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

[John Day]

The definitions I have come to use are:

Flow control is a feedback mechanism colocated with the resource 
being controlled.

Congestion control is a feedback mechanism not co-located with the 
resource being controlled.

And there in lies the rub.


At 12:01 +0200 2008/06/27, Saverio Mascolo wrote:
>dear michael,
>
>you are missing main points here:
>
>1. flow control is aimed at avoiding overflow of the receiver 
>buffer. the receiver buffer is assigned on a per-flow base, i.e. it 
>is not a shared resource. This makes  flow control a mechanism that 
>is 100% perfect from the point of  view of control, i mean   that 
>all the feedback required for perfect control is available;
>
>2. congestion control does not know buffer available at routers 
>because they are shared; this is the reason you need a probing 
>mechanism to estimate cwnd. you do not need this probing mechanism 
>with the receiver buffer since the advertised window tells you the 
>exact available buffer.
>
>this is why we need flow control. moreover,  saturating cwnd with 
>receiver-buffer size (f.i.  64Kb) avoids that any single flow 
>congest network using probing.
>
>best
>
>saverio
>
>
>On Fri, Jun 27, 2008 at 10:08 AM, Michael Scharf 
><michael.scharf at ikr.uni-stuttgart.de> wrote:
>
>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
>
>
>
>
>--
>Prof. Saverio Mascolo
>Dipartimento di Elettrotecnica ed Elettronica
>Politecnico di Bari
>Tel. +39 080 5963621
>Fax. +39 080 5963410
>email:mascolo at poliba.it
>
>http://www-dee.poliba.it/dee-web/Personale/mascolo.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20080627/4605cc2c/attachment-0001.html