<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [e2e] Why do we need TCP flow control
(rwnd)?</title></head><body>
<div>The definitions I have come to use are:</div>
<div><br></div>
<div>Flow control is a feedback mechanism colocated with the resource
being controlled.</div>
<div><br></div>
<div>Congestion control is a feedback mechanism not co-located with
the resource being controlled.</div>
<div><br></div>
<div>And there in lies the rub.</div>
<div><br></div>
<div><br></div>
<div>At 12:01 +0200 2008/06/27, Saverio Mascolo wrote:</div>
<blockquote type="cite" cite><font face="Arial" size="-1">dear
michael,</font></blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">you are
missing main points here:</font></blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">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;</font></blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">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.</font></blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">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.</font></blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">best</font></blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">saverio</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"><br>
<br>
</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">On Fri, Jun
27, 2008 at 10:08 AM, Michael Scharf
<michael.scharf@ikr.uni-stuttgart.de> wrote:</font><br>
<font face="Arial" size="-1"></font>
<blockquote><font face="Arial" size="-1">On Thu, 26 Jun 2008 at
07:52:35, Craig Partridge wrote:<br>
> >Instead of reducing rwnd, an overloaded receiver running out
of buffer<br>
> >space could simply drop (or mark) new arriving packets, or
just<br>
> >refrain from sending acknowledgements.<br>
><br>
> So, try the thought experiment.<br>
><br>
> Suppose the receiver does drop the newly arriving segment.
Eventually<br>
> the segment is retransmitted. Two (non-exclusive)
situations to consider:<br>
><br>
> * the segment's packet encounters
congestion and causes another packet<br>
> to be dropped -- now the
decision by the receiver to drop the<br>
> original transmission has
caused a third party harm...<br>
> (See the Floyd/Romanow paper
from SIGCOMM several years back for<br>
> an analogous situation in ATM
and the harm it causes).<br>
><br>
> * the segment's packet fails to get to
the receiver (congestion loss or<br>
> transmission error) -- this
can be repeated for each retransmission,<br>
> such that the receiver's
decision to drop the original segment means<br>
> it never gets the segment and
the connection dies...<br>
><br>
> So dropping a segment is bad. Let's try retaining but not
sending acks...<br>
><br>
> * without an ack, the sender eventually
retransmits and the retransmitted<br>
> segment can, in a case of
congestion, again cause loss for a third<br>
> party (to no purpose, as the
retransmission is clearly redundant --<br>
> if only the receiver had
acked...)<br>
><br>
> * if acks are suppressed too long, the
sender times out the connection<br>
> and the connection fails<br>
><br>
> * another consequence is that the sender
increases its round-trip<br>
> timeout, so when a true loss
occurs later in the connection, the<br>
> sender will respond less
promptly (harming performance).<br>
><br>
> In conclusion, the receiver needs to ack, and ack promptly.
But the<br>
> receiver is not ready for more data...</font><br>
<font face="Arial" size="-1"></font></blockquote>
<blockquote><font face="Arial" size="-1">Instead of dropping arriving
packets or not sending acks, the receiver<br>
could also send an ack with ECN marking (assuming ECN usage is<br>
negotiated). This would also throttle the sender, but not require
a<br>
retransmission. To my understanding, ECN marking would not cause
all<br>
these problems.<br>
<br>
Thus, a receiver running out of buffer space could just use ECN<br>
instead of shrinking rwnd. (Of course, the ECN solution is more
coarse<br>
grained and does not offer certain features, such as zero window<br>
updates.)<br>
<font color="#888888"><br>
Michael</font></font><br>
<font face="Arial" size="-1"></font></blockquote>
</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"><br>
<br>
<br>
--<br>
Prof. Saverio Mascolo<br>
Dipartimento di Elettrotecnica ed Elettronica<br>
Politecnico di Bari<br>
Tel. +39 080 5963621<br>
Fax. +39 080 5963410<br>
email:mascolo@poliba.it<br>
<br>
http://www-dee.poliba.it/dee-web/Personale/mascolo.html</font></blockquote
>
<div><br></div>
</body>
</html>