bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.
Bug 1158011 (QUIC)

QUIC (Quick UDP Internet Connections) support




3 years ago
a day ago


(Reporter: mt, Unassigned)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [parity-Chrome][necko-backlog], URL)



3 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150415140819

Steps to reproduce:

The official website of QUIC: https://www.chromium.org/quic
The source code of QUIC: https://chromium.googlesource.com/chromium/src/net/+/master/quic/


3 years ago
Severity: normal → enhancement
OS: Unspecified → All
Hardware: Unspecified → All
Summary: QUIC(Quick UDP Internet Connections) supporting → QUIC (Quick UDP Internet Connections) supporting
Version: unspecified → 37 Branch


3 years ago
Component: Networking: HTTP → Networking
Summary: QUIC (Quick UDP Internet Connections) supporting → QUIC (Quick UDP Internet Connections) support
Version: 37 Branch → 1.0 Branch

Comment 1

3 years ago
Informational RFC Draft:
Ever confirmed: true
Whiteboard: [parity-Chrome]
Version: 1.0 Branch → Trunk


3 years ago
Alias: QUIC
Patrick, what's the opinion of the networking team on that?
Flags: needinfo?(mcmanus)

Comment 3

2 years ago
To anyone that read any QUIC docs a long while ago: they've made drastic improvements to completeness and readability. For a long while the documentation did not look like something that was practical to try to implement from.
(In reply to [:fabrice] Fabrice Desré from comment #2)
> Patrick, what's the opinion of the networking team on that?

userspace based transport is an incredibly important area of interest. Personally, its probably my top interest right now and its strategically important for Mozilla as part of Internet evolution.

It allows us to deploy what are effectively L4 upgrades in an era when OS stack updates to TCP are becoming a an ossified bottleneck to things like transport security, effective network utilization, and fault tolerance.

quic deserves credit for pushing forward the state of the art, and has shown good results with the specific case of streaming media on a well distributed CDN. We eagerly look forward to working with goog and engaging with other interested parties to develop an open standard in this space that is suitable for a broad range of use cases and operators.

Informational drops of evolving packet formats are welcome contributions on the road to this goal, but they don't reach the bar on their own.
Flags: needinfo?(mcmanus)

Comment 5

2 years ago
May the following library help?
YouTube serves video to Chrome over QUIC. A contact at YouTube says, "QUIC has worked out pretty well for Chrome. Improved things across the board for Chrome and Android."
Keywords: feature
Whiteboard: [parity-Chrome] → [parity-Chrome][necko-backlog]
Comment hidden (spam)
No longer blocks: 1325169

Comment 8

11 months ago
If this is implemented, we should ensure that it's accessible to WebExtensions webRequest APIs.


"AdBlock Plus, uBlock Origin, and other extensions cannot block QUIC requests. Recommended best practice is to disable QUIC from the chrome://flags/ URL."
re comment 8 - the protocol should not be a problem for any sensible content API. Just make sure they are defined in terms of content and scheme and not protocol. There is nothing about quic that would make it harder to implement for than than say http/2 (which also does not have its own scheme - they both use https://). If the webextension gets defined in terms of TCP or something then that would be a problem - but I cannot see a reason to do that.
Regarding that specific blog post in comment 8, there was a huge twitter thread about it:


It seems maybe the confusion is due to QUIC pre-connects being allowed even if the actual requests are blocked by webRequest:


Also, chrome has some special whitelisting of google domains that bypass webRequest that muddies the waters:

specifically protocol-independent pre-connects are not impacted by webRequest (which seems right to me fwiw). Its not a QUIC issue - same would apply to other transports.

And the whitelist thing certainly sounds undesirable, but again that's a chrome implementation issue independent of transport (i.e. turning off quic doesn't make the whitelisted requests visible to the ad blockets.)

it seems possible that the nascent state of quic tooling made it harder for the bloggers to correctly diagnose the bytes they were seeing. Time and standards will fix that problem.
You need to log in before you can comment on or make changes to this bug.