On Tue, 25 Jun 2024 at 14:05, Lucas Pardue <[email protected]> wrote:
> > It can be difficult to monitor and prove with actual data that end-users > see meaningful performance improvements due to leveraging the features of > QUIC. > I'm surprised, as I'd expected the faster connection setup to be a win across all networks. But yes the specifics matter, and it's important to be able to spot areas where it's slower. As a platform or service operator, its likely that you'll have no idea what > the KPIs of the web applications that pass through you are. Focusing on > low-level observables, such as connection or request times doesn't give the > full, actual, picture. There is a disjoint, that can be hard to fill. > My day job involves a lot of mobile network optimisation. We regularly conduct drive tests to see the effect of network changes on end-user performance. The services tested are necessarily limited. Seeing the results of changes immediately and across the entire country, would be a big win. But perhaps not a topic for this working group. > There's only so much engineering hours to go around, and companies make a > value judgement about where to invest that for peak ROI. > If there are performance wins to be had, they'll likely be wanting to see > case studies before the CTO signs off on turning something on that might > even have the slightest hint of beung able to cause some regression in > performance or stability. > Great point. So in a ranking of potential web performance gains, HTTP/3 may not place high enough. And in other companies, there could simply be a shortage of data to understand where it should be ranked. It also behoves me to mention we have QUIC powering the web in different > ways than the OP question presents it. > Oh, definitely. QUIC goes far beyond this use case, and MASQUE for example is an important building block for privacy partitioning. I'm all for further deployment of QUIC. It's the first truly *evolvable* internet-scale transport protocol. Chris
