Re: [Masque] Capsules

[David Schinazi <[e-mail]>]

Hi Martin, thanks for reading the latest draft. Responses inline.

David

On Mon, Nov 1, 2021 at 11:25 PM Martin Thomson <[e-mail]> wrote:

> 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.
>

Speaking for myself as co-author of the draft, constructing an abstract
framework was never my desire. I care about the properties of the system
we're building, not about abstract concepts.

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).
>

Agreed. My implementation supports both WebTransport and CONNECT-UDP, and
there's definitely value in reusing the code that sends and parses
datagrams and capsules.

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.
>

I'm confused here. In order to reuse code, it makes sense for multiple
protocols to share the capsule TLV wire format and the IANA capsule type
registry. Since protocols will share the IANA registry, you need to define
it in this doc. At that point it makes sense to also define the capsule TLV
format here as well since we see value in reusing it. Copy-pasting the TLV
format in every protocol document doesn't help us. If you don't like the
word "framework", then don't use that word?
draft-ietf-masque-h3-datagram-05 doesn't contain the word framework,
because it doesn't attempt to create a framework. Only to define pieces
that can be reused.

>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.
>

I fully agree with you that we would get the exact same software if we took
some parts out of this document and copied them verbatim into every
protocol that uses datagrams. I don't see that as helpful though.

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.
>

You shouldn't feel constrained to use capsules, you should only use them if
they provide value. Out of curiosity: what are the design constraints that
would steer you to a different protocol?

---
> 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.)
>

What does "different uses of datagrams" mean? If one of my backends
supports CONNECT-UDP, why do I need a SETTING on the client-frontend leg?

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

This is just moving rocks, and increases the total number of lines of spec
written. What's the benefit of copy-pasting something in multiple documents
if they all depend on a common draft?

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.
>

The introduction of opaque and transparent capsules was done as an
editorial clarification to help readers understand the concept of capsules.
We can remove those terms, but we still need the concept of injecting a
datagram into the stream when going from h3 to h2.

---
> 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.
>

I think the value here is the definition of extensions that work across
multiple protocols. draft-schwartz-masque-h3-datagram-ping is a perfect
example of that: there's been discussion in WebTransport of adding a
JavaScript API at some later date that would tell the JavaScript what the
datagram MTU is. Having this MTU information would also be useful for
CONNECT-UDP and CONNECT-IP. What you're suggesting is that every single
protocol redefines this. That's not reducing any complexity, just kicking
the can down the road.

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.
>

Can you clarify what your goal is? It sounds like you would prefer for this
document to be shorter. I agree with that goal, but it shouldn't be done in
a vacuum - we should look at the total length of the MASQUE/WebTransport
documents.

Regards,
> Martin
>
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>