[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reopening jumbo frames in IS-IS

Thus spake "Curtis Villamizar" <curtis at faster-light.net> 
In message <42D7ECF3.3010406 at sun.com>
Radia Perlman writes:

What are the technical reasons that IEEE does not like large
packets?


Is existing hardware a technical reason?  It seems to be a good excuse
to not change things in incompatible ways in the IETF so I'd think
that IEEE could use the same reason.  At the very least, disabling by
default should be a requirement (again imho).

The IETF also has a history of allowing incompatible changes in protocols _provided that there is a mechanism to first determine if those changes are supported on both ends_.

It seems fair to me to allow jumbos to be on by default iff there were a standard means to determine that the other host also supports them.

I was only aware of the long standing ISP issue with jumbo frames but
not the data center issues that Tony and Brian brought up so I'll step
aside on further conversations about whether jumbo frames are needed
in end systems.

I am mainly familiar with jumbos used in HPC, though I've also seen them used on "back side" networks used for backups or file serving. Communication between application and DB servers is similar and doesn't surprise me. However, all cases I'm aware of are closed networks with processes for _humans_ to ensure that all hosts support a nonstandard MTU. Jumbos can't move to general use until humans are removed from the loop.

Also, there are large numbers of routers (and "L3 switches") that are limited in the number of pps they can handle. Jumbos allow a higher bandwidth for the same pps. OTOH, as more applications with small packets (e.g. VoIP) come around, we may need jumbos just to maintain current pps levels on a given pipe.

S

Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov