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

From: Vernon Schryver <[email-masked]>
Date: Wed, 17 Feb 1999 07:48:28 -0700 (MST)

> From: "Eric A. Hall" <[email-masked]>

> ...
> On a lark I did a search for +"nagle algorithm" on AltaVista, and almost
> all references to it are things that explain what it is and then
> admonish the programmer from using it. I'm starting to wonder too if
> anybody actually disables it for non-interactive, non-realtime stuff.

Why would anyone care, since you're talking about "non-interactive,
non-realtime stuff", and the worst effect of Nagle on bulk transfers is
an extra 0.1 second delay in sending the FIN?

> Apple's OT devsite: http://developer.apple.com/qa/nw/nw26.html
> Winsock FAQ:
> http://telin.rug.ac.be/~sid/Netwerken/Winsock/advanced.html#q15

That talks about an especially weak reason to turn off the Nagle
algorithm, to try to retain packet boundaries on the wire, presumably
so that application receive requests get the same block boundaries
as sent by the sender.

> WinSock API:
> http://www.medusa.uni-bremen.de/intern/knowhow/winsock/winsock4.htm

That's a nice ASCII version of the Winsock 1 spec.  Thanks.
I see it mentions RCVBUF and SNDBUF

> ...
> http://www.isi.edu/lsam/publications/phttp_tcp_interactions/

> In this particular test, disabling Nagle helped a lot since the data
> being returned from the HTTP server was sent as two writes (one for the
> MIME header and another for the data).

The following sentence in that paper is interesting:

|   Apache supports keep-alive connections, an early implementation
|   of P-HTTP.  When handling a keep-alive connection, Apache sends
|   its headers as a separate segment. (It does so to work around
|   a bug in a popular browser.)

That seems to me to imply that of the two reasons to turn off the Nagle
algorithm in Apache, broken writes like those and what they call the
"Odd/Short-Final-Segment Problem", the first forces them to turn off Nagle
regardless.  That means that while the second would be helped by the
proposed modification to Nagle, it is moot.  In other words, it's
consistent with my claim that the proposed modification to Nagle won't
gain anything in the real world.

(I am puzzled by that work-around for the browser bug.  Apache cannot
guarantee that its segments won't be combined by the sending kernel.
Oh well, maybe it works often enough to be worthwhile.)

> http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html also
> discusses the issue some, suggesting that Nagle made no effect on some
> pipelined transactions, while it did have an effect in others.

They're talking about turning off Nagle regardless because sometimes doing
so helps a lot.  That again makes the proposed modification moot.

Vernon Schryver    [email-masked]

---

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Wed, 17 Feb 1999 15:31:56 -0500

>so helps a lot.  That again makes the proposed modification moot.

That's because we can't control it the way we would like and don't want to
suffer from the potential penalty. Give me the on/off flag and I am happy
to not say that Nagle should be turned off by default.

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk