A few separate questions come to mind:
1. What to call the new API Surface that QUIC and WebTransport expose,
if anything?
1. My current best suggestion is 'Streamy' because it indicates what
it is and QMux did not get good feedback in my impromptu
marketing workshop
2. How to map that API surface onto TCP, RDMA, Unix Domain Sockets, etc
to allow running HTTP/3, MoQ and other applications on that?
1. I agree with Lucas that sometimes a non-RFC9000 transport would be
an upgrade. For example, it's difficult to imagine beating Unix domain
sockets when they're available.
As the MoQ working group has come to recognize, MoQ isn't always over QUIC,
but it does require a certain API surface, including Streams, Datagrams,
and an ALPN-like mechanism.
Thanks, Ian
On Wed, Mar 26, 2025 at 11:55 PM Lucas Pardue <[email protected]> wrote:
> 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
>
>
>
>
