option 212 for 6RD

[Mikael Abrahamsson]

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.

> 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?

> 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.

> 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.

> 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.

> IMHO it is very wrong do so and you are only hurting your own network.

In what way is that hurting my network?

> 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?

> 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.

> 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.

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

That's your opinion.

> 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.

> 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.

> 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.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se