Re: [tcpm] draft-minshall-nagle

On Wed, Jun 4, 2014 at 12:55 PM, Joe Touch <touch@isi.edu> wrote:

>
>
> On 6/3/2014 8:20 PM, Wesley Eddy wrote:
>
>> On 6/3/2014 1:07 PM, Joe Touch wrote:
>>
> ...
>
>  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.
>>
>
> I saw that, but it's more than for displays; it's actually anything
> *interactive* where the data unit is longer than one byte (e.g., Unicode
> telnet!).

The history of the reference to me is the following:

1) Bob Scheifler and I had developed early versions of the X Window System.
2) when a new BSD release came out (or it may have been a new snapshot of
the network stack, as there was the BSD vs. BBN TCP stack wars going on),
performance of rubber band tracking got dramatically worse.

We tracked it down to the addition of Nagle: and shortly thereafter,
TCP_NODELAY was born: I don't remember whether Bob coded it up, or Mike
Karels.

Specifically, the delay of sending mouse event packets to applications over
the X protocol was terrible to interactive performance.  These mouse events
were around 24 bytes at the time, IIRC (X11 the events are 32 bytes).  As
the X server and client library do various forms of buffering, having the
OS get in the way is not good.  And you *never* want to delay interactive
traffic by anything on the timescale required to merge keystrokes, which,
as I remember, was the original intent of the optimization.

Unfortunately, I believe the default (being on) is wrong.  But it's far too
late to make that change.

>
>
>  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,
>>
>
> I didn't think O_NODELAY was all that cryptic...

And many poor developers have been bit with it being on over the decades.
They naively think that data will be transmitted when you ask the operating
system.  It surprises them badly when it does not...
                                      - Jim

>
>
>
>  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.
>>
>
> Nagle is useful in a very small use case that no longer exists - it's rare
> that we have interactive traffic that we know can be split at a byte
> boundary.
>
>
>  That said, this is not a burning problem.
>>
>
> Agreed.
>
> Joe
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>