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
