[e2e] Why do we need TCP flow control (rwnd)?
day at std.com
Fri Jun 27 05:04:43 PDT 2008
The definitions I have come to use are:
Flow control is a feedback mechanism colocated with the resource
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:
>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.
>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
>> 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
>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
>Prof. Saverio Mascolo
>Dipartimento di Elettrotecnica ed Elettronica
>Politecnico di Bari
>Tel. +39 080 5963621
>Fax. +39 080 5963410
>email:mascolo at poliba.it
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the end2end-interest