[e2e] MTU - IP layer

Cannara cannara at attglobal.net
Thu Apr 21 16:42:25 PDT 2005


This is interesting for its parochial nature, behind TCP/IP blinders.  MTU is
a defined term from way, way back and has nothing specifically to do with any
protocol.  It simply indicates the Maximum Transfer Unit any layer's
implementation can handle.  In other words, each layer's PDU requires an
advertizement of MTU upward and an acceptance of the MTU offered from below.
For the IP world, where 512B seemed to be an important limit from below far
longer than it should have been, this meant implementing Fragmentation of IP
Datagrams.  At higher or lower layers of various protocols, this has been a
reality for many years.  

Alex

Loki Jorgenson wrote:
> 
> OK - I'm convinced that the language is accurate.  Thanks for the
> clarification.  So it may simply be the difference between the
> conceptual and the applied.
> 
> What I've been struggling with are the conflicting requirements to
> resolve MTU as an end-to-end value and to handle framesize/MTU at the
> interface/link layer.  If the reality of IP is such that MTU is
> essentially defined in terms of the link layer, but all the pMTU
> processes operate at the network layer, how does one avoid, for example,
> the problems associated with black holes?
> 
> Where this comes up in our experience is when the confusion of MTU with
> framesize leads to human mistakes being made at mixed MTU boundaries.
> Either switches are put into place to manage the MTU constriction or
> constrictions being accidentally created by miscalculation (9000 byte
> frames instead of 9018).  There is no (effective) mechanism to ensure
> that pMTU is a well-defined entity based on link layer implementaton -
> it tends to be fragile.
> 
> At least by keeping MTU conceptually Layer 3, some of the major pitfalls
> can be avoided, at least at a human level ..... thoughts?
> 
> 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


More information about the end2end-interest mailing list