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

[Agarwal, Anil]

Joe Touch wrote :

>> Do these semantic wranglings actually have a point?

> The question is "under what conditions is it permissible to override a
> SHOULD". I would hope that would be clarified in an update to 2119, but
> don't know what the state of that doc is...

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.
 
It is perhaps understandable that SHOULDs and even MUSTs can be violated in controlled experimental environments (e.g., simulations).
It is perhaps understandable that SHOULDs may be violated in controlled , isolated environments (e.g., satellite networks).
It may be unavoidable that a SHOULD or MUST is violated by a "hacker" and  used over over the Internet.
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 :). What role should the IETF play in this process? Advisory only?
 
Anil
-----
Anil Agarwal
ViaSat Inc.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/9be39f79/attachment.html