Re: MAE-EAST Moving? from Tysons corner to reston VA.

["Richard A. Steenbergen" <ras () e-gerbil net>]

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)