Re: "RFC 2461bis" issue: MTU handling

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 23 okt 2003, at 11:08, Erik Nordmark wrote:

[Having hosts discover and use a larger than standard MTU between them]

> This might be useful when the L2 doesn't have any MTU limitations.
> For instance, with IP over ATM the default MTU is 9k but AAL5 has a 16 
> bit length field (if I don't misremember). Thus a pair of nodes can 
> agree to use e.g. 37.5k MTU.
Isn't the MTU for IP over ATM something around 4500 bytes? And ATM is 
mostly a point-to-point protocol where hosts with a larger MTU are 
restricted by the need to be compatible with hosts with a regular MTU 
isn't relevant.

> But for links where the L2 has tigher limits things are quite a bit 
> more difficuly. Taking Ethernet as an example. Having two hosts say 
> that they want to use a 9k MTU over Ethernet is fine as long as the 
> bridges/switches on the path all support that.
Yes, this is an important limitation.

> But how can the hosts know that?
The simple solution would be for routers to announce the maximum packet 
size to be used on a subnet.

> Even if the hosts can determine this (send a 9k packet and see if it 
> gets through?), what happens when an addition Ethernet switch or wire 
> comes up (or goes away) and spanning tree changes the L2 path between 
> those two hosts so that the packets no longer go through the same set 
> of bridges/switches?
In theory it should be possible to create some kind of layer 2 PMTUD. 
But in practice I would expect operators to simply limit the MTU for 
the full subnet to the minimum of the MTUs supported by all switches on 
the subnet.

> If one would want to pursue this I think the best way would be for
> IEEE 802 to define a "frame size discovery" protocol at L2 so that
> hosts can robustly determine the frame size a given destination
> MAC address and be notified when it changes.
Such a capability would enhance a layer 3 neighbor MTU management 
capability, but it isn't required. Operators can simply have routers 
annouce an upper limit on the MTU that may be used on a subnet. This 
doesn't impede the best case scenario where all the switches support a 
good sized MTU. Since the number of switches per subnet is typically 
much smaller than the number of hosts per subnet, getting all switches 
to support jumboframes is significantly simpler than getting all hosts 
to do the same.

> But since Ethernet jumboframes are non-standard (even though more and 
> more commonly used it seems) and there is concern about the coverage 
> of the Ethernet CRC for larger frames, the IEEE has been unvilling to 
> look into this.
Well we use a non-(IEEE-)standard way to encapsulate IP in ethernet 
frames (Ethernet II rather than 802.3) so we're not without precedent 
here.

I'm not a math or physics guy, but I'm not necessarily convinced by the 
CRC arguments. The ethernet CRC is pretty strong, it's not going to 
immediately break down at 9000 bytes or so, especially not in wired 
networks with very low bit error rates. And if the IEEE picks this up 
there is no reason they can't drop in a stronger CRC. As for the 
TCP/UDP checksum... yes, this is a problem (even at 1500 or ~4500 bytes 
that many IP over xxx RFCs specify) but why would the IEEE care?

> Once you have such L2 capability then a ND option for "I can receive 
> packets with this MTU" allowing the a larger value than the default 
> link MTU, would make sense to me. But without the L2 capability it 
> doesn't seem very useful.
But what would be the usefulness of such a layer 2 feature if higher 
layers don't take advantage of it? I think it's the other way around: 
having the layer 3 feature is useful in itself, when we have this the 
layer 2 feature is a nice bonus.


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------