[e2e] MTU - IP layer

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Loki Jorgenson wrote:
> Hmmmmmm - that's an interesting reading of RFC 791 - and the distinction
> of fragments over datagrams could be made in that way.
> 
> 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.

But that's exactly the difference between a datagram fragment and the
entire datagram, when the datagram is larger than the MTU. Fragments are
smaller than the L2 MTU, but datagrams are smaller than the L3
'framesize' - whatever we want to call that. ;-)

Joe

> 
> Prehaps I'm favouring the pragmatic over the precise....
> 
> 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
> 
> 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

iD8DBQFCaBTTE5f5cImnZrsRAn7wAJ0Qx8njXuW53Z6biPzVrgkFecROngCeOcPk
hQSXcr8aQWhVwgYWlDqjVhw=
=rnwt
-----END PGP SIGNATURE-----