<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>Re: [e2e] Are we doing sliding window in the Internet?</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText52294 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Joe at al,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>To add to this discussion, I
just did a few quick tests with a Linux 2.6.18 TCP stack over an (emulated)
satellite link.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>Here are my observations, based on
analyzing the packet trace -</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>1. The sender starts with an initial cwnd
of 3 segments, 1448 bytes each (1448 = 1500 - 40 bytes TCP/IPv4 hdr - 12 bytes
TCP timestamp option).</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>2. The receiver acks every segment for the
first 32 kbytes of received data; subsequently, it acks every other segment
(delayed ack).</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>3. The sender increases cwnd by 1 segment
for every ack (ABC is not used).</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>The cwnd values are as follows
-</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2> Round cwnd</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>
1 3 segments</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>
2 6</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>
3 10 - for
some reason, the sender does not increase cwnd by 6 in this round</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>
4 16 - the 32
kbyte threshold is crossed in this round, so the cwnd increase rate
halves</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>These are close to the values described by
Detlef.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>A 50 kbyte transfer finishes in 5 RTTs
(including one for the SYN exchange).</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>A quick test on a Sun Solaris 5.8 machine
shows the 50 kbyte transfer take 7 RTTs, which is consistent with an
implementation that always uses delayed acks.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Questions: </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>1. Is this what the Linux TCP stack
implementors intended? Is this documented somewhere?</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>2. Does this violate any IETF TCP
principle, in letter or spirit? It seems to have an (unfair) advantage over TCP
implementations that always perform delayed ack.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Anil</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>------------</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>Anil Agarwal</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>ViaSat Inc.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>Germantown, MD</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> end2end-interest-bounces@postel.org on
behalf of Joe Touch<BR><B>Sent:</B> Wed 1/3/2007 1:07 AM<BR><B>To:</B>
l.andrew@ieee.org<BR><B>Cc:</B> end2end-interest@postel.org<BR><B>Subject:</B>
Re: [e2e] Are we doing sliding window in the Internet?<BR></FONT><BR></DIV>
<DIV><BR><BR>
<P><FONT size=2>Lachlan Andrew wrote:<BR>> Greetings,<BR>><BR>> This is
probably not related to the original thread (on what happens<BR>> in real
networks, as distinct from what *should* happen), but the word<BR>> "bug"
bugged me...<BR>><BR>> On 02/01/07, Joe Touch <touch@isi.edu>
wrote:<BR>...<BR>>> > delayed ACKs (as Linux receivers don't when the
window is small),<BR>>><BR>>> Delayed ACKs are strongly
encouraged.<BR>>> Both good reasons to fix these bugs in
Linux.<BR>><BR>> I don't follow the logic of that at all.<BR><BR>Please
review RFC2581.<BR><BR>> Linux deliberatly suppresses<BR>> delayed
ACKs when it guesses that the sender is in slow start, which<BR>> sems
generally correct, judging by the earlier posts in this thread.<BR><BR>Whether
it's interpreted as correct by this email list, it is NOT what<BR>the IETF
currently recommends.<BR><BR>> In that phase, they harm performance, by
making slow-start even slower<BR>> than it was intended to be.
Increasing the initial speed of slow<BR>> starts helps short flows at no long
term cost to ongoing long flows.<BR>> When the window is large, Linux does
use delayed ACKs, for the reasons<BR>> given in the RFCs. Since this is
fully standards compliant, I don't<BR>> see how it can be called a
bug.<BR>><BR>> The fact that something is "encouraged" doesn't *of itself*
seem a<BR>> good reason to do it, if there are clear reasons not to.
That isn't<BR>> to say that there may not indeed be good reasons to change
Linux's<BR>> behaviour; I'd be interested to hear them.<BR><BR>I'd be more
interested to know that there had been *controlled*<BR>experiments to validate
that this behavior was safe and did not impact<BR>the current behavior of TCP
congestion control as per RFC2581. At that<BR>point, I'd be interested to have
that information taken to the IETF with<BR>a proposal to change the recommended
behavior, and have it vetted by<BR>that community.<BR><BR>The idea that this
should be tried in the large "until there are good<BR>reasons not to" is NOT how
such experiments should be performed.<BR><BR>> (On a related note, this
year's PFLDnet<BR>> <<A
href="http://wil.cs.caltech.edu/pfldnet2007">http://wil.cs.caltech.edu/pfldnet2007</A>>
has a panel session on the<BR>> implications of network stack implementors
Linux and Microsoft setting<BR>> new de-facto flow control standards.
This seems analogous to what the<BR>> BSD Reno release did, implementing
improvements well before Reno made<BR>> it into the RFCs. The
difference is that now a global infrastructure<BR>> rides on
it...)<BR><BR>The improvements in Reno were MORE conservative than TCP as
specified,<BR>not less. Being more conservative is always
compliant.<BR><BR>Joe<BR><BR>--<BR>----------------------------------------<BR>Joe
Touch<BR>Sr. Network Engineer, USAF TSAT Space
Segment<BR><BR></FONT></P></DIV>
</BODY>
</HTML>