Thanks for the update Matt, that's quite a success story. You note that you're not currently using 0-RTT in QUIC. Can you share why? Chrome won't have 0-RTT enabled in Stable until M87(November), so we don't have reliable metrics yet, but we're expecting improvements.
Thanks, Ian On Wed, Oct 21, 2020 at 12:31 PM Matt Joras <[email protected]> wrote: > All, > > I'm excited to finally publicly share some of the work we've been doing on > QUIC in recent years. You can read about it on the Facebook Engineering > blog here > <https://engineering.fb.com/networking-traffic/how-facebook-is-bringing-quic-to-billions/> > . > > The headline is that 75% of Facebook's Internet traffic is now QUIC and > HTTP/3. In real terms this amounts to QUIC being fully enabled in the > Facebook and Instagram mobile apps. We have had production traffic using > QUIC on the Internet for over two years, but have dramatically increased > the volume through 2020. We have been able to do this because QUIC has > consistently shown significant empirical improvements over TCP. Importantly > I'd like to stress that these aren't simply "performance" improvements, but > rather measurable improvements to the application experience. > > A few things to note: > - QUIC is enabled for all content in both apps, and is utilized for media > upload as well. > - The baseline HTTP for the apps is either HTTP/2 (for the Facebook app) > or HTTP/1.1 (for Instagram). > - The baseline transport server-side is vanilla Linux TCP + BBR with > sensible TCP tuning. Our QUIC implementation doesn't diverge majorly from > the drafts except for the use of BBR as the CCA. > - Our TCP baseline uses TLS 1.3 and early_data, with the vast majority of > connections resuming. > - We are not currently using 0-RTT for QUIC. > - We are not currently using connection migration. > - We use a default UDP payload size of 1232 or 1252 depending on the IP > version, and do not yet have our DPLPMTUD implementation enabled. > - None of the quoted metrics include browser traffic, though we have had > QUIC enabled on Facebook and Instagram web endpoints for about a year. As > of today about 56% of Chrome stable traffic towards our servers is using > QUIC, though we do not control the sampling so we cannot make very > definitive statements about improvements. > > We believe several factors contribute to QUIC's significant advantage. A > major factor which is often overlooked on paper is QUIC's ability to > utilize modern loss recovery and congestion control undisturbed by the > myriad middleboxes on Internet networks. The others we all like to mention > in theory clearly play a role in practice as well. > > The linked post is targeted at a wide audience, so it naturally may leave > people with questions. I'm happy to answer and provide more detail in this > forum. > > I'd also like to thank everyone for your tireless efforts on this protocol > over the last few years. You're a remarkable group of people and I hope > this serves as one among many votes of confidence in QUIC as the future of > Internet transports. > > Thanks, > Matt Joras >
