Subject: Re: [Webtransport] Measuring the friction of Http3Transport

From: Alan Frindell <[email-masked]>
Date: Wed, 2 Dec 2020 17:27:41 +0000

Thanks Lucas for your thoughts here.  I have some responses inline.

> It is not clear to me if session multiplexing is needed due to mixing with HTTP/3, or if it is intentionally extended behaviour over QuicTransport.

It appears be intentionally extended behavior.  One could implement similar session multiplexing in QuicTransport, or as you suggest, remove session multiplexing from Http3Transport.  In the latter case, Http3Transport would use a single stream to negotiate the endpoint for WebTransport streams and datagrams, as QuicTransport does now.

> I suggest that permitting only one session per QUIC connection would vastly simplify Http3Transport.

I agree that is true, but still prefer to retain multiplexing WebTransport sessions on a single QUIC or H3 connection.  As I mentioned during the meeting, there are benefits to multiplexing sessions on a single connection that are lost when using multiple connections (shared congestion control, prioritization and server resource usage).

> You can even drop the special WEBTRANSPORT_STREAM frames that squat on client bidi streams, and instead just require that streams are upgraded to WebTransport purpose using Connect (ala RFC 8441).

I think this is an interesting idea that warrants more exploration.

1. Does a single stream still perform the handshake function, as in QuicTransport, or are you suggesting each stream performs its own handshake?

2. If WebTransport streams are using CONNECT, but not performing a handshake, what values go in the :authority and :path headers, or are they omitted?

3. Do unidirectional and server-initiated bidirectional WebTransport streams also send CONNECT?

> Doing this means that changes needed to H3 libraries approaches zero; it aligns with the frontend changes that MASQUE is detailing, which came up during the interim call.

The comparison to MASQUE is interesting.  CONNECT-UDP is very similar to an Http3Transport CONNECT stream:

1) It correlates a destination with an identifier

2) The CONNECT-UDP stream must remain open for the forwarding to continue

3) You can have multiple concurrent CONNECT-UDP sessions on a single connection.

Pooling or multiplexing WebTransport sessions is the same concept, except that it extends to streams as well as datagrams.

There was also a suggestion to use MASQUE itself to handle the pooling use-case.  If I understand that correctly, each WebTransport session would use CONNECT-UDP to a destination, then begin tunneling a new QuicTransport session using the negotiated Flow-Identifier/Connection ID.  While I think that might address the some of the drawbacks of using a connection per WebTransport session, it would have a side effect of hiding WebTransport streams and datagrams from intermediaries.  This is not desirable for our use cases, though I suppose some might find that to be a feature.

> As Luke highlighted in his Github issues, there are serious footguns in the API; mixing WebTransports onto a single QUIC connection in a non-transparent way is like have two guns pointing at you and your buddies feet. The suggestion that pooling can be avoided by using different hosts endangers that becoming the only KISS deployment option if devs care about determinism. So why take on board the complexity even to start with?

I agree there are potential problems from introducing an additional multiplexing layer without providing a way to manage shared resources (eg: flow control, streams) at that layer.  But doesn’t this problem already exist for browsers with HTTP?  Eg: I open multiple tabs that send HTTP requests on the same connection, and these may use/abuse streams and flow-control at their own discretion.

-Alan