[e2e] Why do we need TCP flow control (rwnd)?
craig at aland.bbn.com
Thu Jun 26 04:52:35 PDT 2008
In message <20080626073836.GA13918 at ikr.uni-stuttgart.de>, Michael Scharf writes
>However, I have some difficulties to understand why the flow control
>part and receiver advertized window is actually needed.
>Instead of reducing rwnd, an overloaded receiver running out of buffer
>space could simply drop (or mark) new arriving packets, or just
>refrain from sending acknowledgements.
So, try the thought experiment.
Suppose the receiver does drop the newly arriving segment. Eventually
the segment is retransmitted. Two (non-exclusive) situations to consider:
* the segment's packet encounters congestion and causes another packet
to be dropped -- now the decision by the receiver to drop the
original transmission has caused a third party harm...
(See the Floyd/Romanow paper from SIGCOMM several years back for
an analogous situation in ATM and the harm it causes).
* the segment's packet fails to get to the receiver (congestion loss or
transmission error) -- this can be repeated for each retransmission,
such that the receiver's decision to drop the original segment means
it never gets the segment and the connection dies...
So dropping a segment is bad. Let's try retaining but not sending acks...
* without an ack, the sender eventually retransmits and the retransmitted
segment can, in a case of congestion, again cause loss for a third
party (to no purpose, as the retransmission is clearly redundant --
if only the receiver had acked...)
* if acks are suppressed too long, the sender times out the connection
and the connection fails
* another consequence is that the sender increases its round-trip
timeout, so when a true loss occurs later in the connection, the
sender will respond less promptly (harming performance).
In conclusion, the receiver needs to ack, and ack promptly. But the
receiver is not ready for more data...
More information about the end2end-interest