Date: Thu, 10 Sep 1998 08:37:22 -0700
From: jg@pa.dec.com (Jim Gettys)
Message-Id: <9809101537.AA20888@pachyderm.pa.dec.com>
To: new-httpd@apache.org
Cc: Simon Spero <ses@mossflower.oit.unc.edu>
In-Reply-To: <Pine.SUN.4.00.9809100144560.19320-100000@tipper.oit.unc.edu>
Subject: Re: Apache 2.0/NSPR
Mime-Version: 1.0
Content-Type: text/plain
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


> Sender: new-httpd-owner@apache.org
> From: Simon Spero <ses@mossflower.oit.unc.edu>
> Date: Thu, 10 Sep 1998 01:46:21 -0400 (EDT)
> To: new-httpd@apache.org
> Subject: Re: Apache 2.0/NSPR
> -----
> yeah-i would have said that if my head worked better at the moment. this
> fits in o the send side buffer management.
> 
> simon
> On Wed, 9 Sep 1998, Dean Gaudet wrote:
> 
> >
> >
> > On Thu, 10 Sep 1998, Simon Spero wrote:
> >
> > > 7) TCP changes: There are several changes that would be useful for a web
> > > server.
> >
> > You forgot:
> >
> > 7.n) Get rid of Nagle, and get rid of auto-flush-on-write().  Allow the
> > app to tell the kernel when it's at the end of what it's sending...
> > there's no need for silly timers and that crud like in Nagle when the app
> > is well behaved.
> >
> > Dean
> >

Yes, turn off Nagle once you do your own buffering...

I did have a conversation with a TCP wizard  (can't remember if
it was Van, or possibly Greg Minshall) at SIGCOMM a year ago though: 
the problem with Nagle may not be exactly what we thought and say
in our SIGCOM paper...  

A properly done Nagle implementation may not in fact be slowing down the 
connections; but what does happen is that the "every other packet" ack 
policy implemented by most TCP's interacts with Nagle, such that if it 
is an odd packet, you get a major delay at the END of a conversation (the 
application has flushed, but the OS holds onto the data).

The comment of this wizard was that the every other packet acking 
optimization in TCP has been a lose (you get poorer  clocking of data, 
and possibly slower slow start behavior than if every packet is acked).

We tried to get a final verdict on exactly what is causing the observed
delays in our TCP dumps from Van Jacobsen, but he's never gotten back
to us, and the effect is the same: Nagle should be disabled in any
case, and isn't needed once you have sane buffering, flushing and
timeouts at a higher level where you know more.
			- Jim