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

[Saverio Mascolo]

dear michael,

you are missing some big points here: 

1. flow control is aimed at avoiding overflow



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/2827cff2/attachment.html