Enabling QUIC in tip-of-tree

[Dharani Govindan]

Hello Fellow Chrome Developers,

 

QUIC has been enabled in Google Chrome for 90% of users via a multi-year field trial, and default enabled in a number of popular mobile apps including Google Search and YouTube, for several years. As our various blog posts and SIGCOMM 2017 paper have detailed, this has been a huge win for performance and user experience and we are confident that our QUIC support is robust and solid.

 

As a result, we will be changing the way QUIC is enabled in M82. Instead of explicitly enabling QUIC when the network stack is configured, QUIC will be enabled by default. This means that QUIC will be implicitly enabled for embedders who accept the default options. An embedder will need to explicitly disable QUIC if they do not wish to support it. This can be done by setting the "enable_quic" member of URLRequestContextConfig to false.

 

If you have any questions please feel free to contact net...@chromium.org

Thanks

QUIC Team

[Ryan Sleevi]

Keeping only net-dev@, per request.

The Chromium //net code maintains an allow-list of specially treated Google hosts that, when QUIC is enabled, has different treatment from other hosts. While perhaps reasonable as a Chrome product decision, as part of enabling this for non-Chrome Users, will this list be refactored to be Chrome-only and/or eliminated? Or will it also result in special treatment of Google hosts in these other embedders?

[Dharani Govindan]

Adding Ian as he has more context in those hosts.

[Ian Swett]

Great question Ryan, That's currently in the Chromium code(link), not the Chrome-specific code.  At the moment, that list is still very valuable, but I agree it seems Chrome specific.  It seems possible to refactor it and move it out(would src/components/google be a good location?).  Doing this could cause default enabling to slip to M83, but if you think this work should be done before default enabling, then I'd be supportive.

FYI +David Schinazi 

Thanks, Ian

[Ryan Sleevi]

Refactoring it out is certainly a possibility, or possibly guarding it by appropriate BUILDFLAGs (GOOGLE_CHROME_BRANDING seems relevant), if that's a more temporarily expedient option that doesn't risk your scheduling. Does that seem like it would work?

[Ian Swett]

I don't have a strong opinion on how it's done, so guarding it with BUILDFLAGs SGTM.  David is the new QUIC TL on the Chrome side, so I think the 'how' ideally should be his call.

[David Schinazi]

Thanks for pointing this out, Ryan.

I agree that it would be best to not have mentions of Google domains in Chromium source code. However, that is the state of the world today, and it's not limited to Alt-Svc handling or QUIC. I think that removing these hard-coded domains should be performed as part of a wider effort, not a one-off fix just for QUIC. Additionally, this effort should not have any blocking relationship with our effort to default-enable QUIC.

Ryan, could I ask you to file a crbug to track this issue?

Thanks,

David

[Ryan Sleevi]

Hi David,

I'm not sure I understand your response, so I'm hoping for a bit more detail. As Ian pointed out, we have a place in the code for special-casing Google-specific behaviour, which easily allows embedders and distributors to opt-out (that is, via //components). This isn't about mentioning of Google domains in Chromium source code in general, which would preclude such a component, but more about the default behaviour for //content (and //net) embedders.

For that case, I believe it is specific to Alt-Svc/QUIC handling, and I was hoping you could point out other examples you knew of, particularly those that lead to Web-observable behaviours (i.e. not just metrics). I'm not aware of those in //net. Could you perhaps provide a link?

I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=1060290 to track this discussion

[David Benjamin]

IIRC, this is used for the analog to resumption in QUIC, with the long-term plan being an extension for servers to opt into cross-SNI resumption in TLS 1.3 (combined with IETF QUIC using TLS 1.3). +Victor Vasiliev 

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACvaWvZ_saCmdqELp7tjZNuF_0z%3DZEnxN5HaOU9z439CUGqe3g%40mail.gmail.com.

[Ryan Sleevi]

Thanks for pointing that out, David.

My understanding is that the QUIC being enabled was the IETF QUIC. Is that not the case here - that is, is this default enabling a Google-specific version of QUIC as well?

[David Schinazi]

We are default-enabling QUIC, and that means all versions of QUIC. Note that what is currently colloquially referred to as "GoogleQUIC" is not Google-specific. There are other content providers (Akamai, LiteSpeed, etc.) that deploy QUIC versions Q043 and Q046 in production, and Chrome/Chromium interoperate with them today.

David

[Victor Vasiliev]

When I first read this thread, I assumed this was about this code.  That copy of canonical suffix list is used to allow cross-domain resumption.  The correct long-term solution would be to allow websites to opt-in themselves in-band;  there's an I-D out there that needs shepherding through IETF, but I've not gotten around to it yet.

Looking closer, I realize that this is actually a different copy of the same list, but I suspect the mechanism listed above can solve both.  That one is also not QUIC-specific, and is already exposed to all //net users.

I'm not particularly concerned about shipping this list as-is.  It has a very low growth potential (the problem it solves is fairly niche), and we have a clear path to removing it, which makes it better than some other lists we've shipped in the past.

[Dharani Govindan]

Hello everyone,

Update: This change will be enabled in M83 instead of M82 giving enough time to address all the concerns.

Thanks

Dharani

[Dharani Govindan]

+Renjie Tang 

Renjie will be landing the code to enable QUIC by default at the same time will look into how to separate Google hosts from chromium.

[Krishna Govind]

+Craig Tumblison & +Ernest Cabrera (gTech POCs), +Chrome Product TPgM , +clank-te & +chrome-te as FYI

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAD9fJvzjSG91cxd0nJ%3DNjByAMYpUrgteevBjbUp-tVNEokY8TA%40mail.gmail.com.

[eri...@microsoft.com]

Howdy, all. 

A few questions from the Microsoft Edge team:

With regard to David's statement: "We are default-enabling QUIC, and that means all versions of QUIC" -- does this encompass all available versions or is the claim just meant to say that on-by-default encompasses both "gQUIC" and some versions of ietfQUIC? 

In particular, we on the Edge team are interested in understanding whether the plan includes enabling IETF Draft25 and Draft27?

With regard to Ryan's specific concern about special case behavior, I've weighed in on the https://crbug.com/1060290 issue.

thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to chromi...@chromium.org.

[David Schinazi]

Hi Eric,

To clarify what I meant earlier: the effort discussed in the email that started this thread is about enabling QUIC by default.

Enabling QUIC by default just means that the default config will have a list of supported QUIC versions that isn't empty.

Today, the great majority of Chrome users end up being configured with the supported version list { Q046 }, so that's the version that we're the most likely to embed by default at first.

However, that list isn't static. We already have experiments going with version Q050, and we're hoping to make that the default version in the near future.

We also have concurrent experiments with draft-25 today, and soon draft-27. If those go well, we're hoping to potentially make draft-27 the default version soon thereafter.

So, to answer your question, initially embedders will default to a "Google QUIC" version (Q046 or Q050) but we're hoping to replace that with an "IETF QUIC" version like draft-27 ASAP.

There's no important conceptual difference between "Google QUIC" versions and "IETF QUIC" versions, as both have influenced the other over the course of the past several years, and all of those will be replaced by "IETF QUIC v1" and deprecated once that RFC is published.

David

You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/5f9e18f8-3f24-4d59-849a-3fa5a95aa109%40chromium.org.

[Brandon Maslen]

Thanks for helping clarify David. Are you able to share your experiment details regarding draft-25 and any plans for draft-27? When I took a look I only saw some small (2-11% buckets) of h3-Q048/49/50 and h3-T050 but didn't find the instances of h3-25 or h3-27 being offered.

With properties like Cloudflare (https://developers.cloudflare.com/http3/intro/release/ - h3-23,24,25) and IIS(http.sys)/OWA (h3-25/27) experimenting with H3 offerings based on the IETF drafts it would be great to better understand the roadmap for these versions and ideally get broader usage outside of users who opt to manually add a version target when launching their browser. Do you have any planned milestones or time frames you plan to enable these in?

Thanks,

Brandon

To unsubscribe from this group and stop receiving emails from it, send an email to net...@chromium.org.

[David Schinazi]

[ other lists to BCC, keeping net-dev only ]

Hi Brandon,

Our implementation of draft-25 and draft-27 is currently missing some features such as 0-RTT.

I don't expect us to make one of them the default version until we have that implemented, due to the negative performance impact.

I can't commit to specific dates or milestones but I'll share that we are actively working on this.

We want to enable IETF drafts as soon as we can, specifically to allow testing with other providers.

David

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/914fb090-36c6-4687-98af-844083915c36%40chromium.org.

[Renjie Tang]

Just a side note: https://chromium-review.googlesource.com/c/chromium/src/+/2024077 is what I have to potentially turn QUIC on by default.

You received this message because you are subscribed to a topic in the Google Groups "net-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/net-dev/5M9Z5mtvg_Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAHwtu-EoWNZbRLK-JANpu2mebBoeEvwAoQmVg0yUio-Siz_JxA%40mail.gmail.com.

[Dharani Govindan]

Update: We are about to land the change to enable QUIC by default in M84. If you are interested, you can star this change. 

Thanks!

QUIC Team

On Mon, Mar 9, 2020 at 10:31 AM Dharani Govindan <dha...@google.com> wrote:

[Dharani Govindan]

Update: QUIC is now enabled by default. Please reach out to net...@chromium.org if you are facing any issues.

On Mon, Mar 9, 2020 at 10:31 AM Dharani Govindan <dha...@google.com> wrote: