<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6000.16674" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>dear michael,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>you are missing some big points here: </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>1. flow control is aimed at avoiding overflow</DIV>
<DIV><BR><BR></DIV>
<DIV class=gmail_quote>On Fri, Jun 27, 2008 at 10:08 AM, Michael Scharf
<michael.scharf@ikr.uni-stuttgart.de> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV>
<DIV></DIV>
<DIV class=Wj3C7c>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...<BR><BR></DIV></DIV>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<BR></FONT></BLOCKQUOTE></DIV>
<DIV><BR><BR clear=all><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></DIV></BODY></HTML>