[29317] in North American Network Operators' Group
Re: MAE-EAST Moving? from Tysons corner to reston VA.
daemon@ATHENA.MIT.EDU (Richard A. Steenbergen)
Sat Jun 17 01:04:01 2000
Date: Sat, 17 Jun 2000 01:01:29 -0400 (EDT)
From: "Richard A. Steenbergen" <ras@e-gerbil.net>
To: Ted Schroeder <teds@netcom.com>
Cc: Wayne Bouchard <web@typo.org>, nanog@merit.edu
In-Reply-To: <394AFE61.6C8969D8@netcom.com>
Message-ID: <Pine.BSF.4.21.0006170035050.95120-100000@pkitty.e-gerbil.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
On Fri, 16 Jun 2000, Ted Schroeder wrote:
> As one of the early evangelists for jumbo frames I can say with
> some amount of authority that the number we (Alteon WebSystems)
> were/are pushing for is 9000 bytes. There are other numbers bandied
> about, but 8940 was never one of them. 9216 was the other usual
> candidate as it matches up with ATM.
Come to think of it I can't see any good reason for 8940. FDDI is
4352, FDDI*2 is 8704. 9216 should behave nicely w/AAL5.
> The IEEE will simply say, "only up to 1500 bytes". I've fought this
> battle with very little success. Rich's book will only talk about 1500
> bytes. I've spoken to him about this a number of times and he's
> personally opposed to anything other than 1500 bytes.
I know there is a discussion of jumbo frames there, and its not terribly
negative from what I can recall.
> And, for those of you who think that things might get better in the future,
> let me be an omen for even worse times to come. For 10 Gb Ethernet,
> there are proposals on the table that will, for the first time, make frames
> larger than 1522 bytes physically impossible. These proposals have to
> do with speed matching between the WAN 10GE and the LAN 10GE
> and minimum buffer sizes used to accomplish this speed matching.
>
> As one of the lone voices at the 802.3 meetings calling for longer frame
> support, I've pretty much given up on ever seeing a longer MTU officially
> supported by the IEEE. Perhaps if more people were going there that
> weren't hardware vendors with an "obvious interest in only pushing
> their products" the IEEE members would be more likely to listen. But
> I wouldn't necessarily bet on it. There was a push early on during PAR
> discussions of 10 GE to allow larger frames but it was clear that this
> was a losing battle, so the push ended.
Ugh, from an all around perspective I believe we need an MTU offically
longer then 15??. Its better for applications, better for operating
systems, better for anything that must be interrupted per frame/packet,
better for anything which needs to work paged memory, and better for
anything which needs to do routing per packet.
9000-range works well for server to server or backbone to backbone
connections where you're aiming for NFS optimization or being able to
support large packets without fragmentation across a NAP for example, but
I would suggest you're aiming for trouble trying to take server-traffic
past what is supported by FDDI/PoS, and 4k works well for many of the
above problems. The standardization of a higher number is needed, or we
are just going to see more of these problems as people seek to improve
their networks in incompatible and confusion-introducing ways.
PMTU-D has obvious problems. It would seem to me the cleanest course of
action would be to put a fragmentation encountered flag somewhere along
the line.
--
Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/humble
PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
