Date: Wed, 14 Aug 2002 08:17:02 -0400 From: Barney Wolff <barney@tp.databus.com> To: Mike Silbersack <silby@silby.com> Cc: Oleg Polyakov <opolyakov@yahoo.com>, freebsd-net@FreeBSD.ORG Subject: Re: Initial congestion window increase Message-ID: <20020814121701.GA27934@tp.databus.com> In-Reply-To: <20020814003743.U93223-100000@patrocles.silby.com> References: <20020812192549.24783.qmail@web10409.mail.yahoo.com> <20020814003743.U93223-100000@patrocles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
You're assuming that the jumbo will be the successful MTU. But at the start of a connection PMTUD has yet to run, and you could be sending jumbos into a choppy link somewhere on the path. The tcp-impl IETF WG had (and the email list still has) a very smart bunch of people with decades of experience with TCP. Those RFCs didn't just come out of somebody's idle thought. Slowstart flightsize doesn't matter a whole lot on a lan (as long as it's at least 2 to compensate for delayed ack) other than for locker-room comparisons with Linux. But it does matter a lot on long pipes, whether fat or thin, and that's where the risk of an overaggressive strategy is that you can congest the Internet. On Wed, Aug 14, 2002 at 12:44:28AM -0500, Mike Silbersack wrote: > > Incidently, I think that the formula > > min (4*MSS, max (2*MSS, 4380 bytes)) > > is bogus. We really have three cases: > > MTU 512 bytes > MTU 1500 bytes (and 1480 or whatever PPPoE uses) > MTU 9000 bytes (jumbo frames) > > The formula above would penalize jumbo frames, while sending a lot of > packets for the 512 byte case. Just using MSS * X, where X is a constant > for all of the above seems like a better idea. -- Barney Wolff I'm available by contract or FT: http://www.databus.com/bwresume.pdf To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020814121701.GA27934>