From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dan Cross <cross@math.psu.edu>
Message-Id: <200111261913.OAA11973@augusta.math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Nagle algorithm
In-Reply-To: <87oflu5gez.fsf@becket.becket.net>
References: <20011122132413.0BE83199E7@mail.cse.psu.edu>
Cc:
Date: Mon, 26 Nov 2001 14:13:43 -0500
Topicbox-Message-UUID: 2a2cc21e-eaca-11e9-9e20-41e7f4b1d025

In article <87oflu5gez.fsf@becket.becket.net> you write:
>Well, this is overstated.  The Nagle algorithm (which we should be
>calling "slow start") is actually hugely important on the net as a
>whole; it's the Right Thing, albeit it's wrong for certain kinds of
>rapid response RPC transactions.  But for the *vast* majority of IP
>packets, it's completely right.

Well, Nagle is a localized optimization, essentially.  Slow start is
very different.  I fail to see why it's the right thing to put it in
the TCP if the host can handle essentially the same thing at a different
layer.  For instance, bio would accomplish most of what I'd want Nagle
to do, but not force the policy on me.

>And, incidentally, it's not optional; the Host Requirements RFC's,
>IIRC, require it.

As Forsyth said, it's recommended, but not required.

>> i claim it's not the TCP/IP subsystem's responsibility to delay
>> sending something so that it can buffer up writes to make larger
>> packets.  that's for stdio or bio (or local OS equivalent).
>
>Sadly, that's not adequate for lots of good reasons, too much to go
>into here, but it has been considered, and it's just not enough.

I'm sorry, but I'm afraid that explanation is not adequate.

	- Dan C.