Re: Re: Responding to Ron's comment about removing fragmentation

[Ray Hunter <[e-mail]>]

Carsten Bormann wrote:
> Having a single MTU is not very useful thinking: Every tunnel then causes a fragmentation problem.
>
> Instead, we need to keep two MTUs:
> The one exported to the top of stack (inner MTU), and the one imported from the bottom of the stack (outer MTU)
>
> The inner MTU is 1280, and with IPv6 it is really hard to use anything that is much closer to 1500, as old style (RFC 1191) PMTUD so overwhelmingly breaks and PLPMTUD (RFC 4821) incomprehensibly isn’t switched on.
>
> The outer MTU is 1500 for all instances of reality.
I agree having a single MTU is broken thinking. There isn't even a 
specification of what exactly a "path" is in PMTUD.

There are plenty of people who need larger frames (for efficiency) e.g. 
disk over IP. And Metro Ethernet and MAN links regularly exceed 1500 MTU.

But I think you'll find that the reality is that there is actually a 
whole "stack of MTU's" to consider, not just "inside" and "outside", 
because people really do regularly have transport stacks like IP over 
.1q trunk over EoMPLS over Ethernet....... (including 2 label stacks)

If at any point in the stack the relevant MTU at that layer is exceed, 
then bad stuff happens, and any higher layers are rarely informed of 
what exactly has broken where: you just get black-holing.
> By never sending more than 1280 from an application and never limiting the available MTU below what tunneling removes from 1500, most applications and tunnel stacks can just work well.
Most, but not all.
>
> Apart from the cognitive dissonance problem, do we really need that 17 % (max) reduction in the number of packets that jamming up the inner MTU to the max would allow?
Yes. For the other apps. And it isn't 17% when talking about L2 MTU of 
9000 (or greater).
> Grüße, Carsten
>
> PS.: Yes, we made the mistake not to recognize these simple facts in 6LoWPAN.   See section 4 of draft-bormann-6lo-6lowpan-roadmap-00.txt for the (unofficial, but widely implemented) fix.
>
>

-- 
Regards,
RayH