Hi Martin, Wearing no hats in response inline
On Thu, Mar 27, 2025, at 01:19, Martin Duke wrote: > It was an interesting discussion last week about QMux and how to position it > clearly through naming. > > To move forward, it would be useful to describe exactly what the "threat > model" is that we are worried about. > > Is a server operator going to use QMux over TCP instead of full QUIC? IMO > that isn't responsive to the costs that are actually deterring QUIC > deployments, but I am happy to defer to those closest to customers. > > Is it that operators who currently block UDP will feel "less bad" about doing > so and feel less pressure to change? If so, that would be a sad outcome. I think "block UDP" might be too coarse a category here and it would help to refine this into a set of common scenarios where QUIC over UDP does not meet function in accordance with its targets of the deployment or the users of that deployment. Ultimately, an established connection that performs badly can often be classed as a failed connection too. For example, there will be situations where a firewall misconfiguration does cause UDP traffic to be dropped on egress or ingress of some on path component. That can trigger QUIC initiqlization connection failures. There are also cases where MTU issues can affect a QUIC connection. While we have some protocol machinery to ensure a minimum MTU, I am aware of different cases that trigger problems when attempting to use larger MTUs. One problem relates to QUIC PMTUD, whereby attempting to use a larger discovered MTU for a sustained amount of packets triggers a performance or operational penalty. Another is where QUIC DATAGRAMS are desired or required for a usecase, and how that triggers different failure modes when considering things such as MASQUE proxies, tunneling overheads, intermediary famous etc. There are situations where deployments make their own policy choices about whether to allow _QUIC_ or not. For example, out of the box Chrome doesn't permit the use of HTTPS intercepting proxies for general HTTP/3. A command line flag provides explicit opt in on a per hostname basis but that doesnt scale. As more application protocol mapping to QUIC get defined, there may be scenarios where operators want to allow X over QUIC but not Y over QUIC, according to a slew of policy choices. There are cases where both QUIC and UDP are nominally permitted but the characteristics of the deployment affect operational performance. For example, non-optimized UDP buffer tuning in the send or receieve direction. Use cases that are not data heavy or as performance sensitive can function fine in such situations, while high performance cases could deem such a situation a failure. These things don't occur in isolation either. I was in a coffee shop the other day on my work laptop, which uses a VPN with an intercepting proxy. When I tried to visit a website in Chrome it loaded. I know that didn't use QUIC because of the Chrome interception policy. If I'd have tried my personal device and it didn't use QUIC, or QUIC was slow, that might have been because of any of the other actors in the path. Trying to pinpoint that is difficult. Let alone trying to exert some pressure on them to fix their stuff. There's clearly some overlap here with the work going on in the HAPPY WG. Specifically about discoverability, selection, and reporting of misconfiguration or use of fallback modes. I'll close by highlighting that none of these scenarios indicate that a fallback to TCP is the only course of action. For example, within a data centre a deployment could start with an off the shelf QUIC over UDP implementation until they hit scaling or performance issues. At which point they might consider investing in QUIC over RDMA ad an *upgrade* Cheers Lucas > > I would like to see this work move forward, and hope we can be more > systematic about these concerns so they can be addressed properly. > > Martin > >
