> > FWIW we'll have a blog coming in the next couple weeks which also has > "wow!" numbers, using similar experimental setup (though obviously with our > apps instead of browsers + Alt-Svc). I would agree these are big > contributors, though elimination of HOLB does measurably help connections > with high degrees of multiplexing. The aforementioned PEPs are also often > really terrible for application performance, despite their name suggesting > otherwise. Simply bypassing these can be a big win for QUIC all by itself. >
Yes, that. I continue to believe that the TCP "ecosystem" is broken, and when you're looking at metrics from real traffic, you're going to be comparing against all the broken TCP middleboxes. There's some discussion in Google's SIGCOMM paper (section 6.5): https://storage.googleapis.com/pub-tools-public-publication-data/pdf/8b935debf13bd176a08326738f5f88ad115a071e.pdf > On Wed, Oct 7, 2020 at 5:42 PM Martin Duke <[email protected]> >> wrote: >> >>> Thanks David. I'm intrigued by your performance numbers. You say there's >>> no 0RTT and I've always thought of you guys running a pretty >>> state-of-the-art TCP stack. Is this just HOL blocking, or is there >>> something else? >>> >>> On Wed, Oct 7, 2020 at 9:50 AM David Schinazi <[email protected]> >>> wrote: >>> >>>> Hi QUIC WG, >>>> >>>> We would like to share an important announcement from Chrome: >>>> >>>> https://blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html >>>> >>>> In particular, we'd like to highlight two points of interest to the WG: >>>> >>>> 1) Chrome now supports IETF QUIC by default (h3-29). >>>> >>>> 2) Since the subsequent IETF drafts 30 and 31 do not have >>>> compatibility-breaking >>>> changes, we currently are not planning to change the over-the-wire >>>> identifier. What >>>> this means is that while we'll keep tracking changes in the IETF >>>> specification, we >>>> will be deploying them under the h3-29/0xff00001d name. We therefore >>>> recommend >>>> that servers keep support for h3-29 until the final RFCs are complete >>>> if they wish to >>>> interoperate with Chrome. However, if the IETF were to make >>>> compatibility-breaking >>>> changes in a future draft, Chrome will revisit this decision. >>>> >>>> Full details in the link above. >>>> >>>> Cheers >>>> David >>>> >>> Matt Joras >
