Re: Smallest Transit MTU

[Fred Baker <fred () cisco com>]

At 01:43 PM 12/29/04 -0500, Joe Abley wrote:
> > Is there an RFC that clearly states: "The internet needs to transit 1500 
> > byte packets without fragmentation."??
>
> Not to my knowledge, and since the hoardes of users mentioned above 
> present a clear, deployed counter-example it seems unlikely that one will 
> be written.

There are any number of RFCs that state that implementations SHOULD 
implement the capability to receive a 1500 byte payload on just about any 
link, and that the interface MTU or MRU SHOULD default to no smaller than 
that number.

That said, RFC 1042 ("Standard for the transmission of IP datagrams over 
IEEE 802 networks.") notes that

   Note that the MTU for the Ethernet allows a 1500 octet IP datagram,
   with the MTU for the 802.3 network allows only a 1492 octet IP
   datagram.

For an RFC to require an MTU of 1500 octets without fragmentation would 
imply requiring it to not use IEEE 802.3 framing, which is to say, not use 
802.1d (used to be p/q) prioritization. It would also require one to not 
use CPE-CPE tunnels (which often means "VPNs"), as such tunnels add an 
additional IP header (at least), reducing the MTU within the tunnel by that 
amount.

To be honest, I think we should be carefully considering Mathis' newer 
approach to Path MTU, described in 
http://www.psc.edu/~mathis/MTU/pmtud/draft-mathis-pmtud-method-00.txt and a 
more recent but expired internet draft.

   The general strategy of the new algorithm is to start with a small
   MTU and probe upward, testing successively larger MTUs by probing
   with single packets.  If the probe is successfully delivered, then
   the MTU is raised.  If the probe is lost, it is treated as an MTU
   limitation and not as a congestion signal.

The table in 5.7.1 appears wrong (it list 1492 as an MSS candidate, but 
neither 1460 nor 1500, so I find it rather incomprehensible). But the 
concept seems reasonable.