Personal Miscellaneous TCP/IP GRID Quality of ServiceMulti-Cast  
Background high-speed tcp Transfer Tests Web 100TCP Tuning  

Congestion Windows and Congestion Signals

 

TCP is based on the notion of the sliding window in order to enable reliable and in-order delivery of packets from a sender to a sink.

Inadequate Window: 16 bit receiver window field in the packet header limits BW to 64 kb/RTT. RFC1323 provides a Window Scale option to address this problem.
Can now scale window by up to 2^14. New max window is 1 GB. (How soon will it be until this runs out?) (With 1500 byte packets, this is a window of 600,000 packets. How long would that take to open?)

Timestamps: RFC1323 also introduced the Timestamp Option. This provides for timing of every packet in flight, rather than only one per RTT. This enables keeping a more dynamic and accurate value for RTO.
Can anyone see problems with this? Haven't changed the exponential smoothing, so RTO varies rapidly. In particular SDEV could become small quickly even if long term RTT fluctuations are occuring.

The congestión window (Cwnd) is defined as the number of allowed packets (or bytes) sent but not yet acknowledged (packets or bytes in transit).

A window indicates the size of outstanding data allowed in aTCP connection without acknowledgment o A window closes as the left edge advances to the right whendata is sent and acknowledged o A window opens as the right edge moves to the right, allowingmore data to be sent (receiver's buffer is cleaned) o A window shrinks when the right edge moves to the left. Notallowed by TCP's RFC o the window size is controlled by the receiving application

The optimal send-buffer size of a tcp connection is the smallest size buffer that still enables the conneciton to use the maximum available bandwidth. Thatis to send a new segment whenever tcp flow control allows. This optimal buffer size may change during the lifetime of the connection.

The optimal send-buffer size is directly affected by the following factors:

The sender window

 

Congestion Signals

Congestion signals are signs that the network is congested. As TCP has no explicity feedback from the network about congestion (although Explicit Congestion Notification is now becoming popular), the only way in which TCP can 'know' that congestion has occured is by the absence acks for specific packets.

The absence of acks falls under two categories: the complete loss of an ack, ie we don't get one, or get one too late; or we recieve an ack for an unexpected packet, that is not for the packet on the leftmost side of the window. The former can be taken as a sign that the reciever has not recieved the packet, whilst the latter can be interpreted as a sign that there has been some reordering in the network.

How congestion signals are used, and more importantly, how a cluster of congestion signals are use, is dependent on the variant of TCP being used.

 

Wed, 23 July, 2003 13:07 Previous PageNext Page
 
 
    email me!
© 2001-2003, Yee-Ting Li, email: ytl@hep.ucl.ac.uk, Tel: +44 (0) 20 7679 1376, Fax: +44 (0) 20 7679 7145
Room D14, High Energy Particle Physics, Dept. of Physics & Astronomy, UCL, Gower St, London, WC1E 6BT