Window Sizes and ACKs

TCP transfers are connection-orientated transfers. This means that in order for a sender to send more data to a remote machine, the local client (or sender) must first receive an acknowledgement from the remote server. This is commonly known as an ACK.

This form of data acknowledgement provides a means in which the network is 'self-clocked' in such a way that a steady state flow of data between the two endpoints of the connection is possible. Hence, the transfer rate of large files across the internet should reach equilibrium as successfully transmitted data that has left the network will be replaced by newly sent data.

However, if we were to wait for an acknowledgement for each packet of data before sending the next, the transfer rate of the connection would be severely limited by the duration of time that it takes for the sender to receive an ACK. This time value is commonly known as the round trip time (RTT). To circumvent the problem of having to wait for an ACK for every piece of information (a segment), TCP uses a technique in which a series, or a 'window', of segments can be sent out without acknowledgement. These segments are sent out in 'packets' of data across the internet. Once an acknowledgement for a segment on the 'left hand side' of this window is received, the window can progress onwards and the next packet of data can be sent out. This technique is often called 'sliding windows'.

Problems associated with this and more generally with data transfers can be broadly classified into three areas, that of the sender, that of the receiver, and that of the network. Each one of these will be considered in turn.

Sender Side

Upon a new TCP connection, the operating system determines a 'buffer size' (window size) from which data from an application will be stored before the data is transferred. The size of this buffer is often set to a fixed default value on most computers\footnote{Old operating systems often had window sizes as small as 8k. However, with the advent of high-speed communication networks 64k default window sizes are becoming the norm.}. Through simple modelling, one can obtain better network performance by simply increasing the size of the default value of the window size. Further investigations such as parallel TCP streams are a popular way of increasing transfer rates, but are however beyond the scope of this paper.

A simple first order equation to calculate the optimal window size for a known topological network is shown below,

Window Size = Bandwidth x RTT

The Bottleneck Bandwidth is the maximum transfer rate that the network can reach which is often limited by a router not performing optimally along the network path. The Round Trip Time (RTT) is the amount of time required for an acknowledgement to be received from the remote machine assuming instant acknowledgement. Hence, having a default window size of 64k and an RTT of approximately 10ms will yield a maximum bandwidth of about 50Mbits/sec. With ethernet connections of 100Mbits/sec to 1Gbit/sec, it is clear that a larger window size will be necessary to fully utilise the available bandwidth.

Several programs have been developed in order to 'probe' the network to find out the bandwidth available to a certain connection. Programs such as pchar and pipechar have been very successful in aiding network technicians in finding problems in their networks. Pipechar, in particular, will be described later in this report.

Receiver Side

A similar window size buffer to that of the sender is also kept on the remote machine in order to hold data segments that were successfully received. The architecture of the internet means that packets may arrive out of order, damaged or even duplicates received. As such, the role of this window is to hold segments in memory, checking and possibly rearranging it before passing the complete data stream through to the application.

An 'advertised' window is sent back to the sender with ACKs to tell the sending machine how much buffer space is the receiver has available to receive data. This value is important as we do not wish to flood the receiving machine with too much information. If this window size is too small, and assuming the network allows a high enough throughput, data arriving at the receiving machine can not stored, resulting in packets being lost and hence a deterioration in the throughput of the connection.

Network Side

During the transport of data through the internet, packets of data have to be 'routed' by dedicated machines to its destination. However, as each router has to deal with many requests from many machines at once, it has to hold all incoming packets in queues and each packet has to be dealt individually. If the server is overly congested due to an influx of packets, it may cause data to be delayed, or in the worst case, the router may drop certain packets in order to lessen the queue length. This may result in the loss of data as the segments are never ACKed, hence forcing the sender to resent the lost segments of data.

To account for the possibility of packets being delayed during transport, TCP algorithms have a value called RTO which updates a 'timeout' value which defines how long the sender has to wait for an ACK before having to resend that segment of information. The value of RTO is calculated from the RTT of the current and past packets which have been sent through the system. The standard TCP implementation suggests that this RTT is updated on a low-pass filter according to the following formulae,

Err = M - A

Where A is the smoothed average RTT, D is the smoothed mean deviation and M is the RTT of the most recent packet. Both g and h are gain constants with suggested values of 0.125 and 0.25 respectively\cite{internetworking}. As the spread of RTT is not always gaussian, an addition 'fuzz' of 4D is included in the final calculation of RTO. This means that 95% of the time, we would expect the variation of the RTT to be within 2D.

Thu, 3 October, 2002 22:50