Subject: Re: internet draft on suggested mod to the Nagle algorithm

From: Vernon Schryver <[email-masked]>
Date: Thu, 11 Feb 1999 14:59:32 -0700 (MST)

>>I think that by modifying the Nagle algorithm in the manner presented in the
>>draft, we can improve the performance for a percentage of the request/response
>>interactions for many internet applications (including the biggie, http) in a
> > way that is transparent to application developers.  I think this is a win.

As the discussion has gone on, there seems to me less justification for
changing the Nagle algorithm.  Could someone review the plausible scenarios
where the change helps?  (I.e. not just switching the interpretation of
"send" from what it seems no one used to something closer to what everyone
is doing.)

> I do not think that just the interpretation change alone will make much
> of a difference because the internal application buffering such as you
> discuss will not align nicely with 2*MSS, or the applications will make
> a pair of sub-mss sends.
>
> Also, it sounds like we have a number of stacks out there already which
> are implementing something very close to the proposed change to Nagle,
> and we still have rampant use of TCP_NODELAY.
>
> So, we could go ahead with the codification of the change to nagle as
> being per-send/the draft, but unless explicit flush becomes reality I
> don't think there will be a significant impact on the use of
> TCP_NODELAY.

That's an excellent point.  It's weakness is in the implicit assumption
that there exist many request-response applications that use transactions
larger than the MSS and smaller than the windows, where 100 ms one way or
another matters, which are not turning off Nagle for other reasons, and
also where turning off Nagle would be less desirable.  Concrete examples
of such applications are required for any change to TCP.

That bad programmers might imitate people who turn off Nagle for good
reasons is not justification for adding a TCP Flush knob.  The incompetant
will do the wrong thing regardless.  The best you might hope is that
they'd use the flush knob as well as turning off Nagle.

One must never add code to an operating system by reasoning "why not,"
since down that path lie many infamous piles of bloat.  It is even more
important to never write standards based on vague hopes or "it can't
hurt" reasoning.  Down that road lie the dead protocols such as the ISO
OSI suite, 100VG-AnyLAN, and FDDI-II.  That way also is populated by
Winsock 2.0 (read the spec to see the zillions of geegaws, geewhizzes,
and "wouldn't-it-be-nice"s) and WIN32 (which must be used to be believed,
with its 37 ways to do anything, all of which require at least 300 lines
more than you'd expect).

Vernon Schryver    [email-masked]

---

From: Greg Minshall <[email-masked]>
Date: Fri, 12 Feb 1999 18:01:42 -0800

Vernon (and others, i am sure),

> As the discussion has gone on, there seems to me less justification
> for changing the Nagle algorithm.  Could someone review the plausible
> scenarios where the change helps?  (I.e. not just switching the
> interpretation of "send" from what it seems no one used to something
> closer to what everyone is doing.) 

The scenario is that TCP has been willing to send lots of data because (either 
at tcp_output() or at send()) it was presented with "lots" of data to send (>= 
MSS), and so has sent lots of data.  Now, it is presented (either at 
tcp_output() or at send()) with a "little bit" of data.  In this case, TCP 
will wait until all the previous data has been acknowledged.

(The change would allow TCP to transmit this "little bit" of data (but not 
transmit any subsequent "little bit" of data until *this* "little bit" of data 
has been acknowledged.)

Greg (who believes many things, such as that a mode of program-controlled 
flushing would probably be a good API addition, and that some heuristics to 
delayed ACKs might be a good thing [but make sure you understand about Silly 
Window Syndrome avoidance before messing too much with that! -- see RFC813, 
one of the Dave Clark 5], etc., but *still* feels this change will help things)