[Webtransport] Layered or integrated protocols

[Martin Thomson <[e-mail]>]

I was originally just going to announce here that I've made a contribution to the discussion on how to map WebTransport semantics to HTTP.  To be honest this isn't a mapping to HTTP, it's more of a burrow into.

In case you want to read it, here it is: https://www.ietf.org/archive/id/draft-thomson-webtrans-hwtq-00.html

However, in discussing this with Alan Frindell and Eric Kinnear I realized that the designs we are all proposing are based on a bunch of assumptions.

The HTTP/2 integration in draft-ietf-webtrans-http2-00 assumes that the shortest path to expressing WebTransport semantics in HTTP/2 is to reuse HTTP/2 stream semantics as much as possible, adjusting where necessary.  That has a lot of merit, especially when you consider the potential reuse you get of multiplexing, priority, and whatnot.  It's not perfect, but you can make it work with a few precise tweaks.

Then I looked at where MASQUE is headed.  Despite a lot of similarities in what we are seeking to do, the differences there are nearly complete.  Extended CONNECT vs. CONNECT-UDP and capsules vs. frames mean that the two things might look similar, but they share very few design elements.  We are headed toward building one protocol for MASQUE and two completely different protocols for WebTransport.

I don't know what happened to the design of MASQUE that I originally saw, but to me that was a much cleaner layering.  That is, you establish a tunnel (using CONNECT-whatever) and then you use the resulting bidirectional stream to do whatever is necessary.  Then, if you have something better (as you do if you are using QUIC) you move things to their own streams or datagrams as the opportunity arises.

That basic design works for both WebTransport and MASQUE regardless of the HTTP version.  The cost is that a light integration with the underlying protocol forces the design to provide its own resource management and prioritization features.  Multiplexing without flow control is a good way to get bad outcomes, after all.  That might result in some duplication of effort, even bad interactions as you move from a two layer system (connection>stream) to a three layer system (connection>session>stream) in the extreme case.

What we have right now is deep integrations.  That has the aforementioned advantages, but it means that you need to own your stack before you can implement the extension.  That is, in their current form, you can't build WebTransport or MASQUE by taking an HTTP implementation and building *on* it, you have to build *in* the stack.

Deep integrations have a few advantages, particularly when it comes to reusing existing mechanisms.  The HTTP/{2,3} mapping can use HTTP/{2,3} stream flow control and prioritization (assuming that you have already replaced the RFC 7540 scheme for priority, that is).  But they are invasive and can be high maintenance.

Layering protocols avoids coupling at the cost of being constrained by the abstractions of the layers that are used.

One thing that I wanted to do by suggesting a layered design - aside from the architectural split - was to isolate the resource management for WebTransport sessions from the other resources consumed on the connection.  For instance, it would help if two sessions share a connection, then maybe they can each make progress if the other is determined to exhaust the stream limit.  Per session limits are a natural consequence of a layered design.  However, if we don't need that capability, it's not necessarily an advantage.  We should talk about whether we need per-session limits for WebTransport.  Same for MASQUE.

Eric mentioned one point that I hadn't considered.  A generic mapping of QUIC stream and datagram semantics to a stream transport might be more broadly useful.  If that has multiple uses, then that might be good motivation for a layered design.

I don't have a concrete example in mind, but I can offer is the fact that people want to use QUIC in other contexts and they probably do want a TCP fallback also.  If they can't just use WebTransport (which is possible), a generic mapping could be helpful where an HTTP/2 implementation might not be.  An HTTP/1.1 mapping would be the next best thing.  (From my perspective, however, I would never seek to make a purely generic mapping, but rather seek to make large parts of the design trivially reusable in a new mapping.  That's almost the same thing, but I've never seen a generic protocol mapping design that didn't end up full of weird stuff that handled irregularities in one substrate or other.  Or, for programming nerds: monomorphism > generics.)

Anyway, this is a long message to basically ask that we be deliberate about our choices.  I don't think that anyone has chosen the integrated path thoughtlessly, but I want to ask that we collectively step back and make sure that this is really what we want.  That might mean talking about the reasons that push toward integrated designs or more about our resource management requirements.

Cheers,
Martin

p.s., https://datatracker.ietf.org/doc/html/rfc1958#section-3 contains some wrongness (3.9) and some points that can be read any number of ways here (3.5), but I think that point 3.6 argues for layering.