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

[Joe Touch]

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.

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/20070103/d677beb1/signature-0001.bin