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

From: Vernon Schryver <[email-masked]>
Date: Tue, 16 Feb 1999 20:16:17 -0700 (MST)

> From: Greg Minshall <[email-masked]>

> ...
> > suffer the problem, or a pointer to a real application that
> > exemplifies the class of suffering applications.  These must be
> > applications that now suffer unnecessary latency on real world TCP
> > stacks on private nets or the Internet. 
>
> I'm not sure we're converging, but let's try this:  for request-reponse 
> protocols with variable-sized responses, with the current Nagle and delayed 
> ACKs, there is no way to write the server application such that some 
> percentage of the responses don't get delayed.  The modified Nagle allows an 
> application writer to write their application to avoid that particular delay.

That's still only a sketch of an hypothetical application instead of a
concrete pointer.  Do you have a name of a product? 

My intuition claims there are essentially no real applications that fit
that sketch, and do not need to turn off the Nagle algorithm for other
reasons.  The most common reason is the incompetant use of write-write
instead of writev().  Another common but respectable reason is occassional,
unidirectional traffic asynchronous with the main requests and responses.
If your application has extra, one sided operations, such as updating
unimportant status, then you must turn off Nagle, or the real requests will
stall when they come.

It has been said that the proposal would wean users of write-write instead
of writev to turning off Nagle.  I disagree.  They'll still reflexively
turn off Nagle instead of using writev(), and won't notice the modified
Nagle algorithm.

The modification is not free.  It's modest cost <<MUST>> have concrete
beneficiaries!

I think you've convinced me the current Nagle algorithm is good enough
for fixing telnet, that it does not matter to FTP, NFS, and other bulk
applications, and it is and always will be turned off for HTTP and
everything else for various good and bad reasons.

> Here's something i mentioned to the Rick Jones (and the list); maybe this 
> helps:
>
> > Check out, for example, John Heideman's article in the  April, 1997,
> > ACM SIGCOMM Computer Communications Review, or Henrik Nielsen, et  al,
> > from SIGCOMM 1997, for example of fairly well-crafted applications
> > that  still run afoul of Nagle/delayed ACK interactions.

Do you have an on-line reference?   A year or two ago, after 15 going on
30 years of increasing irritation, the ACM's insistance on charging me
for the nearly content-free, trade rag that CACM had become exhausted my
patience and extravagance.  You can get ads separated by bogus statistics
proving the wonders of the latest panacea for the Information Technology
Crisis du jure for free, and with a lot less stilted pedantry.  And you
don't get invoices with hefty "contributions" conveniently included.

I do recall seeing something somewhere about HTTP 1.0 and maybe 1.1 versus
the Nagle algorithm.  As I vaguely recall it, even the proposed modified
Nagle algorithm would still have to be turned off.  That's not the subject
of those articles, is it?

Vernon Schryver    [email-masked]

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 16 Feb 1999 21:55:29 -0800

> My intuition claims there are essentially no real applications that
> fit that sketch

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.

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
WinSock API:
http://www.medusa.uni-bremen.de/intern/knowhow/winsock/winsock4.htm

> I do recall seeing something somewhere about HTTP 1.0 and maybe 1.1
> versus the Nagle algorithm.  As I vaguely recall it, even the
> proposed modified Nagle algorithm would still have to be turned off.

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).

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.

-- 
Eric A. Hall                                            [email-masked]
+1-650-685-0557                                    http://www.ehsco.com

---

From: [email-masked]
Date: Wed, 17 Feb 1999 07:39:01 -0500

On Tue, Feb 16, 1999 at 08:16:17PM -0700, Vernon Schryver wrote:
> Do you have an on-line reference?

Both papers are available at:

http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-97.html

Jon Snader