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

Hi,

Responding to Lucas's concern, it turns out our metadata implementation is
relatively simple.  Yes, it is a new setting identifier and a new frame
type, but HPACK/QPACK usage is trivial: a new encoding context is
instantiated for serialization of each metadata block, and a new decoding
context for parsing each metadata block (that can be fragement over
multiple METADATA frames in HTTP/2).  A single encoding/decoding context
pair could also be used for the entire connection to cut down on object
instantiation/destruction overhead.  The requirement that the HPACK and
QPACK encoding is not allowed to use the dynamic table allows for a simpler
implementation: there is no need to plumb to the shared compression context
of the connection, or--in the case of QPACK--to the decoder stream.

To respond to Cory's suggestion about making metadata use a separate
compression context: the reason we don't do that is that for our particular
use case the keys tend to be short and the values are usually unique, so we
don't expect to gain a lot from compression.  That being said, there is no
technical reason not to use a separate compression context and allow the
use of the dynamic table.  The current draft simply reflects our internal
use case, and we appreciate any feedback to make this proposal more
suitable for other people's use cases.

For example, one option could be to introduce something like
SETTINGS_HEADER_TABLE_SIZE_FOR_METADATA and
QPACK_MAX_TABLE_CAPACITY_FOR_METADATA instead of the currently proposed
SETTINGS_ENABLE_METADATA.  Any value would advertise support for METADATA
frames, the lack would mean no support, and deployments that would not
benefit significantly from compression could send 0.

Cheers,

Bence

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

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