[e2e] MTU - IP layer
braden at ISI.EDU
Thu Apr 21 14:32:22 PDT 2005
*> My observation remains that MTU is conceptually defined and implemented
*> at Layer 3. Making pains to define it in Layer 2 terms in order to
*> ensure its scope includes all valid cases makes sense - and yet I find
*> it challenged. Promoting the subtle distinction of "Frame payload" over
*> "packet/datagram" doesn't seem beneficial.
You are not getting the point. This is a completely correct
distinction, and it is not subtle. IP permits a link layer frame to be
longer (but not shorter) than the IP datagram it contains. There is
NOT a necessary equality between layer 2 frame size and layer 3
datagram size. That is (one reason) why an IP header contains a length
field; it cannot just assume the length field provided by the link
layer (the way TCP inherits the length from IP).
We thrashed this point out in 1978 when TCP/IP was being designed.
On another issue in this thread, MSS is specific to TCP, because the
definition of a "segment" is TCP-specific. (I once tried to convince
Jon Postel that "segment" was a superfluous term, but he was not
*> Prehaps I'm favouring the pragmatic over the precise....
Quite the opposite, in fact.
*> -----Original Message-----
*> From: Joe Touch [mailto:touch at ISI.EDU]
*> Sent: Thursday, April 21, 2005 1:30 PM
*> To: Loki Jorgenson
*> Cc: end2end-interest at postel.org
*> Subject: Re: [e2e] MTU - IP layer
*> -----BEGIN PGP SIGNED MESSAGE-----
*> Hash: SHA1
*> L3 packet size isn't referred to as MTU, esp. in IP (rfc791); it is
*> datagram length (or total length).
*> Fragments in IP must be less than or equal to the MTU, which there (791)
*> refers to the max payload of the L2.
*> path MTU discovery is equivalent to path "max link payload" discovery,
*> rather than path "max network payload" discovery.
*> IMO, therefore, MTU really refers to the L2 payload size, which is not
*> the same as the L3 'frame' size (size of the total IP packet), but is
*> related to the size of an L3 fragment.
*> Loki Jorgenson wrote:
*> > Minor note - MTU is technically Layer 3 (as opposed to link layer or
*> > layer 2). So it is quite correct to describe the MTU as the link
*> > payload size. So, as noted, 1518 bytes is the frame size at layer 2.
*> > However, it is very important to keep in mind that MTU and path MTU
*> > discovery operate at Layer 3. For example, boundaries between
*> > MTUs should be handled by Layer 3 devices (not switches) to avoid
*> > end-to-end issues that can arise.
*> > Loki
*> > ----
*> > "Joe Wrote:"
*> > Date: Thu, 21 Apr 2005 09:28:28 -0700
*> > From: Joe Touch <touch at ISI.EDU>
*> > Subject: Re: [e2e] Question on MTU
*> > To: Arjuna Sathiaseelan <arjuna.sathiaseelan at gmail.com>
*> > Cc: end2end-interest at postel.org
*> > Message-ID: <4267D4AC.8090503 at isi.edu>
*> > Content-Type: text/plain; charset=ISO-8859-1
*> > MTU usually refers to a link layer, and denotes the maximum link
*> > size, excluding link header/trailer info. For Ethernet, such
*> > header/trailers include:
*> > - 14 byte header
*> > - 4 byte 802.1q (VLAN) tag
*> > - 4 byte CRC
*> > Standard ethernet has 1518 byte frames, but 802.1q ethernet has 1522
*> > byte frames. From the link frame size, subtract the link
*> > to get the MTU. Standard ethernet has an MTU of 1500 bytes, but there
*> > are jumbograms of 9,000 bytes in the extended ethernet spec.
*> > MSS usually refers to a transport protocol, e.g., TCP, and denotes the
*> > max payload size there too. It is also relative to the network (IPv4,
*> > IPv6) protocol _and_ link layer used.
*> > And just as link layer overhead sizes vary, so do network layer
*> > sizes (minimums of 20 for IPv4, 40 for IPv6 - larger if options are
*> > included, e.g., 48 for IPv6 with jumbogram option).
*> -----BEGIN PGP SIGNATURE-----
*> Version: GnuPG v1.2.4 (MingW32)
*> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
*> -----END PGP SIGNATURE-----
More information about the end2end-interest