[e2e] Are we doing sliding window in the Internet?
touch at ISI.EDU
Wed Jan 3 21:21:04 PST 2007
Agarwal, Anil wrote:
> 1. The technical issue in question is QuickAck, where delayed acks are
> not used for the first R / 2 bytes of received data, where R seems to be
> the receive socket buffer size
> 2. QuickAck is enabled in Linux, by default. There is no procedure to
> disable it, except temporarily, for an application via a system call.
> 3. Linux supports many other "non-standard" TCP features, but most/all
> of them seem to be disabled by default.
> 4. There does not seem to be a whole lot of technical documentation on
> the feature, except for the Linux man page. It is not clear how this
> feature gets turned on and off during the life of a connection. There
> is no RFC on the subject.
> 5. It seems to violate a "SHOULD" statement in the RFCs.
> 6. It's objective is certainly not nefarious. It improves performance
> for individual short data transfers. Perhaps the SHOULD needs to be
> changed with some qualifications. But that requires an open discussion.
Nefarious motives are not the issue. The SHOULD currently stands, and it
is Linux's default that should be changed first.
> But under what circumstances should a SHOULD be violated and let loose
> over the Internet as part of a widely used OS?
> One would like to think that the last category should require some care
> and a rigorous process. Is this process not documented or well
> understood? Surely, it cannot be - implement, deploy, publish paper and
> write RFC :).
How about "implement, *test*, publish a paper or bring the results to
the IETF, and publish an RFC"? (i.e., basically, "of course it can be")
And don't call me Shirley ;-) (with apologies in advance to those not
familiar with the movie "Airplane")
> What role should the IETF play in this process? Advisory only?
The IETF plays the role of standards body. Linux (and Microsoft)
*should* play the role of test first, deploy later.
Sr. Network Engineer, USAF TSAT Space Segment
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/d677beb1/signature-0001.bin
More information about the end2end-interest