Thoughts on increasing MTUs on the internet

Daniel Senie dts at senie.com
Thu Apr 12 21:58:07 UTC 2007


At 05:28 PM 4/12/2007, David W. Hankins wrote:

>Hopefully I'll be forgiven for geeking out over DHCP on nanog-l twice
>in the same week.
>
>On Thu, Apr 12, 2007 at 11:20:18AM +0200, Iljitsch van Beijnum wrote:
> > 1. It's no longer necessary to limit the subnet MTU to that of the
> > least capable system
>
>I dunno for that.

Indeed. I do hope the vocal advocates for general use of larger MTU 
sizes on Ethernet have had in their careers the opportunity to enjoy 
the fun that ensues with LAN technologies were multiple MTUs are 
supported, namely token ring and FDDI. Debugging networks where MTU 
and MRU mismatches occur can be interesting, to say the least.

It's not just a matter of receiving stations noticing there's packets 
coming in that are too big. Depending on the design of the interface 
chips, the packet may not be received at all, and no indication sent 
to the driver. The result can be endless re-sending of information, 
doomed to failure.

OSPF has a way to negotiate MTU over LAN segments to deal with 
exactly this situation. I uncovered the problem debugging a largish 
OSPF network that would run for weeks or months, then fail to 
converge. Multi-access media benefits from predictable MTU/MRU sizes. 
Ethernet was well served by the fixed size.

I have no issue with allowing for a larger MTU size, but disagree 
with attempts to reduce everyone on the link to the lowest common 
denominator UNLESS that negotiation is repeated periodically (with 
MTU sizes able to both increase and decrease). If systemns negotiate 
a particular size among all players on a LAN, and a new station is 
introduced, the decision process for what to do must be understood.

An alternative is to limit everyone to 1500 byte MTUs unless or until 
adjacent stations negotiate a larger window size. At the LAN level, 
this could be handled in ARP or similar, but the real desire would be 
to find a way to negotiate endpoint-to-endpoint at the IP layer. 
Don't even get into IP multicast...


> > 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).
>
>The thing is, not very many (if any) clients actually request it.
>Possibly because of problem #1 (if you change your MTU, and no one
>else does, you're hosed).

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.


>So, if you solve for the first problem in isolation, you can
>easily just use DHCP to solve the second with virtually no work
>and probably "only" (heh) client software updates.
>
>
>I could also note that your first problem plagues DHCP software
>today...it's further complicated...let's just say it sucks, and
>bad.
>
>If one were to solve that problem for DHCP speakers, you could
>probably put a siphon somewhere in the process.
>
>But it's an even harder problem to solve.

DHCP has enough issues and problems today, I think we're in agreement 
that heaping more on it might not be prudent.

Dan




More information about the NANOG mailing list