Home page logo

nanog logo nanog mailing list archives

Re: MAE-EAST Moving? from Tysons corner to reston VA.
From: "Richard A. Steenbergen" <ras () e-gerbil net>
Date: Sat, 17 Jun 2000 01:01:29 -0400 (EDT)

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)

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]