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

On Tue, Jul 26, 2022 at 2:22 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

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

The key difference is that this inherits all of the features of HTTP. You
just need to add the metadata. Other proposals like capsule require
inventing and implementing a whole new way of sending what HTTP already
sends today like the message.

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

Possibly. We'd love to hear from anyone with such a deployment.

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

I don't know much about Server-Timing, but I agree with the sentiment that
trailers make life sad.


>
>
> Cheers
> Lucas
>
>