[153420] in North American Network Operators' Group
Re: IPv6 day and tunnels
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Jun 5 18:48:39 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <4FCDF9D0.1020004@ttec.com>
Date: Tue, 5 Jun 2012 15:40:11 -0700
To: Joe Maimon <jmaimon@ttec.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jun 5, 2012, at 5:21 AM, Joe Maimon wrote:
>=20
>=20
> Owen DeLong wrote:
>=20
>>=20
>> 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.
>>=20
>> 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,
>>=20
>> Owen
>=20
>=20
> Yes, it is quite nice when ICMP helpfully informs you what your MTU =
is.
>=20
> 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
