Continuous ARQ (TCP) adapting to congestion
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.
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.
|