IPv6 day and tunnels

Owen DeLong owen at delong.com
Tue Jun 5 22:40:11 UTC 2012


On Jun 5, 2012, at 5:21 AM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
> 
>> 
>> But that's a whole lot more packets than working PMTU-D to get there and
>> you're also waiting for all those round trips, not just the 4 timeouts.
>> 
>> The round trips add up if you're dealing with a 100ms+ RTT. 22 RTTs at
>> 100ms is 2.2 seconds. That's a long time to go without first data packet
>> passed,
>> 
>> Owen
> 
> 
> Yes, it is quite nice when ICMP helpfully informs you what your MTU is.
> 
> However, we have known for quite some time that is simply not reliable on the IPv4 internet, for a multitude of reasons, with intentional ICMP blocking just one of them.

You keep saying this, yet you have offered no other explanations.

> I have no reason to expect it to work better in IPv6.

That's where we differ. In IPv4, since PMTU-D was a new thing, it had to be optional and we had to work around places where it was broken to avoid flat-out breaking the internet.

In IPv6, we have the opportunity to push the issue and use education to resolve the problem correctly.

> This is why more reliable methods are a good idea, even if they work slower or add more overhead, because as I see it they are intended to be used concurrently with ICMP.

ICMP can be a reliable method if we just stop breaking it. Do you have some reason to believe people won't break the other methods, too? I don't.

PMTU-D can't be fire-and-forget because paths aren't static.

> Also, as I understand the probing, getting data through happens much faster then arriving at the optimal mtu size might take.

At the expense of sending a lot of unnecessary additional datagrams.

> Perhaps short flows should just be sticking to the min-mtu anyways.

So you want to turn a short-flow (say a retrieving a 20k PNG) from being a 3-packet transaction on a path with jumbo frame support at 9000 octets into a 16+ packet exchange? (note I'm only counting the payload packets in one direction, not setup, teardown, additional acks, etc.).

Still seems like a bad idea to me.

Owen





More information about the NANOG mailing list