[76794] in North American Network Operators' Group
Re: Smallest Transit MTU
daemon@ATHENA.MIT.EDU (Fred Baker)
Wed Dec 29 16:27:39 2004
Date: Wed, 29 Dec 2004 13:25:37 -0800
To: Joe Abley <jabley@isc.org>
From: Fred Baker <fred@cisco.com>
Cc: Jerry Pasker <info@n-connect.net>, nanog@merit.edu
In-Reply-To: <904C6A26-59C9-11D9-BF97-000D93B24C7A@isc.org>
Errors-To: owner-nanog-outgoing@merit.edu
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.
