[e2e] Are we doing sliding window in the Internet?
Anil.Agarwal at viasat.com
Wed Jan 3 13:14:20 PST 2007
Joe at al,
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.
Here are my observations, based on analyzing the packet trace -
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).
2. The receiver acks every segment for the first 32 kbytes of received data; subsequently, it acks every other segment (delayed ack).
3. The sender increases cwnd by 1 segment for every ack (ABC is not used).
The cwnd values are as follows -
1 3 segments
3 10 - for some reason, the sender does not increase cwnd by 6 in this round
4 16 - the 32 kbyte threshold is crossed in this round, so the cwnd increase rate halves
These are close to the values described by Detlef.
A 50 kbyte transfer finishes in 5 RTTs (including one for the SYN exchange).
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.
1. Is this what the Linux TCP stack implementors intended? Is this documented somewhere?
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.
From: end2end-interest-bounces at postel.org on behalf of Joe Touch
Sent: Wed 1/3/2007 1:07 AM
To: l.andrew at ieee.org
Cc: end2end-interest at postel.org
Subject: Re: [e2e] Are we doing sliding window in the Internet?
Lachlan Andrew wrote:
> This is probably not related to the original thread (on what happens
> in real networks, as distinct from what *should* happen), but the word
> "bug" bugged me...
> On 02/01/07, Joe Touch <touch at isi.edu> wrote:
>> > delayed ACKs (as Linux receivers don't when the window is small),
>> Delayed ACKs are strongly encouraged.
>> Both good reasons to fix these bugs in Linux.
> I don't follow the logic of that at all.
Please review RFC2581.
> Linux deliberatly suppresses
> delayed ACKs when it guesses that the sender is in slow start, which
> sems generally correct, judging by the earlier posts in this thread.
Whether it's interpreted as correct by this email list, it is NOT what
the IETF currently recommends.
> In that phase, they harm performance, by making slow-start even slower
> than it was intended to be. Increasing the initial speed of slow
> starts helps short flows at no long term cost to ongoing long flows.
> When the window is large, Linux does use delayed ACKs, for the reasons
> given in the RFCs. Since this is fully standards compliant, I don't
> see how it can be called a bug.
> The fact that something is "encouraged" doesn't *of itself* seem a
> good reason to do it, if there are clear reasons not to. That isn't
> to say that there may not indeed be good reasons to change Linux's
> behaviour; I'd be interested to hear them.
I'd be more interested to know that there had been *controlled*
experiments to validate that this behavior was safe and did not impact
the current behavior of TCP congestion control as per RFC2581. At that
point, I'd be interested to have that information taken to the IETF with
a proposal to change the recommended behavior, and have it vetted by
The idea that this should be tried in the large "until there are good
reasons not to" is NOT how such experiments should be performed.
> (On a related note, this year's PFLDnet
> <http://wil.cs.caltech.edu/pfldnet2007> has a panel session on the
> implications of network stack implementors Linux and Microsoft setting
> new de-facto flow control standards. This seems analogous to what the
> BSD Reno release did, implementing improvements well before Reno made
> it into the RFCs. The difference is that now a global infrastructure
> rides on it...)
The improvements in Reno were MORE conservative than TCP as specified,
not less. Being more conservative is always compliant.
Sr. Network Engineer, USAF TSAT Space Segment
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the end2end-interest