[e2e] Why do we need TCP flow control (rwnd)?

[Craig Partridge]

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...

Craig