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

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Thu, 11 Feb 1999 16:29:19 -0500

At 14:48 2/3/99 -0800, Joe Touch wrote:

>>    This draft is NOT suggesting that these applications should disable
>>    the Nagle algorithm.
>
>Why not?

This is actually a hard question to answer.

>Nagle was a solution to char-at-a-time remote logins, and
>is discouraged for transactional systems, even ones with
>bursts as small as a few characters, e.g., X11.

In HTTP the size of requests and responses vary arbitrarily from message to
message so even though the proposed change fixes the particular problem of
the odd, small final segment in Apache, it is always possible to find
scenarios where Nagle is triggered to delay packets even though it is not
desired.

If I understand correctly then the following HTTP pipeline example will
trigger Nagle into delaying the 2nd response:

	client			server
	HTTP REQ 1	-->	
			<--	1st segment of RES 1
	HTTP REQ 2	-->
			<--    last 1.25 segment of RES 1
			<--	0.25 segment RES 2 delayed

From (at least a Web) application point of view, the main problem is
actually not Nagle itself but the fixed delay (at least in the sense that
it isn't adjusted to fit the link). Risking this delay is likely to have
app writes disable Nagle regardless of the proposed change or not. One
solution would be to adjust the delay but knowing timers, this is normally
not an easy task.

Instead, added control at the application layer would be of tremendous help
as the app is likely to know what it going on. In other words, I like the
SO_EXPLICITPUSH flag idea a lot and think that it would solve at least our
needs.

Henrik

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

---

From: Greg Minshall <[email-masked]>
Date: Thu, 11 Feb 1999 14:15:48 -0800

Henrik,

The modification to Nagle is designed to help lock-step request/response 
protocols (such as HTTP used in a non-pipelined fashion(**)).

Your example is:
----
	client			server
	HTTP REQ 1	-->	
			<--	1st segment of RES 1
	HTTP REQ 2	-->
----

If httpd had seen REQ 2, then i think it should have done one send which had 
the 1.25 RES 1 and the 0.25 RES 2.

If httpd had not seen REQ 2, then you are right, the 0.25 RES 2 will be 
delayed.

Notice, however, that if you were using something like SO_EXPLICITPUSH, and 
you set SO_EXPLICITPUSH for the 1.25 RES 1, and then turned around and set 
SO_EXPLICITPUSH for the 0.25 RES 2, *my* [fictional] implementation would 
*also* delay the 0.25 RES 2.  (This is because i would be using 
SO_EXPLICITPUSH as a way to *avoid* sending < MSS packets, but would *still* 
be protecting the network from excess traffic from small packets.)

Having an adaptive delayed ack scheme is an interesting idea (that others, 
including John Nagle recently, have thought about).  I don't know if it would 
be based on link speed, "one-way-ness" of application traffic, or what.  It is 
independent of the Nagle modification.

Greg

(**) Any idea how much HTTP is pipelined these days, or what the trend is?

---

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Thu, 11 Feb 1999 17:49:53 -0500

>If httpd had not seen REQ 2, then you are right, the 0.25 RES 2 will be 

Yes, it is a timing issue, you are right.

>be protecting the network from excess traffic from small packets.)

Hmm, I think a simple write-through mechanism would be easier to deal with.
Isn't the point exactly that the app knows it is a small packet but it
wants it to go out anyway because it is "the Right Thing" in that
particular situation?

>independent of the Nagle modification.

...

>(**) Any idea how much HTTP is pipelined these days, or what the trend is?

In HTTP itself, there are only a few clients that do pipelining - roughly
speaking applications based on my libwww code

	http://www.w3.org/Library/

The major argument against it on client side is that it is (too) hard to
implement (one reason being that HTTP/1.1 has 5 different ways of
delimiting messages). As it is significantly simpler on server side, this
is much more commonly supported.

However, if work on WebMUX is truly starting in the IETF, a lot of the
complexity will go away as WebMux has a much better handle on the message
length. In that case, pipelining is likely to become much more common than
it is now.

Henrik