[e2e] MTU - IP layer

[Loki Jorgenson]

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