On Jun 25, 2024 09:00, Lucas Pardue <[email protected]> wrote:
<<As others have noted, some folks are risk averse and are happy enough with the status quo. 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.>> I know that the designated topic is performance, but please give a thought to the CISO's sign off. In a secure private network, a protocol designed to prohibit monitoring is a nonstarter. We could get further faster with QUIC deployment to these networks if there was support for secure proxy discovery with connection annealing after the proxy had applied its policies to a flow. p vixie On Jun 25, 2024 09:00, Lucas Pardue <[email protected]> wrote: On Tue, Jun 25, 2024, at 15:20, Chris Box wrote: 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. That sort of depends also. A key question has to be, how much does a use case see connection time dominating their performance user journey. The web has several techniques to pull connection times out of the critical path, things such as link preload or preconnect can ask a browser to do that. TCP+TLS with regular session resumption or 0-RTT resumption is pretty fast too. In an ideal scenario for fresh connections, you're looking at saving an RTT with QUIC. For many reasons, short RTTs are desired for performance (indeed, there's a whole CDN industry that provides this). If a complete page load, of a poorly designed page takes 20 seconds to load, shaving off 20 milliseconds is peanuts. The bigger opportunities are in improving the web page design itself, then leveraging other technologies on the content and content loading level that will make more-substantial improvements than a single RTT saving. For some use cases, absolutely saving any concrete milliseconds are a win. Its just the story isn't cut and dry as soon as you use any advanced user agent with a complex website. Where the RTT is a larger, shaving it off is a no brainer. However, that might indicate you'll have issues with BDP that can affect all transports equally. QUIC doesn't change the laws of physics :-) My anecdata is that the majority of page load oriented metric reports declare connection duration of 0. Meaning that the user is already connected. Therefore connection time optimisation is targeting a subset of journeys where a fresh connection is needed. For example, the user discovers a shopping website via an Internet search engine and clicks through. Capturing this is sometimes a different business metric. Not everyone knows or cares to measure it. It shouldn't be so hard to weigh up all these factors. Ideally there'd be some kind of common definition and more objective way to consider them but to my knowledge that's a bit lacking. 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. It's a fascinating topic! The capabilities for simulating this are woefully limited. I'm think some others can speak to their experience about how L2 technologies interact with their QUIC stacks. See Christian's blog post on WiFi for example [1]. Maybe getting better at teating this is a good item for the WG discussion. 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. That's a good way to phrase it. I'm keen to make this ranking easier to do, or eliminate its need altogether by just "Doing the right thing". It's hard when the web keeps evolving at its current pace :) Cheers Lucas [1] http://www.privateoctopus.com/2023/05/18/the-weird-case-of-wifi-latency-spikes.html 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
