Hi, below are Cullen's raw notes from the side meeting. Thanks for letting me share them!
(We tried to use the "AI summary" feature of the conferencing system, but somehow that ended up not producing any summary, AI or not. Probably pilot error on my part, sorry.) We're planning to continue the discussion in some form, please let me know if you'd want to be included. Thanks, Lars > Begin forwarded message: > > From: Cullen Fluffy Jennings <[email protected]> > Subject: Notes from QUIC side meeting > Date: November 6, 2025 at 00:03:32 GMT+2 > To: Lars Eggert <[email protected]> > > About 40 people in room and a few online. > > > > We are about 30% market share of bandwidth. Could we get more. > > Do we want more bandwidth share or more apps on QUIC. > > > Today web server developers etc just go with the default. Things are not > enabled by defaults > > Enterprise networks. Often UDP 443 is blocked. > > NO good answer to how much better is QUIC. Thus CDN do not enable by default. > > If browsers could provide a signal of what they could do, they could provide > a signal. > > People say QUIC better than TCP, yes in theory but in practice it may not, or > may not be much better. > There are deployments where QUIC is slower. > > The 30% is the percentage of connections that come to clouudflair that are > likely to be humans. Bots very different. > > Enterprise are doing new form of certificate pining. Not working on new > chrome security settings. > > People disable QUIC when see third party roots because of shitty QUIC proxy > implementations. This contributes to why it is not working in enterprises. > > Happy Eyeballs is one aspect but just because you can get a connection does > not mean it is going to be good. Might work well in some fraction of the > planet, but then bad some places. Too hard to be selective in places where it > does get worse. Easier to turn off than enable. > > Also plays into multi CDN. > > Still about 50% on QPS and about 2/3 on youtube. > > For meta and youtube app to mobile might be over 90%. [ my notes may have > this wrong ] > > TV never upgrade and if they do old QUIC they are very old. > > So apps on personal mobile tend to have higher usage than browsers. > > Multi CDN, issue that should be solve. Such as DNS based load balancing. > > Most website developers do not have good metrics. Most websites don’t care > much about latency. > > QUIC is more computation expensive than TCP and in places with bad > infrastructure, it does not make sense. > > Netflix has 800 MBps server that runs TCP. Not there yet with QUIC. > > Perhaps not more QUIC but QUIC more accessible. > > People want metrics on how much better it is but very hard to get from just > the server side. > > QUIC only turned on if shows a benefit. Might be startup time, might be > reduce latency, might be survive network connection changes. > > Not clear on why SVRC working or not > > Not clear there is a killer app that would be better on QUIC not on QUIC > > Masque using it and DoH and MoQ. > > QUIC starts from user side instead of kernel side is seen as a security issue > by some. > > A venue to bring observations and deliver things to fix would help. > > How we can allow flexibility of QUIC for a larger thing > > For measurement data, chrome has long running experiments. Might be able to > get some of that data visible. > > Power efficiency etc. TCP with TLS is easier to fill a NIC but in most > applications cannot tell CPU difference as other things dominate. Not true > video servers. Have to compare apples to apple. > > Congestion controllers are a huge pain but big win and need to make sure the > congestion control is competitive with TCP when doing comparisons > > Why move, want to kill HTTP 2 dead. Fine with HTTP 1 and 3. > > MoQ uses partial and reliable data. > > H2 is good enough that it does not create the pressure to fix H3. Could we > default to H3. > > If people are doing migration, very hard to move particularly if you have POC > of staging. Makes really crappy experience in the way the errors come across > in a transition time. Delay and exponential back off and max expires made > this more complicated > > Data from Firefox: 25% of connection H3. 20% H1 , and rest H2. This is from > Firefox release. This data is publicly available. > > Mozilla typically happy to do experiments as long as cannot identify the > users. Use groups of 5000. > > Disable everything if they see a 3rd party cert on path. Do not want to debug > more anti virus software. > > Make it easy for browsers to run an experiment. > > All the experiments seem to be run on network intensive applications. But > when looking people developing applications, they mostly don’t care. Just use > whatever the language provides. Need better tools in programming languages to > make it easier to use QUIC. > > Implementing a good congestion controller that can match TCP performance has > been more work than implementing QUIC itself. Need more focus on this. > > Consider advantages QUIC have and improve them. > > Getting QUIC stack out means we can build on top of it. > > HTTPS / DNS record front. Worried that some parts of the RFC are not well > understood so important as it gets implemented to make sure we get it right. > > Might be good to have a trusted forum to share experience > > The BBR was not as good for interactive VoIP use cases and thus the > development of C4 congestion control.. > > If they can inspect flows, banks will not use. Point made they can as they > own the servers. > > SSH developers very focused on security and transferring to QUIC was just too > much without good APIs from where they were. It would take too much change to > the code. Reason not to move. > > Would be nice to have a socket shim API for QUIC for C applications. > > Long tail of private small scale servers. Have not seen uptake in that. Need > to find a way to make it easy for them to use. > > All first party servers at google have enabled QUIC. This has gone pretty > smoothly. > > At one point had list for AS where QUIC is worse but mostly got it to zero. > Still situation where some ISP that just block QUIC all the time. > > QUIC on TCP then migrate to UDP. > > Look into the space of multi CDN issues. Might be able to get some best > practices. > > Quic Ops Forum. Perhaps Chatham house style. > > People worry that QUIC experimental thing that might go away. > > Really good to get apples to apple performance measurements. > > If you want NIST to acknowledge QUIC, would need formal verifications. > > > > > > > >
signature.asc
Description: Message signed with OpenPGP
