On Tue, Jun 25, 2024, at 17:39, Paul Vixie wrote: > 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.
Secure proxy discovery and configuration would be useful for a number of use cases beyond just QUIC. I totally support the idea of people working on that in the appropriate IETF venue. Cheers Lucas > > 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 >>
