[e2e] Are we doing sliding window in the Internet?

[Joe Touch]

Lachlan Andrew wrote:
> Greetings,
> 
> 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
that community.

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.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070102/d6846059/signature-0001.bin