Re: METADATA frames for HTTP/2 and HTTP/3

Hi David,


On Tue, Jul 26, 2022 at 2:49 PM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

> Hi Lucas,
>
> I don't think capsules are a good fit here. Our deployment involves
> traditional HTTP intermediaries that speak standards-compliant HTTP between
> each other, except that we want to add a little bit more information. This
> is the very reason that HTTP was made to be extensible, to allow adding
> features without having to build your own custom protocol like PROXY. For
> example PROXY would be a huge performance hit because it would conceptually
> require falling back to h1 and we see significant gains from the connection
> reuse properties of h2 and h3.
>

Right. I'm not saying you should use PROXY protocol here (apologies if that
was unclear). What I'm saying is that deployments that care about adding
sidecar metadata in the way I think you are using it, probably already have
a solution for doing that, which isn't METADATA frames. That's typically by
virtue of some out of band or private arrangement within an organization or
between entities with a business relationship.

To quote what mnot said earlier:

> There's no semantics to 'grab onto', nothing an intermediary can do
without application-specific knowledge or configuration, etc.

> If the use case is telemetry, we could talk about how that might be best
accommodated in the protocol, and it might end up as a TELEMETRY frame (or
header, or trailer, or resource...). As it is, this is just another
tunnelling mechanism, and we already have a lot of options there.

I agree with this.

If I'm reading things correctly, it seems to make a presumption that it is
easy to add to the long tail of HTTP applications, which I'm skeptical
about because even things like 1xx responses are not well supported even
today. Biren stated a desire for the METADATA frame to be treated as
hop-by-hop, but the second paragraph of the intro states: "An HTTP
intermediary MAY consume METADATA frames, pass them along unmodified,
modify the payloads, or emit new METADATA frames, depending on the specific
needs of the application" - this raises a tone of questions about what
applications should do, beyond just what the wire format allows them to do.
A client that can influence load balancer decisions seems bad in the same
way that the Forwarded header field might be abused [1]. In the reverse
direction, it might expose information about the server(s) to clients that
could aid forms of attack.

mnot mentions tunneling mechanisms. If you only care about
private-arrangement communications within intermediaries, there's lots of
options. Using capsules is one such mechanism that has recently been
defined in the IETF, which could easily support the use case. I'm not
advocating strongly to do it that way (it probably has more overheads than
we'd like) but it would help to understand why something like METADATA is
prefferable to other mechanisms.

Cheers,
Lucas

[1] - https://www.rfc-editor.org/rfc/rfc7239.html