Computer Laboratory

Course material 2010–11

Continuous ARQ (TCP) adapting to congestion

Critically, this video does NOT show slow-start only congestion avoidance - the second phase of TCPs mechanisms for congestion control.

This video shows the (windowing) continuous ARQ mechanism employed by TCP adapting to congestion.

ARQ can be used to ensure reliable delivery of data; simply reacting to the drop will trigger a packet retransmission.

The exact size of an ARQ window might be fixed as a function of the channel capacity, frame-size and channel delay. (refer to slide 7-8)

However, TCP does not fix the window size to a static value, it adapts the window size in the face of congestion within the network.

Firstly, one might ask why does TCP do this; the reason is that two TCP end-points do not know the properties of the network between them (end-points do not have values for channel capacity or channel delay).

TCP adapts (enlarges) the ARQ window in an attempt to "locate" the correct window size - the correct window size is a combination of the receiver's buffer capacity and the round-trip-time.

Secondly, as discussed, TCP uses ARQ to respond to congestion. While congestion is an event in the network that is independent of end-points, it is usually treated as independent and unable to be predicted. As a result, TCP needs to respond dynamically to the coming and going of congestion events.

Both problems are attended using the same mechanism:

TCP will expand the ARQ window until packets are dropped.

TCP will then halve the window size, recover the error, and resume (slowly) opening the window.

The movie illustrates a pair of TCP end-points sending data in one direction.

The graph along the bottom illustrates the current value of the window size over time.

As packet-acknowledgements (RED) are received by the source (left-hand-side); the window is opened: the sender presumes more packets may be made outstanding, that is, sent into the network in the network without receiving ACKS.

The congestion is emulated by the bottleneck on the right-hand link - a value of utilisation of the right-hand link is computed and displayed.

Once a packet is lost (the buffer overflows and the packet drops out the bottom), the information about the drop (the word "drop") is carried through the network and once received by the sender, the sender reacts by halving the window-size. This has the immediate effect that no more packets are sent into the network until the window is "caught-up". Note how the W value in the sender is halved.

Once acknowledgements are received for the (now halved) window; the sender will once-again start increasing the window size.

Things to note:

The reactive ARQ employed by TCP will keep the right-hand link at full utilisation - once this is achieved.

However, TCP takes a long time (lots of packets) to reach a point where the right-hand link is full utilised.

And, TCP will cause packets to be regularly dropped at points of congestion - even in normal operation.