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

[Michael Scharf]

On Thu, 26 Jun 2008 at 07:52:35, Craig Partridge wrote:
> >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...

Instead of dropping arriving packets or not sending acks, the receiver
could also send an ack with ECN marking (assuming ECN usage is
negotiated). This would also throttle the sender, but not require a
retransmission. To my understanding, ECN marking would not cause all
these problems.

Thus, a receiver running out of buffer space could just use ECN
instead of shrinking rwnd. (Of course, the ECN solution is more coarse
grained and does not offer certain features, such as zero window
updates.)

Michael