[e2e] MTU - IP layer

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
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,

yes...

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

Joe


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

iD8DBQFCaENGE5f5cImnZrsRAje5AJ9glKM5wN1vJ2G9NtPqpdV4XbH45ACeLLr+
igUDU1KTiBnn+xc0qp20bk8=
=+5lW
-----END PGP SIGNATURE-----