Open Bug 1158011 (QUIC) Opened 9 years ago Updated 15 days ago

[meta] QUIC support

Categories

(Core :: Networking, enhancement, P3)

Product:
Core
Component:
Networking
Type:
enhancement

Tracking

()

People

(Reporter: mt, Unassigned)

References

(Depends on 37 open bugs,
URL
)

Details

(Keywords: feature, meta, parity-chrome, Whiteboard: [necko-backlog]) 

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/
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
Component: Networking: HTTP → Networking
Summary: QUIC (Quick UDP Internet Connections) supporting → QUIC (Quick UDP Internet Connections) support
Version: 37 Branch → 1.0 Branch
Informational RFC Draft:
https://tools.ietf.org/html/draft-tsvwg-quic-protocol
URL: https://tools.ietf.org/html/draft-tsv...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [parity-Chrome]
Version: 1.0 Branch → Trunk
Alias: QUIC
Patrick, what's the opinion of the networking team on that?
Flags: needinfo?(mcmanus)
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)
May the following library help?
https://github.com/devsisters/libquic
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]
No longer blocks: Quantum
If this is implemented, we should ensure that it's accessible to WebExtensions webRequest APIs.

https://blog.brave.com/quic-in-the-wild-for-google-ad-advantage/

"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:

https://twitter.com/bcrypt/status/856886044066590721

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

https://bugs.chromium.org/p/chromium/issues/detail?id=715140#c11

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

https://bugs.chromium.org/p/chromium/issues/detail?id=715184
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.
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome
Whiteboard: [parity-Chrome][necko-backlog] → [necko-backlog]
Dirkjan Ochtman (already CCed on this bug) mentioned on Twitter today that he published the first version of his Rust crate (quinn) that implements QUIC: https://crates.io/crates/quinn

We probably couldn't ship it as-is because it uses ring / rustls, but it's possible it could be modified to swap those implementations to use NSS by way of wrapper crates in Firefox.
I actually emailed Dragana (the current Networking module owner) about this recently, it appears she would prefer to stick to the mozquic implementation that Patrick and she have been working on, on the premise that it will be hard to integrate the Rust code into the Gecko environment (she mentioned NSPR).

We'd be happy to bring up some traits to abstract over TLS implementations -- although in the end, I think that Gecko adopting rustls would be a much more interesting long-term strategy than doing NSS bindings. Isn't this exactly the kind of thing Rust is better at?
> I think that Gecko adopting rustls would be a much more interesting long-term strategy than doing NSS bindings

Changing TLS provider from NSS to something else is a much bigger question than "just" quic (and I wouldn't be surprised if there's already a bug filed about that with a very long comment section), but it also seems totally unlikely (and wrong) that a quic implementation for Firefox would use a different TLS 1.3 provider than the rest of necko/gecko.
Daniel: I agree that these are largely orthogonal issues, which is why I mentioned that we'd be happy to abstract over TLS implementations in our QUIC implementation if that will help unblock this strategy.

(BTW, searching Bugzilla for rustls results in Zarro Boogs for now.)
Regardless of where we start for QUIC support, our basic policy here is that Firefox should use a consistent TLS 1.3 implementation, which, at least for now, means NSS.

I considered modifying this to "HTTP/3 support" given that is the only current use case, but I realized that there are a few differences between HTTP/2 and HTTP/3 other than QUIC. (Some of which is just bypassing HTTP/2 flow control routines to calls into quic.) Should that be a separate bug, or just roll it up into this one since it's all part of the same push?

I believe HTTP/3 support should be a separate bug, depending on this one.

status-firefox68: --- → affected
status-firefox69: --- → affected
status-firefox70: --- → ?
status-firefox-esr60: --- → affected
status-firefox-esr68: --- → affected
Webcompat Priority: --- → ?
Keywords: meta
Summary: QUIC (Quick UDP Internet Connections) support → [meta] QUIC (Quick UDP Internet Connections) support
Depends on: 1577643

Couldn't help myself.

Summary: [meta] QUIC (Quick UDP Internet Connections) support → [meta] QUIC support
Depends on: 1578883
Depends on: 1581637
Depends on: 1582660
Depends on: 1582659
Depends on: 1582663
Depends on: 1582664

Excuse me, sorry for the intrusion.

"Initial support was added in Chrome 29 and Opera 16, and in LiteSpeed servers. Chrome support expanded this month, but the bigger news is Cloudflare making the protocol generally available for its customers."

Link:
https://www.zdnet.com/article/cloudflare-google-chrome-and-firefox-add-http3-support/

Thanks...

Excuse me, sorry for the intrusion(again).

There is this project in GO:
https://github.com/lucas-clemente/quic-go

Thanks!

Depends on: 1587353
Depends on: 1587712
Depends on: 1587739
Depends on: 1595269
Depends on: 1595271
Depends on: 1595337
Depends on: 1595449
Depends on: 1597072
Depends on: 1601070
Depends on: 1605099
Depends on: 1605090
Depends on: 1605105

INFO: currently that is a problem with QUIC/HTTP3 because some functionality in neqo has changed and necko has not adapted to it. I am working a solution. The problem can be experience that http3 connection will never be closed and will enter a busy wait state.

Depends on: 1608786
Depends on: 1605109
Depends on: 1608967
Depends on: 1609051
Depends on: 1608774
Depends on: 1614711
Depends on: 1616009
Depends on: 1616238
Depends on: 1616239
Depends on: 1616340
Depends on: 1616398
Depends on: 1616005
Depends on: 1617142
Depends on: 1618804
Depends on: 1498663
Depends on: 1618849
Depends on: 1619764
Depends on: 1619211
Depends on: 1619793
Depends on: 1619813
Depends on: 1618158
Depends on: 1620574
Depends on: 1605751
Depends on: 1622232
Depends on: 1622233
Depends on: 1622237
Depends on: 1622861
Depends on: 1622845
Depends on: 1622901
Depends on: 1623312
Depends on: 1616323
Depends on: 1623755
Depends on: 1623501
Depends on: 1624090
Depends on: 1624105
Depends on: 1624800
Depends on: 1625198
Depends on: 1625284
Depends on: 1625841
Depends on: 1625886
Depends on: 1626359
Depends on: 1603240
Depends on: 1626799
Depends on: 1627910
Depends on: 1628459
Depends on: 1628460
Depends on: 1628461
Depends on: 1628886
Depends on: 1629057
Depends on: 1629090
Depends on: 1635355
Depends on: 1635502
Depends on: 1634020
Depends on: 1640148
Depends on: 1643165
Depends on: 1644374
Depends on: 1644377
Depends on: 1644532
Depends on: 1645471
Depends on: 1646023
Depends on: 1646024
Depends on: 1646025
Depends on: 1646318
Depends on: 1648266
Depends on: 1596576
No longer depends on: 1596576
Depends on: 1648532
Depends on: 1648556
Depends on: 1648558
Depends on: 1649495

blog.cloudflare.com/how-to-test-http-3-and-quic-with-firefox-nightly/
when you enable network.http.http3.enabled to true >slows down Internet connect and request stopped

Flags: needinfo?(mt)
Depends on: 1650358
Depends on: 1650363
Depends on: 1650366
Depends on: 1650388
Depends on: 1646961
Depends on: 1650992
Depends on: 1651489
Depends on: 1651565
Depends on: 1651541
Depends on: 1651814
Depends on: 1652104
Depends on: 1652573
Depends on: 1653178
Depends on: 1653179
Depends on: 1653180
Depends on: 1653043
Depends on: 1654401
Depends on: 1654507
Depends on: 1655356
Depends on: 1655125
Depends on: 1655782
Depends on: 1655843
Depends on: 1656522
Depends on: 1656870

(In reply to artymka1 from comment #27)

blog.cloudflare.com/how-to-test-http-3-and-quic-with-firefox-nightly/
when you enable network.http.http3.enabled to true >slows down Internet connect and request stopped

¡Hola!

I'm sorry to learn that enabling HTTP/3 on your Nightly has negatively impacted performance.

Could you please elaborate on what exactly do you mean by "slows down Internet connect and request stopped"?

Could you please share URL(s) of where the slow down is observed and how exactly it manifests?

¡Gracias!
Alex

Flags: needinfo?(artymka1)

¡Hola Dragana!

Thanks so much for all of your work on HTTP/3 on Firefox!

Lazy Saturday so I was again testing the servers listed at https://bagder.github.io/HTTP3-test/ on today's Nightly...

Some work but I noticed that all of these fail with the initial request showing "Blocked" on the "Transferred" column on the 1st request in the "Network" tab of the Developer Tools:

https://quic.tech:8433/
https://pgjones.dev:4433/
https://f5quic.com:4433/
https://nghttp2.org:4433/

These fail with the initial request showing "0 B" on the "Transferred" column on the 1st request in the "Network" tab of the Developer Tools:
https://test.privateoctopus.com:4433/
https://fb.mvfst.net:4433/

The rest of test servers seem to work.

Are these known bugs? If not, are these worth filing?

¡Gracias!
Alex

Depends on: 1658362
Depends on: 1656118
Depends on: 1659705
Depends on: 1660080
Depends on: 1664321
Depends on: 1664512
No longer depends on: 1655356
Depends on: 1665620
Depends on: 1665621
No longer depends on: 1582659
No longer depends on: 1586794
No longer depends on: 1616238
No longer depends on: 1616239
No longer depends on: 1622845
No longer depends on: 1622901
No longer depends on: 1640148
No longer depends on: 1646023
No longer depends on: 1648556
No longer depends on: 1654401
No longer depends on: 1653180
No longer depends on: 1649969
Depends on: 1666413
Depends on: 1668019
Depends on: 1668021
Depends on: 1668023
Depends on: 1668232
Depends on: 1669813
Depends on: 1670086
Depends on: 1672520
Depends on: 1673585
Depends on: 1673611
Depends on: 1674111
Depends on: 1674112
Depends on: 1674116
Depends on: 1674124
Depends on: 1673231
Depends on: 1674316
Depends on: 1674366
Depends on: 1674759
Depends on: 1674922
Depends on: 1674925
No longer depends on: 1674111
No longer depends on: 1674316
No longer depends on: 1674759
No longer depends on: 1674922
No longer depends on: 1674124
Depends on: 1674449
Depends on: 1673124
No longer depends on: 1674116
No longer depends on: 1674449
No longer depends on: 1648558
Depends on: 1675411
Depends on: 1677743
Depends on: 1677858
Depends on: 1678312
Depends on: 1680349
Depends on: 1680354
Depends on: 1680497
Depends on: 1681689
Depends on: 1680447
Depends on: 1682262
Depends on: 1682539
Depends on: 1683902
Depends on: 1683261
Depends on: 1686593
Depends on: 1687392
Depends on: 1687787
Depends on: 1688091
Depends on: 1688850
Depends on: 1686362
Depends on: 1669892
Depends on: 1689550
Depends on: 1689554
Depends on: 1689555
Depends on: 1690000
Depends on: 1690008
Depends on: 1690355
Depends on: 1693738
Depends on: 1694164
Depends on: 1695785
Depends on: 1695717
Depends on: 1697791
Depends on: 1698438
Depends on: 1698470
Depends on: 1698742
Depends on: 1699463
Depends on: 1699490
Depends on: 1700703
Depends on: 1700884
Depends on: 1701110
Depends on: 1701232
Depends on: 1701829
Depends on: 1702529
Depends on: 1703186
Depends on: 1705171
Depends on: 1706586
Depends on: 1708094
Depends on: 1708567
Depends on: 1708678
Depends on: 1709166
Depends on: 1708868
Depends on: 1709568
Depends on: 1710816
Depends on: 1710820
Depends on: 1710821
Depends on: 1656779
Depends on: 1710387
Depends on: 1711971
Depends on: 1712440
Depends on: 1712441
Depends on: 1713580
Depends on: 1713591
Depends on: 1713650
Depends on: 1713689

🎉 QUIC is finalized and standardized 🎉
https://www.ietf.org/rfc/rfc9000.html

Depends on: 1716588
Depends on: 1716172
Depends on: 1717505
Depends on: 1717524
Depends on: 1719316
Depends on: 1720079
Depends on: 1719658
Depends on: 1720597
Depends on: 1723218
Depends on: 1724196
Depends on: 1724240
Depends on: 1724408
Depends on: 1726528
Depends on: 1727148
Depends on: 1718426
Depends on: 1728268
Depends on: 1728735
Depends on: 1733603
Depends on: 1734198
Depends on: 1734110
Depends on: 1730491
Depends on: 1735309
Depends on: 1738102
Depends on: 1740637
Depends on: 1741031
Depends on: 1739025
Depends on: 1743378
Depends on: 1743965
Depends on: 1748097
Depends on: 1748782
Depends on: 1749437
Depends on: 1750587
Depends on: 1751170
Depends on: 1751218
Depends on: 1752117
Depends on: 1753002
Depends on: 1753486
Depends on: 1751523
Depends on: 1756709
Depends on: 1759292
Depends on: 1749807
Depends on: 1772057

Redirect needinfos that are pending on inactive users to the triage owner.
:dragana, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mt)
Flags: needinfo?(dd.mozilla)
Flags: needinfo?(artymka1)
Flags: needinfo?(dd.mozilla)
Severity: normal → S3
Depends on: 1795829
Depends on: 1818483
Depends on: 1839054
Depends on: 1848840
Depends on: 1855978
Depends on: 1864877
Depends on: 1866218
Depends on: 1869515
Depends on: 1586794
Depends on: 1654690
Depends on: 1829989
Depends on: 1854653
Depends on: 1882863
Depends on: 1862630
You need to log in before you can comment on or make changes to this bug.