[95992] in North American Network Operators' Group
Re: Thoughts on increasing MTUs on the internet
daemon@ATHENA.MIT.EDU (Daniel Senie)
Thu Apr 12 18:23:52 2007
Date: Thu, 12 Apr 2007 18:18:56 -0400
To: "David W. Hankins" <David_Hankins@isc.org>, nanog@merit.edu
From: Daniel Senie <dts@senie.com>
In-Reply-To: <20070412220956.GF18633@isc.org>
Errors-To: owner-nanog@merit.edu
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."
