Existing MTU Limits
(This rough draft is only a place keeper)
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
- 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
- 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.
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.
This page is http://www.psc.edu/~mathis/MTU/limits.html.
For additional information check out these pages:
Raising the Internet MTU,
Pittsburgh Supercomputing Center,
Network research at PSC, or
Please send comments and suggestions to email@example.com.