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

Hi David,

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

>
>
> On Tue, Jul 26, 2022 at 12:24 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
> wrote:
>
>> 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.
>>
>
> This was an oversight in the -00 version of the draft, which was corrected
> in the following PR. That should address those security concerns.
> https://github.com/bencebeky/metadata/pull/10/files
>
> 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.
>>
>
> There is definitely an infinite array of solutions, but this one is very
> practical because it is very easy to implement when you already have an
> HTTP intermediary - it incrementally adds to HTTP instead of building
> something from scratch.
>

I'd appreciate hearing more on this. What makes it easier to implement this
mechanism (which requires an implementation to support a new frame type
that integrates with HPACK or QPACK, and then for me to add to code to
produce and consume it) vs. other things. Some APIs I know have little or
few ways to actually do this (hence my earlier skepticism comment).

Tangentially: the restriction that it is _only_ hop-by-hop might be overly
restrictive for some types of deployments.

Tangentially: if you were to support METADATA frames from server-to-client
(and why not?) then there is overlap with the Server-Timing [1] field. I
think that illustrates a more concrete form of "telemetry" that mnot was
possibly alluding too. The interesting thing with Server-Timing is the
difficulties it has found working in HTTP trailers in practice. And that
might help inform some of the discussion here.

Cheers
Lucas