Thoughts on increasing MTUs on the internet

Daniel Senie dts at senie.com
Thu Apr 12 22:18:56 UTC 2007


At 06:09 PM 4/12/2007, David W. Hankins wrote:

>On Thu, Apr 12, 2007 at 05:58:07PM -0400, Daniel Senie wrote:
> > >> 2. It's no longer necessary to manage 1500 byte+ MTUs manually
> > >
> > >But for this, there has been (for a long time now) a DHCPv4 option
> > >to give a client its MTU for the interface being configured (#26,
> > >RFC2132).
> >
> > Trying to do this via DHCP is, IMO, doomed to failure. The systems
> > most likely to be in need of larger MTUs are likely servers, and
> > probably not on DHCP-assigned addresses.
>
>If you're bothering to statically configure a system with a fixed
>address (such as with a server), why can you not also statically
>configure it with an MTU?

Neither addresses interoperability on a multi-access medium where a 
new station could be introduced, and can result in the same MTU/MRU 
mismatch problems that were seen on token ring and FDDI. The problem 
is you might open a conversation (whatever the protocol), then get 
into trouble when larger data packets follow smaller initial 
conversation opening packets.

Or you can work with the same assumptions people use today: all 
stations on a particular network segment must use the same MTU size, 
whether that's the standard Ethernet size, or a larger size, and a 
warning sign hanging from the switch, saying "use MTU size of xxxx or 
suffer the consequences." 




More information about the NANOG mailing list