[Masque] Capsules

[Martin Thomson <[e-mail]>]

I've just reacquainted myself with the ever-shifting content of draft-ietf-masque-h3-datagram (-05 specifically).

My conclusion: this document is about 10x longer and more complex than it needs to be and maybe three or four times more complex than it could be if you accept some of the underlying assumptions.

---
The source of this added complexity is a desire to construct an abstract framework that allows intermediaries to participate in the protocols that this document attempts to facilitate.

The key functional role for an intermediary here is for it to take datagrams and forward them in a way that best suits the HTTP version in use, allowing the same datagram to traverse different versions.  Forwarding in HTTP/3 wants to use native DATAGRAM frames, whereas fowarding elsewhere needs to use the stream established by extended CONNECT.  The goal in creating a generic framework was to enable some common handling between different protocols (UDP proxying, IP proxying, WebTransport).

This is a bit of narrow use case.   An intermediary that understands that a capsule-based protocol can take datagrams from a stream of capsules and send them in DATAGRAM frames.  In the opposite direction, they can fold DATAGRAM frames into streams.

This forwarding behaviour depends on the intermediary understanding that the protocol in use is a capsule-based protocol.  This is done by looking at the :protocol pseudo header field on the extended CONNECT and looking that up in a list of known capsule-based protocols.  This is necessary because not all protocols that use extended CONNECT use capsules.  After all, the only use of extended CONNECT that currently exists, websockets, doesn't.

That's not so far removed from a system where the intermediary understands the contents of different CONNECT-based protocols that do not share a framework.  It is possible to have different protocols that use extended CONNECT with shared design elements that maximize code reuse at intermediaries WITHOUT a framework like this.  Those protocols can all use the same format, name, and registry if that helps maximize code reuse.  At that point that is functionally indistinguishable from the system that uses a framework.

>From this perspective, a framework like this becomes something of an academic exercise.  A lot of work is done to document the framework and describe its properties, but as the effect on deployed code is non-existent, it has no real effect on what people do.  And it comes with risks, like leading people who build intermediaries to start making bad assumptions about how extended CONNECT works generally.

The editors of the WebTransport over HTTP/2 draft are currently debating whether to propose the use of capsules there.  There, we have some interesting design constraints that might be cause to use a different format.  One option that is being considered is reusing design elements from QUIC to make the protocol easier to implement.  I don't think that we should feel constrained to use capsules, except to the extent that it might be nice to make implementation in intermediaries easier.

---
I'd like to propose a different approach:

1. When datagram support is negotiated at the QUIC transport layer, HTTP uses datagrams by associating them with request streams.  This uses the system described in the draft (prepending the stream id divided by four).

2. Different uses of datagrams need to be individually negotiated using settings.  (WebTransport negotiates use of both datagrams and extended CONNECT with a single setting.)

3. Each of the protocols we have describe the use of capsules.  Separately.

That's it.  It's perhaps a shade minimal, but it is sufficient.

I can see the advantage of a shared registry for capsule types.  That has some real advantages in terms of code reuse.  This document might be a good home for doing a little unification of the clerical stuff.  I'm OK with doing that (this is the 10x saving -> 3x saving I alluded to), but it does not need the supporting machinery in the current draft.  It just needs to make a registry, describe the generic capsule format and define the DATAGRAM capsule and forwarding rules for that capsule.  The rules that talk about opaque capsules and whatnot is unnecessary.

---
This would mean losing all the text about datagram contexts with their format types.  I can't see any justification for a generic framework for those functions.  I can see protocols in which these might be useful constructs.  However, use of those constructs would benefits from closer tuning of the mechanisms to the problem domain, something that a framework cannot do.

draft-schwartz-masque-h3-datagram-ping proposes using the format type to create a separation between that and "other" uses of datagrams.  It's important to note that identical treatment at intermediaries is a necessary feature for that draft, but I don't think that is necessary.  It also depends on datagram contexts being used, which is a big assumption as they are effectively pointless for many protocols.  WebTransport doesn't seem inclined to want them.  Should WebTransport want this, it has to pay a pretty high price (>=1 byte on every datagram sent), but that should be something that protocol decides.  Maybe that protocol can come up with a better means of distinguishing datagrams that results in less overhead.

Earlier, it was suggested that datagram contexts might be used for ECN signaling.  At the time, it seemed clever.  But now I realize that it is more like one-step forward, four-steps backwards compression.

---
Sorry for the long missive.  I hope that I was able to capture the rationale so we can discuss this next week in more detail.

Regards,
Martin