[e2e] MTU - IP layer
touch at ISI.EDU
Thu Apr 21 17:20:22 PDT 2005
-----BEGIN PGP SIGNED MESSAGE-----
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
> Loki Jorgenson wrote:
>>Hmmmmmm - that's an interesting reading of RFC 791 - and the
>>of fragments over datagrams could be made in that way.
>>My observation remains that MTU is conceptually defined and
>>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"
>>"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. ;-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the end2end-interest