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

[Ryan Hamilton]

On Tue, Nov 11, 2014 at 11:27 AM, Jeroen Massar <jeroen at massar.ch> wrote:

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

​(What's "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?
>

​We don't currently have any plans, no, but we could. Like most features of
QUIC it's simply a question of return on our investment. How much more QUIC
traffic would you expect us to be able to handle if we solved this problem?
I'd love to explore the options at our disposal if (or someone else) is
interested.

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


​Right, we don't :>


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

​Almost... When the first request is made to a server, we race QUIC with
TCP and use which ever wins. If it happens that TCP wins and then QUIC
eventually finishes, we will then use QUIC. However, for subsequent
connections, QUIC will use 0-RTT, so it "wins immediately" and the request
is sent via QUIC. If it then turns out later that the QUIC handshake did
not succeed (either explicitly or via a timeout) we will retry the requests
via QUIC.

When we change networks, or restart Chrome, we switch back to the "first
request" behavior in which we don't use 0-RTT. So this means that if we
switch from a 1500 MTU network to a 1280 MTU network there won't be a user
impact.

(Of course if the MTU actually shrinks, then we can get h0zed).


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

​Interesting. I'll read about that.



>
> [..]
> >     (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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20141111/11717532/attachment-0001.html