[e2e] MTU - IP layer

[Bob Braden]

  *> 
  *> 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
buying... ;-))

  *> 
  *> Prehaps I'm favouring the pragmatic over the precise....
  *> 

Quite the opposite, in fact.

Bob Braden

  *> Loki
  *> 
  *> -----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.
  *> 
  *> Joe
  *> 
  *> 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
  *> layer
  *> > 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
  *> differing
  *> > 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
  *> ayboad
  *> > 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
  *> header/trailer
  *> > 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
  *> overhead
  *> > 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
  *> 
  *> iD8DBQFCaA0tE5f5cImnZrsRAow8AJ4pWCIAqdCRFbQDAhbm4+z1SaZzbACfSvb/
  *> XZXMcs7Veyt+qS6RdSEzzeU=
  *> =kDKI
  *> -----END PGP SIGNATURE-----
  *>