From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Nagle algorithm
From: forsyth@caldo.demon.co.uk
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="upas-gpegfbngdounyypkusizwdubrf"
Message-Id: <20011124104817.79873199B9@mail.cse.psu.edu>
Date: Sat, 24 Nov 2001 10:48:12 +0000
Topicbox-Message-UUID: 28bfb238-eaca-11e9-9e20-41e7f4b1d025

This is a multi-part message in MIME format.
--upas-gpegfbngdounyypkusizwdubrf
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

not only that, but the Nagle algorithm explicitly ignores the PSH bit
anyway:

                 The Nagle algorithm is generally as follows:

                      If there is unacknowledged data (i.e., SND.NXT >
                      SND.UNA), then the sending TCP buffers all user
                      data (regardless of the PSH bit), until the
                      outstanding data has been acknowledged or until
                      the TCP can send a full-sized segment (Eff.snd.MSS
                      bytes; see Section 4.2.2.6).


--upas-gpegfbngdounyypkusizwdubrf
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: <9fans-admin@cse.psu.edu>
Received: from punt-1.mail.demon.net by mailstore for forsyth@caldo.demon.co.uk
          id 1006580009:10:23830:0; Sat, 24 Nov 2001 05:33:29 GMT
Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-1.mail.demon.net
           id aa1103420; 24 Nov 2001 5:33 GMT
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.18.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id A0CF819AAB; Sat, 24 Nov 2001 00:33:13 -0500 (EST)
Delivered-To: 9fans@cse.psu.edu
Received: from plan9.cs.bell-labs.com (plan9.bell-labs.com [204.178.31.2])
	by mail.cse.psu.edu (CSE Mail Server) with SMTP id 2D3F019A57
	for <9fans@cse.psu.edu>; Sat, 24 Nov 2001 00:32:33 -0500 (EST)
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Nagle algorithm
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20011124053233.2D3F019A57@mail.cse.psu.edu>
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.7
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Help: <mailto:9fans-request@cse.psu.edu?subject=help>
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <http://lists.cse.psu.edu/archives/9fans/>
Date: Sat, 24 Nov 2001 00:32:31 -0500

> > 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).
>
> If there was a way for the user say when to set TCP's PUSH bit,
> would that do the job?

Why would you want this?  I thought the above
was a very effective argument.

Russ
--upas-gpegfbngdounyypkusizwdubrf--