Re: [tcpm] draft-minshall-nagle

[[e-mail]]

And... In the old days programmers knew an app would nearly always send
small packets and Nagle needed to be disabled. For many modern apps that
is far less obvious - Nagle may be disabled simply because people think it
is better to do so without really understanding the requirements, or they
may simply not know what the network traffic will look like - Some TCP
connections vary their traffic patterns over time.

Gorry

> 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
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>