MTU = 1280 everywhere? / QUIC (Was: Some very nice ...)

[Jeroen Massar]

On 2014-11-11 20:05, Ryan Hamilton wrote:
[..]
>     > Does QUIC work from behind your tunnel? If so, maybe my colleagues
>     have
>     > already solved that problem.
> 
> 
> ​If the MTU is 1280, QUIC will not (currently) work, and Chrome will
> fall back to using TCP.​

Thanks for acknowledging this (and answering the BCC :).

Are there any plans for resolving it by supporting the minimum MTU of
1280 or better still, a variable MTU from 1280 upwards?

>     From:
>     https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/mobilebasic
>     "UDP PACKET FRAGMENTATION" but IPv6 dos not fragment...
>     no mention on handling ICMP PTBs either, let alone mention of IPv6.
> 
> 
> ​Yup, if the MTU is too small to accommodate our packets we detect ​QUIC
> as broken and fallback to TCP. We assume that fragmentation and
> reassembly is rarely successful.

Indeed, please do not rely on fragmentation. It would have been best if
IPv6 did not even had it in the first place as people just think they
should be using it while it just complicates matters.

As far as I understood the QUIC and TCP connections race each other and
the first one wins (after which QUIC either works and is used, or TCP
works and that is used).

Hence, QUIC not passing properly will not cause any slow down; though
there are extra packets involved which do not go anywhere.

As you do that kind of discovery you might want to use a similar
technique as in RFC4821 to get a full packet.

[..]
>     (Btw, note the "UPD" typo there, too minor to report that as a 'bug' ;)
> 
>     Seems it was 1200, but got upped to a magic 1350:
>     https://codereview.chromium.org/427673005/
>     https://codereview.chromium.org/420313005/
> 
>     Not much background there; but those sizes are likely
> 
> 
> ​Yes, currently our max packet size is 1350 bytes of UDP payload (8
> bytes fewer for IPv6). We chose this number based on the results of
> experiments we ran which tried various packet sizes and saw what
> fraction of the net was able to send and received them. 1350 was a good
> compromise between reachability and maximum payload.

Sounds like a reasonable selection indeed.

Greets,
 Jeroen