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

From: Vernon Schryver <[email-masked]>
Date: Thu, 11 Feb 1999 16:21:48 -0700 (MST)

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

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

Who is urging that applications be smart enough to see REQ2 before
finishing sending RES1?  It's nice to gobble all currently waiting input
before sending your output, but I think it's above and beyond the call of
duty, and edges into geewhiz freaping creaturism territory.

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

With all current and proposed forms of Nagle, right?

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

That is inconsistent with my understanding of Dave Borman's SO_EXPFLUSH
bit.  (PLEASE call it something other than SO_EXPLICITPUSH, because it
has nothing to do with the other PSH thing!)   As I understood it, his
bit would flush data no matter how small.  

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

Yes, and everyone who thinks about a timer immediately looks for something
else, something practical.  It's not as if we don't already know how hard
adaptive timers are, from experience with congestion stuff (even if you're
not impressed by the high costs that such timers impose on large systems).
There are unrelated, very good reasons for an adapative delayed Ack timer
on any shared medium LAN.  When you're pushing lots of data, the reverse
stream of TCP ACK's does terrible things to performance.  For example, on
BLEB 802.3, reducing the Ack rate can be good for a 30% throughput boost.
But ...

  ___________________

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

] ...
] I'd also like to see some sort of wording that says "developers should
] only disable Nagle if they know for certain that they will only be
] generating data that is cumulatively smaller than two full-sized  
] segments, as many writes of small blocks of data will negatively impact
] the network, possibly to the point that performance degradation occurs 
] for all applications (including the disabler)" or something similar.   
] This helps to get the message out.
  
Such words migth be ok in an RFC that is justified on other grounds,
although they seem to me to duplicate RFC 896.  However, I strongly oppose
a purely conscousness raising RFC.  You don't need to get the word out to
people who woud read a new RFC, since they've already RFC 896 and RFC
1122.  Publishing broadsides is statisfying to the already enlightened,
but as we know from watching real life, doesn't do much to raise the
conscousness of those who actually need it.

Has everyone who favors a conscousness raising RFC read RFC 896 and the
relevant parts of RFC 1122?  More words can be less when it comes to
raising consciousness.

Vernon Schryver    [email-masked]

---

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

>duty, and edges into geewhiz freaping creaturism territory.

Welcome to HTTP/1.1 pipelining [1] :)

It's in Apache, Jigsaw, and possibly many other HTTP/1.1 servers.

Henrik

[1] http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 11 Feb 1999 18:35:33 -0800 (PST)

> relevant parts of RFC 1122?  More words can be less when it comes to

Yes, I have read the 2 RFCs.  The reason I suggested a draft on describing the
preferred way to write network application is that many application
programmers do not really understand how TCP works.  Reading those RFCs may 
just confuse them more, as those RFC assumes an understanding of how TCP
works.  And those RFCs do not provide a programming guide line.  By guide line
I mean actual example code.  To me, a document with example code and an
intuitive explanation on why the code is better in simple networking terms
is more suitable for most programmers.  I don't know if there is such a
document freely available on the Web.  If you know, please post a reference.

							K. Poon.
							[email-masked]