<div dir="ltr"><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif"><span style="font-family:arial">On Tue, Nov 11, 2014 at 11:27 AM, Jeroen Massar </span><span dir="ltr" style="font-family:arial"><<a href="mailto:jeroen@massar.ch" target="_blank" class="cremed">jeroen@massar.ch</a>></span><span style="font-family:arial"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 2014-11-11 20:05, Ryan Hamilton wrote:<br>
[..]<br>
<span class="">> > Does QUIC work from behind your tunnel? If so, maybe my colleagues<br>
> have<br>
> > already solved that problem.<br>
><br>
><br>
> If the MTU is 1280, QUIC will not (currently) work, and Chrome will<br>
> fall back to using TCP.<br>
<br>
</span>Thanks for acknowledging this (and answering the BCC :).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;display:inline">(What's "the BCC"?)</div></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Are there any plans for resolving it by supporting the minimum MTU of<br>
1280 or better still, a variable MTU from 1280 upwards?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif">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.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> From:<br>
> <a href="https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/mobilebasic" target="_blank" class="cremed">https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/mobilebasic</a><br>
> "UDP PACKET FRAGMENTATION" but IPv6 dos not fragment...<br>
> no mention on handling ICMP PTBs either, let alone mention of IPv6.<br>
><br>
><br>
> Yup, if the MTU is too small to accommodate our packets we detect QUIC<br>
> as broken and fallback to TCP. We assume that fragmentation and<br>
> reassembly is rarely successful.<br>
<br>
Indeed, please do not rely on fragmentation.</blockquote><div><br></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif">Right, we don't :></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> It would have been best if<br>
IPv6 did not even had it in the first place as people just think they<br>
should be using it while it just complicates matters.<br>
<br>
As far as I understood the QUIC and TCP connections race each other and<br>
the first one wins (after which QUIC either works and is used, or TCP<br>
works and that is used).<br>
<br>
Hence, QUIC not passing properly will not cause any slow down; though<br>
there are extra packets involved which do not go anywhere.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;display:inline">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. </div></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;display:inline">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.</div></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;display:inline">(Of course if the MTU actually shrinks, then we can get h0zed).</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
As you do that kind of discovery you might want to use a similar<br>
technique as in RFC4821 to get a full packet.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif">Interesting. I'll read about that. </div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
[..]<br>
> (Btw, note the "UPD" typo there, too minor to report that as a 'bug' ;)<br>
><br>
> Seems it was 1200, but got upped to a magic 1350:<br>
> <a href="https://codereview.chromium.org/427673005/" target="_blank" class="cremed">https://codereview.chromium.org/427673005/</a><br>
> <a href="https://codereview.chromium.org/420313005/" target="_blank" class="cremed">https://codereview.chromium.org/420313005/</a><br>
><br>
> Not much background there; but those sizes are likely<br>
><br>
><br>
> Yes, currently our max packet size is 1350 bytes of UDP payload (8<br>
> bytes fewer for IPv6). We chose this number based on the results of<br>
> experiments we ran which tried various packet sizes and saw what<br>
> fraction of the net was able to send and received them. 1350 was a good<br>
> compromise between reachability and maximum payload.<br>
<br>
Sounds like a reasonable selection indeed.<br>
<br>
Greets,<br>
Jeroen<br>
<br>
<br>
</blockquote></div><br></div></div>