From owner-freebsd-hackers  Sun Jan 11 15:25:44 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA17831
          for hackers-outgoing; Sun, 11 Jan 1998 15:25:44 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from echonyc.com (echonyc.com [198.67.15.2])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA17824
          for <hackers@FreeBSD.ORG>; Sun, 11 Jan 1998 15:25:33 -0800 (PST)
          (envelope-from benedict@echonyc.com)
Received: from localhost (benedict@localhost)
	by echonyc.com (8.8.7/8.8.7) with SMTP id SAA04975;
	Sun, 11 Jan 1998 18:25:28 -0500 (EST)
Date: Sun, 11 Jan 1998 18:25:28 -0500 (EST)
From: Snob Art Genre <benedict@echonyc.com>
To: Marc Slemko <marcs@znep.com>
cc: hackers@FreeBSD.ORG
Subject: Re: why 100 byte TCP segments?
In-Reply-To: <Pine.BSF.3.95.980111153144.10734d-100000@alive.znep.com>
Message-ID: <Pine.GSO.3.96.980111182400.333C-100000@echonyc.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk

Oh yeah, doesn't Stevens talk about this in TCP/IP Illustrated Vol. 3?
It's a particularly obnoxious problem because HTTP traffic so often falls
into the bad range.

Does anyone have any ideas/motivation to fix this, or should I start
researching it myself?  :-)

On Sun, 11 Jan 1998, Marc Slemko wrote:

> Yup, this seems to happen only with data between one and two mbuffs
> in size, ie.  101-207 bytes or so.  Smaller and it fits in one
> packet, between 208 and the MTU it is properly sent in one packet.
> 
> On Sat, 10 Jan 1998, Marc Slemko wrote:
> 
> > Note the below tcpdump:
> > 
> > 21:05:47.748479 valis.worldgate.com.1034 > testbed.worldgate.com.http: S 761734757:761734757(0) win 16384 <mss 1460> (DF)
> > 21:05:47.748749 testbed.worldgate.com.http > valis.worldgate.com.1034: S 1887037484:1887037484(0) ack 761734758 win 17520 <mss 1460> (DF)
> > 21:05:47.749793 valis.worldgate.com.1034 > testbed.worldgate.com.http: . ack 1 win 17520 (DF)
> > 21:05:47.749809 valis.worldgate.com.1034 > testbed.worldgate.com.http: P 1:101(100) ack 1 win 17520 (DF)
> > 21:05:47.749823 valis.worldgate.com.1034 > testbed.worldgate.com.http: FP 101:139(38) ack 1 win 17520 (DF)
> > 21:05:47.749837 testbed.worldgate.com.http > valis.worldgate.com.1034: . ack 140 win 17482 (DF)
> > 21:05:47.752540 testbed.worldgate.com.http > valis.worldgate.com.1034: F 1:1(0) ack 140 win 17520 (DF)
> > 21:05:47.766014 valis.worldgate.com.1034 > testbed.worldgate.com.http: . ack 2 win 17520 (DF)
> > 
> > valis is a FreeBSD 2.2 box.  The same thing happens on boxes from 2.1.5 to
> > 2.2.5.  Don't have a -current box to try it...
> > 
> > The connection was generated by the below program.  Note that it is
> > a single write() or send() call that generates the data, yet it
> > is split into two packets.
> > 
> > While it isn't a big deal here, I noticed this when I was using a simple
> > web benchmark program (ZeusBench) that doesn't disable the Nagle
> > algorithm.  In that example, the server was delaying its ack (standard
> > 200ms) and the client wasn't sending the second part of the request (due
> > to Nagle) so you could only get 5 reqs/sec on a persistent connection, ie.
> > multiple sequential requests on one TCP connection.  Disabling Nagle fixed
> > this of course. 
> > 
> > Why is this happening?  Is it just a coincidence that 100 bytes
> > is the size of the data area in the first mbuf in a chain?
> > 
> > Has it been fixed in -current or should I dig deeper...
> > 
> 
> 



 Ben

"You have your mind on computers, it seems."