RE: draft-bonica-6man-frag-deprecate

["Templin, Fred L" <[e-mail]>]

Hi Ole,

> -----Original Message-----
> From: Ole Troan [mailto:[e-mail]]
> Sent: Friday, June 28, 2013 11:56 PM
> To: Templin, Fred L
> Cc: Brian E Carpenter; 6man
> Subject: Re: draft-bonica-6man-frag-deprecate
> 
> Fred,
> 
> >> in my understanding the 1280 minimum MTU for IPv6 was already chosen
> to
> >> accommodate nested tunnels.
> >
> > Right, but..
> >
> >> the expectation made, I believe, was that native links support at
> least
> >> an MTU of 1500 bytes,
> >
> > But, that expectation went out the window at the same time the IPv6
> > minMTU was set to 1280 - so now 1280 is all that can be expected.
> 
> quite the opposite.
> physical link MTUs aren't getting smaller.
> do you have any evidence that operators set the IPv6 MTU to a value
> smaller than the MTU supported
> by the link-layer?

The evidence is in RFC2460, where the minMTU is set to 1280.
Plus, there are links (e.g., 6lowpan, aviation data links,
tactical military links etc.) where setting an MTU larger
than 1280 might not be practical.
 
> as far as I can see the setting IPv6 minimum MTU to 1280, which gives
> ample room for
> nested tunnels works as designed.

But, what would that look like in real life? The first tunnel
(T1) would have to set a 1280 MTU so that its tunneled packets
would emerge as 1320 bytes. Then, the next tunnel (T2) would
have to set a 1320 MTU so its tunneled packets would emerge as
1360. Then the next tunnel (T3) would have to set a 1360 MTU
so that its tunneled packets would emerge as 1400, etc. until
we run out of available MTU. The question is, how can those
tunnels be so carefully coordinated so that the nesting is
nailed down enough so that we will never have an MTU infraction?
In a single administrative domain where an operator can lay
hands on every tunnel ingress this may be possible, but we
need to engineer for the general case.

> > So, without fragmentation, when the tunnel ingress receives a 1280
> > packet, it emits a (1280+HLEN) packet. If that packet is dropped
> > at a link that configures a 1280 MTU, then it simply black holes.
> >
> >> allowing 220 bytes for tunnel encap (5 IPv6 headers).
> >
> > Tunnels within tunnels presents an additional pain point, but the
> > plain truth is that IPv6 links only need to configure a 1280 MTU;
> > not a 1500.
> 
> again, why would anyone do that?

Performance. What matters is time on the wire, and some "wires"
may not be fast enough to support anything larger than 1280
(see above).

> the pain here is fragmentation, not supporting an MTU larger than 1280.

Fragmentation and reassembly is a pain point for some (but
not all) routers. The pain may be observed by the hosts
which would (selfishly) like to do something to improve
their performance. With SEAL, to get better performance (and
in the process ease the burden on the routers) the hosts can
use RFC4821 and begin sending packets larger than 1500. 
 
> >> you want to avoid reassembly at tunnel endpoints, if you care about
> >> performance that is.
> >
> > Unfortunately, reassembly is absolutely necessary if the tunnel is
> > configured over a path that contains at least one 1280 link (see
> above).
> 
> reassembly in the network is a non-starter.

Let me say again what I said several messages ago. Never say
"always" and never say "never". The answer as to whether
reassembly can be tolerated is: "it depends" (i.e., it
depends on where the tunnel endpoints are positioned). 

> the vendor I'm most familiar with does not do this in hardware. sure,
> you can get reassembly, but at an order of one or two magnitudes less.
> if anyone know of platforms doing IPv6 fragment reassembly at line rate
> for 10G or 100G interfaces I'll stand corrected. ;-)
> for now reassembly in the network is not realistic.

Reassembly is required by RFC2460, RFC2473 and I think others
have also been mentioned. To support tunnels, and especially
tunnels within tunnels, it needs to be there.

Thanks - Fred
[e-mail]

> cheers,
> Ole