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

From: Vernon Schryver <[email-masked]>
Date: Wed, 17 Feb 1999 14:03:41 -0700 (MST)

> From: Henrik Frystyk Nielsen <[email-masked]>

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

(I assume you mean an explicit flush bit, and not the proposed modification
to the Nagle algorithm itself.)

Are you sure about that?  That you would use it?

First is the problem that the flag would not be available on most
platforms for at least a few years.

Second, for an application I'm hacking, I've been trying to see how I
would use a flag or the proposed change or something else.  As far as I
can tell, nothing does better than simply turning off Nagle, and I bet
the same applies to HTTP.  It's not that you could not use a flush bit,
but that the packet traces and everything else would be essentially the
same as with Nagle off.  So why bother writing code that only works on
those platforms with the flush bit implemented?  Why not forget the
flush bit even when available and just turn off Nagle?

My application involves mostly request-response transactions resulting
from explicit user actions.  Looking at packet traces, I see mostly of

      data -->
	<-- data+Ack
	(delay)
       Ack --> 

with occassional

      extra data --> or <--
      (delay, and possibly Ack packet)
      data -->
	<-- data
       Ack -->

The extra data is necessary, is triggered by various async. events, must
be handled in sequence with the main stuff, and cannot be delayed more
than ~0.3 sec without noticable (objectionable) user interface effects.
I think agressive caching or anticipatory cache filling in something like
HTTP would be similar.

I've mechanims to buffer the extra data in the application, and then write
it with the next request or response in one write().  There are timers to
flush the buffer when no request or response comes along in time.  Still,
I've been unable to avoid turning off Nagle, because if I do emit an extra
data write and then discover I need to send a request, I don't want the
request to be delayed.  If I had a flush flag I could use it on main data,
but that would result in the same packet traces as with Nagle off.
So why bother?

For a day or two, I thought an inverse flush bit, something that says
"delay this segment" would be cool.  But that's no good either.

Vernon Schryver    [email-masked]

---

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Wed, 17 Feb 1999 19:01:40 -0500

>platforms for at least a few years.

That's simple - check for the flag - if it exists then use it, otherwise
drop Nagle.

>flush bit even when available and just turn off Nagle?

I feel we are circling in this thread :) I started out answering Joe Touch
that this is in fact a hard question (the archives don't allow me to refer
to individually archived messages which IMHO is really bad - HTML'ized
archivers come cheap these days and would avoid a lot of circular and
repeated arguments).

Yes, I too do application level buffering with all the problems of figuring
out what a good buffer size is (I ended up using 1K as a compromise). In
most cases this mean I don't need Nagle at all.

But, from an architectural viewpoint, I think it makes a lot more sense if
I didn't have to do that at the application layer and that I instead could
keep the services separated. This means that I need enough control to be
able to indicate what I want - an explicit flush is one of those hooks.
Today, I don't have that so I have to repeat a lot of the functionality in
a layer above and short-circuit things like Nagle in lower layers.

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