option 212 for 6RD

[Jeroen Massar]

On 2013-01-15 08:44, Mikael Abrahamsson wrote:
> On Tue, 15 Jan 2013, Jeroen Massar wrote:
> 
>> But the first hop is local likely at 100mbit or GigE thus that
>> response comes back very quickly from that one. Also note that the
>> destination caches will retain this information for quite a bit.
> 
> This is just wrong.
> 
> Client <-> 6RD CPE <-> 6RD ISP RELAY <-> Web server
>       < 1ms       <few ms>         <150 ms>
> 
> Now, client sends SYN with high MSS, gets SYN+ACK back, sends, ACK, send
> GET request, web server sends first 1500 byte packet, 6RD ISP RELAY has
> to send back PTB to web server, web server sends new packet with 1480
> instead of 1500 byte size. Now you've lost one complete RTT between 6RD
> ISP RELAY and Web server.

That is the way it is. The only way to get around that is the either
lower the MSS or to remove your low MTU link.


Note that the 6rd relay could lower this MSS (which means an evil
customer packet rewrite) for you without having to resort to lowering
your LAN MTU.

>> What about traffic between hosts on the same LAN? (see below too)
> 
> Yeah, what about it? What is the damage from the hosts on the lan using
> a slightly smaller MTU compared to the damage PMTUD does for all your
> Internet traffic?

My statistics at home show I do a lot more traffic in the home network
between boxes than what I do towards the Internet. Thus for me it is
very important. And I think for other people who have media caches,
backups etc that will be the same especially for folks who do an MTU of
9000 on the local network (and yes, that means I actually run one on
9000 and one on 1500 for the odd box that does not support jumbo...).

Like a lot of cases it depends on one's situation what might be best.


>> Except for TCP's MSS there is no way of universally indicating a
>> minimal MTU to a remote server, thus indeed if there are one (or more)
>> changes in MTU on the path you will be resending those packets and
>> getting PTBs for them the first time you talk to that server.
> 
> Yes, but there is no reason to do it for *all* traffic.

Indeed there is no reason to limit the local network to an MTU lower
than what that local network supports.

Otherwise, why not fix your local network to the speed of the upstream
Internet link? :)

Or to put it differently: are you running your content servers at 1280?


>> There is no way around that, though in the sole case of TCP indeed
>> setting the MSS works. Well there is a 'work around' and that is the
>> one you are proposing: make everything 1280 as then you are sure that
>> it is all okay..... but that is flawed.
> 
> Setting IPv6 MTU on the LAN to 1450 or 1480 or something like that isn't
> flawed in my opinion.

Of course, it "solves" the problem you are seeing for TCP as it causes
the OS to fix the MSS to a lower setting.

In IPv4 world people would do this by forcing the MSS on the gateway.

What is flawed is that you are limiting your local network because of an
upstream deficiency.


>> Note also that setting your local network to a wrong MTU does not
>> resolve this. Typically packets from the server will be large while
>> the client only sends small one, and you are only controlling the
>> sending of packets with your local MTU, not what the server is
>> sending, which will in most cases happily be at 1500 and maybe even
>> jumbo.
> 
> With TCP the client advertised MSS will be derived from the IPv6 MTU, so
> the server will never send 1500 byte packets on TCP.

Yes, but also every packet on the local network will have that lower MTU
and MSS.

>> IMHO it is very wrong do so and you are only hurting your own network.
> 
> In what way is that hurting my network?

There is quite a difference in transfer speed between 9000 and 1480
bytes sized packets....

>> I wonder who made that suggestion and with what kind of reasoning as
>> it does not help the typical client(x)<->tunnel(<1500))<->server(1500)
>> case at all as the server will try to send an initial packet at 1500
>> anyway when it is sending large content back to the client.
> 
> Why do you believe this to be true?

Because it is. Even if you set your local MTU to 1480, for every non-TCP
packet you will still get PTBs.

>> There really is no problem with this and there is no slow down of any
>> kind, indeed there is a initial PTB, but who cares about that, it will
>> happen anyway as the server side will typically be 1500.
> 
> No it won't.

Not always indeed as the server side will cache your PTB and every next
packet and likely every following connection (be that TCP, UDP or even
SCTP) will have the right MTU details.

>> I guess you see the difference quite well there that way as local
>> transfers are 9000 while internet traffic is 1480, but then again
>> currently LAN is GigE while internet is only 25/3 which is another major
>> difference.
> 
> I have advocated a change to RAs so that the default route will have an
> "MTU", so that you can have whatever local MTU you want, but all packets
> going out the default route will have a lower MTU. That's the best way
> to solve this permanently in my mind. Until then, I'd rather have low
> IPv6 MTU in peoples homes.

It "solves" the problem because of TCP MSS while having the disadvantage
of a lower LAN MTU indeed. It does not solve the problem for non TCP
traffic.

>> I am really wondering why people would advise misconfiguring the MTU
>> on a local network. It really is not needed.
> 
> That's your opinion.

It definitely is.

>> I am not 100% about the statement (hence the might), but I would
>> assume some smart OS might be doing this. I would if I wrote a TCP
>> stack ;)
> 
> All I have checked do this.

Then why did you question it? :)

>> There are people who use IP for other things than TCP..... this little
>> UDP thing also still exists next to SCTP and various others.
> 
> Since most of the traffic is TCP this helps a lot of the traffic.

But it does not help all...

and the point is this is the ipv6-ops list. Thus we should be aware of
locations that filter ICMP PTB and resolve those locations instead of
hacking around it.

The IPv6 networks that exist are small, the content providers that are
offering it are few, we can still maybe educate them properly and kick
them hard enough to fix things today.

If hacks go around it though, then we can just as well just lock down
the Internet to TCP port 80 as that is what it will be and then
deploying IPv6 just does not make sense to get end-2-end back as it
won't be back...

>> Also, against setting the MTU to <1500 on the LAN, what if an
>> far-away-upstream does a tunnel of 1280, does that mean "oh lets just
>> go 1280 everywhere" ? :)
> 
> I never advocated going 1280 on the LAN, I advocate going the MTU on the
> LAN that will traverse the tunnel without PMTUD/PTB being needed.

I agree that you never did that.

But as I noted in the above little text that you fortunately fully
quoted, what if an upstream, thus out of your control tunnels to 1280 ?

(Yes, indeed the right answer is to avoid such an upstream and kick them
quite hard for returning back to the 6bone days ;)

Greets,
 Jeroen