<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>

<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>Re: [e2e] Are we doing sliding window in the Internet?</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText74238 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT>&nbsp;</DIV></DIV>
<DIV dir=ltr>Joe Touch wrote :<BR><FONT size=2><BR>&gt;&gt; Do these semantic 
wranglings actually have a point?<BR><BR>&gt; The question is "under what 
conditions is it permissible to override a<BR>&gt; SHOULD". I would hope that 
would be clarified in an update to 2119, but<BR>&gt; don't know what the state 
of that doc is...<BR><BR>1. The technical issue in question&nbsp;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</FONT></DIV>
<DIV dir=ltr><FONT size=2>2.&nbsp;QuickAck is enabled in Linux, by default. 
There is no procedure to disable it, except temporarily, for an application via 
a system call.</FONT></DIV>
<DIV dir=ltr><FONT size=2>
<DIV dir=ltr><FONT size=2>3. </FONT><FONT size=2>Linux supports many other 
"non-standard" TCP features, but most/all of them seem to be disabled by 
default.</FONT></DIV></FONT></DIV>
<DIV dir=ltr><FONT size=2>4. There does not seem to be&nbsp;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. 
&nbsp;There is no RFC on the subject.</FONT></DIV>
<DIV dir=ltr><FONT size=2>5. It seems to violate a "SHOULD" statement in the 
RFCs. </FONT></DIV>
<DIV dir=ltr><FONT size=2>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&nbsp;discussion.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT size=2>It is perhaps understandable that SHOULDs and even 
MUSTs can be violated in controlled experimental environments (e.g., 
simulations).</FONT></DIV>
<DIV dir=ltr><FONT size=2>
<DIV dir=ltr><FONT size=2>It is perhaps understandable that SHOULDs may be 
violated in controlled , isolated environments (e.g., satellite 
networks).</FONT></DIV>
<DIV dir=ltr>
<DIV dir=ltr><FONT size=2>It may be unavoidable that a SHOULD or MUST 
is&nbsp;violated by a "hacker" and&nbsp; used over&nbsp;over the 
Internet.</FONT></DIV>But under what circumstances should a SHOULD be violated 
and let loose over the Internet as part of a widely used OS?</DIV>
<DIV dir=ltr>&nbsp;</DIV>
<DIV dir=ltr>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?</DIV>
<DIV dir=ltr>&nbsp;</DIV>
<DIV dir=ltr>Anil</DIV>
<DIV dir=ltr>-----</DIV>
<DIV dir=ltr>Anil Agarwal</DIV>
<DIV dir=ltr>ViaSat Inc.</DIV>
<DIV dir=ltr>&nbsp;</DIV></DIV></FONT><FONT size=2></FONT>

</BODY>
</HTML>