[e2e] MTU - IP layer

Joe Touch touch at ISI.EDU
Thu Apr 21 17:20:22 PDT 2005

Hash: SHA1

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 Bob said ;-)

> 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.

MTU is a link payload issue. Path MTU is the min of the MTUs on the
path; it is path MTU that is defined E2E.

> 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?

I'm not sure one has anything to do with the other. The only way to
_know_ you will avoid a black hole is to send the smallest IP packets
possible - 68 bytes. You can do this by sending small datagrams (28
byte), or by sending larger datagrams and fragment them.

Short of that, the only other way is POSITIVE feedback - try larger
packets and see what gets through. If it does, report back and use that
size. That's already under consideration in the IETF "pmtud" working group.

Using NEGATIVE feedback - the absence of error messages bouncing large
packets - is what is currently used, and that is what is susceptible to
black holes, because black holes look like a successful transmission.

> 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.

That's what automated PMTUD is supposed to fix ;-)

> 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.

That, again, is because paths are not link concepts, so pMTU isn't
defined at the link layer.

> At least by keeping MTU conceptually Layer 3, some of the major pitfalls
> can be avoided, at least at a human level ..... thoughts?

IMO, there's no benefit to human management possible; automated systems
are the key. The major pitfall, IMO, is trying to track this with brain
cells ;-)


> 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
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


More information about the end2end-interest mailing list