From owner-freebsd-hackers Sun Jan 11 15:34:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA18762 for hackers-outgoing; Sun, 11 Jan 1998 15:34:39 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA18708 for ; Sun, 11 Jan 1998 15:34:24 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id QAA16531; Sun, 11 Jan 1998 16:34:05 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id QAA13202; Sun, 11 Jan 1998 16:33:15 -0700 (MST) Date: Sun, 11 Jan 1998 16:33:15 -0700 (MST) From: Marc Slemko To: Snob Art Genre cc: hackers@FreeBSD.ORG Subject: Re: why 100 byte TCP segments? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk Aha. Yes, section 14.11. He suggests either knocking MINCLSIZE down to 101, increasing the size of a mbuf from 128 to 256 bytes, or changing sosend to avoid sending multiple packets when mbufs (instead of mbuf clusters) are being used. The last one may be a better solution, but the first is easier. I can't see much in the way of bad side effects offhand to changing MINCLSIZE... certainly not compared to how annoying this is. It sucks when it triggers slow start or Nagle especially with delayed acks. On Sun, 11 Jan 1998, Snob Art Genre wrote: > 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.