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

[Saverio Mascolo]

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/379d3712/attachment.html