(This rough draft is only a place keeper)

Protocols

These are MTU limits that are a direct consequence of protocol specifications. These are generally impossible to correct except by redeploying the protocol.

• IPv4 - The IPv4 packet length field is 16 bits, limiting the MTU to 65535 bytes.

• IPv6 - The extended length option provides for a 32 bit length field, supporting packets up to 4294967295 bytes.

Explicit Limits In Hardware Standards

These are MTU limits that are a directly specified in hardware standards. In most cases there is an obvious way to build hardware that extends the standard. However, it is crucial that the hardware enforces some explicit maximum frames size such that all frames also fall within the (adapted) implicit limits, as described below.

• All Ethernet protocols (IEEE 802.3xxx) explicitly limit frames to 1500 bytes.

• . . .

Implicit HW Limits

These are potential frame size limits that are indirect consequences of other details in HW standards. If these are not adapted carefully they will lead to implementations that seem to work (often delivering large frames) but that are no longer guaranteed to do so under all operating conditions. This sort of failure is extremely serious and absolutely must be avoided.

• In (all?) Ethernet standards there are separate specifications for MTU, clock stability and some sort of rate adaption FIFO. The FIFO is used to compensate for the fact that the clocks have only finite accuracy (typically specified as plus or minus 100 parts per million). If you raise the MTU, you have to either tighten the clock stability or lengthen the rate adaption FIFO, otherwise the hardware will nondeterministically fail to deliver large frames. Beware that the two possible ways to adapt the standard (better clock stability or larger FIFO) do not lead to implementations that are guaranteed to interoperate.

• In (all?) Ethernet standards the inter-frame-gap is used to reset the rate adaption FIFO. If the FIFO is made larger, perhaps the senders minimum inter-frame-gap needs to be larger (or perhaps the receivers minimal allowed inter-frame-gap should be smaller).

We believe that there should be specifications (standards?) on how to adapt existing standards to support larger frames. Otherwise there is a risk that different implementations will make incompatible adaptations in less obvious parts of the standards, or worse no adaption at all.

Implementations

For the moment this will only list examples of design elements that limit MTU. As an effort to future proof products, all network hardware vendors are encouraged to consider and avoid these where ever possible. This list is approximately in order from least to most serious.

• SW compile time constants.

• Insufficient field widths in data structures.

• Reusing high bits above length fields in data structures.

• Insufficient bits in HW length count registers.

• Insufficient buffer memory.

• Insufficient address bits to the buffer memory.

• Not planing ahead on rate adaption FIFO sizes.

• No provisions for buffer chaining within a frame (But note that this one item doubles HW costs).

• HW interface registers that reuse high bits above length fields. These lead to really ugly SW-HW version interlocks.

For additional information check out these pages: Raising the Internet MTU, Pittsburgh Supercomputing Center, Network research at PSC, or Matt Mathis. Please send comments and suggestions to mathis@psc.edu.