option 212 for 6RD
Lorenzo Colitti
lorenzo at google.com
Wed Jan 16 04:49:23 CET 2013
On Tue, Jan 15, 2013 at 5:06 PM, Jeroen Massar <jeroen at massar.ch> wrote:
> > 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.
>
No, there's another way to get around it: lower the LAN MTU so the host
lowers the MSS itself.
I don't buy the performance impact. Going from 1500 to 1480 is an 0.1% hit
to throughput, and even going from 9k MTU (which is, let's say, rather
rare), the hit is only about of 3%. When compared to experiencing 1xRTT on
every new connection to an outside server because of PMTUd, well, I know
which one I'd choose (and which one I used before I had native
connectivity).
Doing MSS rewriting on the BR is expensive, is probably not supported by
many BRs, and will likely not work if extension headers are present.
I agree that it would be much better if the MTU were associated with the
default route rather than the link. That would let us have our cake and eat
it too, though of course it would take a long time to update all the hosts.
Internet-draft anyone?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20130116/d1d30755/attachment.htm>
More information about the ipv6-ops
mailing list