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