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

[Templin, Fred L]

Hi, all tunnels should be able to support a minimum 1500 MTU even if a small amount
of fragmentation is necessary. Any MTU smaller than 1500 is a degenerate MTU and
does not support tunnels within tunnels to sufficient levels of recursive depth. When
I say "fragmentation", I mean IPv6 fragmentation which fixes the problems in IPv4
fragmentation.

Thanks - Fred
fred.l.templin at boeing.com

> -----Original Message-----
> From: ipv6-ops-bounces+fred.l.templin=boeing.com at lists.cluenet.de [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing.com at lists.cluenet.de] On Behalf Of Jeroen Massar
> Sent: Tuesday, November 11, 2014 11:27 AM
> To: Ryan Hamilton
> Cc: IPv6 Ops list; Lorenzo Colitti
> Subject: Re: MTU = 1280 everywhere? / QUIC (Was: Some very nice ...)
> 
> 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
>