Re: [tcpm] draft-minshall-nagle

[Wesley Eddy <[e-mail]>]

On 6/3/2014 1:07 PM, Joe Touch wrote:
> 
> 
> On 6/3/2014 8:15 AM, Neal Cardwell wrote:
>> On Tue, Jun 3, 2014 at 11:04 AM, Joe Touch <[e-mail]> wrote:
>>> Hi, Wes,
>>>
>>> Although I don't recall this and only scanned it briefly, I don't quite
>>> understand the problem.
>>>
>>> I thought it was widely known that Nagle was useful for single-character
>>> interactive traffic, but also widely known as something that should be
>>> disabled for any multi-character interactive traffic - including
>>> multi-character encodings, HTTP, etc.
>>>
>>> If Nagle is off - as it should be for interactive web traffic - then the
>>> optimizations in this draft won't have any impact.
>>>
>>> So what kind of traffic does this actually help? Or is this an
>>> optimization
>>> of a path that either isn't or shouldn't be used?
>>
>>
>> The Minshall algorithm is a nice win for some workloads other than web
>> traffic:
>>
>>    Application performance pitfalls and TCP's Nagle algorithm
>>    http://dl.acm.org/citation.cfm?id=346012
> 
> My point is that even by the time of this paper, it was well-understood
> that Nagle should not be used in these environments. The paper cites
> 1999 personal communication with Jim Gettys for this, but it was
> well-known long before it was recited as an issue in this 1996 paper:
> http://ccr.sigcomm.org/archive/1997/apr97/ccr-9704-heidemann.pdf


Even before that!  RFC 1122 (from 1989) says:

   Some applications (e.g., real-time display window
   updates) require that the Nagle algorithm be turned
   off, so small data segments can be streamed out at the
   maximum rate.


> The use case cited is quite dated - network news has been largely
> abandoned. Is there a currently relevant use case for this approach, and
> given that interactive apps already should be disabling Nagle, how much
> will it help?
> 


I agree that disabling Nagle for "interactive" flows should be a
recognized best current practice.  (assuming they're aiming for
a packets/segments per second rate that isn't absurd)

I think this would be a part of the "TCP Usage Guidelines"
analogue to RFC 5405 (for UDP) that Lars once thought about.

Since Nagle is on by default in many OSes, and deciding to turn
it off means a developer has to know what it is, and that it's
even there to be turned off, the Minshall tweak to Nagle does
seem to make it "more friendly" default to a diversity of
application behaviors (small writes, or odd patterns of writes),
while retaining the benefit of conserving packet count.

I've noticed some people seem to have a tendency to disable Nagle
automatically, whether or not that's really necessary, since
maybe it bit them once in the distant past, and was difficult to
debug or understand.  The Minshall flavor stands a better chance
of not indoctrinating people against Nagle this way.

That said, this is not a burning problem.

-- 
Wes Eddy
MTI Systems