|
The
Window Flag
The Window
size is considered to be one of the most important flags within the
TCP header. This field is used
by the receiver to indicate to the sender the amount of data that it is able
to accept. Regardless of who the sender or receiver is, the field will always exist and be used.
You will notice that the largest portion of this page is dedicated to the Window size field. The reason behind this is because this field is of great importance. The Window size field is the key to efficient data transfers and flow control.
It trully is amazing once you start to realise how important this flag
is and how many functions it contains.
The Window size field uses
'bytes' as a metric. So in our example above, the number 64,240 is equal to 64,240
bytes, or 62.7 kb (64,240/1024).
The 62.7 kbytes
reflects the amount of data the receiver is able to accept, before transmitting to
the sender (the server) a new Window value. When the amount of data transmitted is equal to the current Window value, the sender will expect a new Window value from the receiver,
along with an acknowledgement for the Window just received.
The above process is required in order to maintain flawless data transmission and high efficiency. We should however note that the Window size field selected is not in any case just a random value, but one calculated using special formulas like the one in our example below:
In this example, Host
A is connected to a Web server via a 10 Mbit link. According
to our formula, to calculate the best Window value we need the following
information: Bandwidth and Delay.
We are aware of the link's bandwidth:
10,000,000 bits (10 Mbits), and
we can easily find out the delay by issuing a 'ping' from Host
A to the Web server which
gives us an average Round Trip Time response (RTT)
of 10 milliseconds
or 0.01 seconds.
We are then able to use this information to calculate the most efficient Window size
(WS):
WS
= 10,000,000 x 0.01
=> WS =
100,000 bits or (100,000/8)/1024
= 12,5 kbytes
For 10 Mbps bandwidth and
a round-trip delay of 0.01 sec, this gives a window size of about 12
kb or nine 1460-byte segments:
This should yield maximum throughput on a 10 Mbps LAN, even if the delay is as high as 10 ms because
most LANs have round-trip delay of less than a few milliseconds. When
bandwidth is lower, more delay can be tolerated for the same fixed window
size, so a window size of 12 kb works well at lower speeds, too.
Windowing
- A Form of Flow Control
Apart from the Windowing concept being a key factor for efficient data transmission, it is also a form
of flow control, where a host (the receiver) is able to indicate to the other
(the sender) how much data it can accept and then wait for further instructions.
The fact is that in almost
all cases, the default value of 62 kbytes is used as a Window size. In addition, even
though a Window size of 62 kbytes might have been selected by the receiver,
the link is constantly monitored for packet losses and delays during the data
transfer by both hosts, resulting in small increases or decreases of
the original Window size in order to optimise the bandwidth utilisation
and data throughput.
This automatic self-correcting mechanisim
ensures that the two hosts will try to make use of the pipe linking
them in the best possible way, but do keep in mind that this is not a guarantee that they will
always succeed. This is generally the reason why a user is able to manually modify the Window
size until the best value is found and this, as we explained, depends greatly on the link between the hosts and its delay.
In the case where the Window size falls
to zero, the remote TCP can send no more data. It must wait until buffer
space becomes available and it receives a packet announcing a non-zero
Window size.
Lastly, for those who deal
with Cisco routers, you might be interested to know that you are able
to configure the Window size on
Cisco routers running the Cisco IOS v9 and greater. Routers
with versions 12.2(8)T and above support Window Scaling, a feature that's automatically
enabled for Window sizes above 65,535, with a maximum value of 1,073,741,823
bytes!
Window Scalling will be dealt with in greater depth on the following page.
On the Server Side: Larger Window Size = More Memory
Most network administrators
who have worked with very busy web servers would recall the massive
amounts of memory they require.
Since we now understand the concept of a 'Window size', we are able to quickly analyse
how it affects busy web servers that have thousands of clients connecting
to them and requesting data.
When a client connects
to a web server, the server is required to reserve a small amount of memory
(RAM) aside for the client's session. The amount of required memory
is the same amount as the window size and, as we have seen, this value
depends on the bandwidth and delay between the client and server.
To give you an idea
how the window size affects the server's requirements in memory, let's
take an example:
If you had a web
server that served 10,000 clients
on a local area network (LAN) running at 100
Mbits with a 0.1 second round
trip delay and wanted maximum performance/efficiency for your file transfers, according to our formula, you
would need to allocate a window of 1.25
MB for each client, or 12 Gigs
of memory for all your clients! Assuming of course that all 10,000 clients are connected to your web server simultaneously.
To support large file transfers
in both directions (server to client and vice versa), your server would
need: [(100,000,000 x 0.1)
10,000 x 2] = over 24 Gigs of memory
just for the socket buffers!
So you can see how important
it is for clients not to use oversized window values! In fact, the current
TCP standard requires that the receiver must be capable
of accepting a full window's worth of data at all times. If the receiver over-subscribes
its buffer space, it may have to drop an incoming packet. The sender
will discover this packet loss and invoke TCP congestion control mechanisms
even though the network is not congested.
It is clear that receivers
should not over-subscribe buffer space (window size) if they wish to
maintain high performance and avoid packet loss.
Checksum
Flag
The TCP Checksum field was created to ensure that the data contained in the TCP segment
reaches the correct destination and is error-free. For those network
gurus who are wondering how TCP would ensure the segment arrives to
the correct destination (IP Address), you will be happy to know that
there is a little bit more information used than just the TCP header
to calculate the checksum and, naturally, it would include a portion
of the IP Header.
This 'extra' piece
of information is called the pseudo-header and we will shortly analyse
its contents but, for now, let's view a visual representation of the sections used to
calculate the TCP checksum:
The above diagram shows you the pseudo header, followed
by the TCP header and the data
this segment contains. However, once again, be sure to remember that the pseudo
header is included in the Checksum calculation to ensure the segment
has arrived at the correct receiver.
Let's now take a look how the receiver
is able to verify it is the right receiver for the segment it just received by analysing the pseudo header.
The
Pseudo Header
The
pseudo header is a combination of 5 different fields, used during the
calculation of the TCP checksum. It is important to note (and remember!)
that the pseudo header is not transmitted
to the receiver, but is simply involved in the checksum calculation.
Here are the
5 fields as they are defined by the TCP RFC: |
