North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Thoughts on increasing MTUs on the internet

  • From: Daniel Senie
  • Date: Thu Apr 12 18:00:28 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