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

Sorry for the delays replying to the feedback on this list. I'll try to
address your feedback. Thank you for the constructive criticism!

On Thu, Jul 14, 2022 at 11:27 AM Cory Benfield <cory@lukasa.co.uk> wrote:

> Hi Bence,
>
> I’ve read through the draft. The proposal seems straightforward enough.
>
> I’m surprised by the usage of HPACK, though. The document implies (but
> does not state) that the METADATA frames use the same HPACK encoder/decoder
> pair as the regular HTTP/2 streams. I read this implication through the
> forbidding of HPACK/QPACK messages containing any operation that would
> change the state.
>
> This seems like it both makes it easy to accidentally fail to comply with
> the spec (by not carefully reading that one clause) and reduces the
> efficiency of the compression (by forbidding the use of the dynamic table).
> Has thought been given to establishing a separate HPACK encoder/decoder for
> METADATA frames? That would make it easy to avoid needing to negotiate the
> frames, and would also let you take advantage of the dynamic table for more
> efficient encoding of the metadata.
>

For our deployment, we won't see any benefit from compression, so for
simplicity we're always using the HPACK literal encoding. For the purposes
of the specification, however, I think we could state that a separate
compression context is used for METADATA frames.


> As a protocol extension, my feedback is that this seems to be a solution
> in search of a problem. This certainly adds protocol capabilities, but
> without specifying any intended use-cases it doesn’t do a good job of
> justifying why headers are unsuitable for the task. I think I’d like to
> hear the folks with more insight into HTTP’s semantic layer chime in as to
> whether they think this is a good fit. As an extension to HTTP/2 I think it
> fits well.
>

One issue with headers is that you only have the ability to convey
information at certain points during the HTTP transaction. We've found that
sometimes we need to convey load balancing information (for example) on an
ongoing basis for long lived streams.



>
> Cory
>
> > On 12 Jul 2022, at 07:16, Bence Béky <bnc@google.com> wrote:
> >
> > Hello HTTP WG,
> >
> > I submitted our proposal to define METADATA frames for HTTP/2 and
> > HTTP/3, see below.  This has been used internally at Google over
> > HTTP/2 for years to help load balancing and diagnostics among other
> > things, and we are currently working on the HTTP/3 implementation to
> > support the same use cases.  We would be interested to see if other
> > folks would also benefit from this capability.  Please feel free to
> > share your thoughts on this list, or by creating an issue at
> > https://github.com/bencebeky/metadata.
> >
> > Thank you,
> >
> > Bence
> >
> > ---------- Forwarded message ---------
> > From: <internet-drafts@ietf.org>
> > Date: Mon, Jul 11, 2022 at 5:57 PM
> > Subject: New Version Notification for draft-beky-httpbis-metadata-01.txt
> > To: Bence Béky <bnc@google.com>, Biren Roy <birenroy@google.com>
> >
> >
> >
> > A new version of I-D, draft-beky-httpbis-metadata-01.txt
> > has been successfully submitted by Bence Béky and posted to the
> > IETF repository.
> >
> > Name:           draft-beky-httpbis-metadata
> > Revision:       01
> > Title:          METADATA frame for HTTP/2 and HTTP/3
> > Document date:  2022-07-11
> > Group:          Individual Submission
> > Pages:          8
> > URL:
> > https://www.ietf.org/archive/id/draft-beky-httpbis-metadata-01.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-beky-httpbis-metadata/
> > Html:
> > https://www.ietf.org/archive/id/draft-beky-httpbis-metadata-01.html
> > Htmlized:
> > https://datatracker.ietf.org/doc/html/draft-beky-httpbis-metadata
> > Diff:
> https://www.ietf.org/rfcdiff?url2=draft-beky-httpbis-metadata-01
> >
> > Abstract:
> >   This document describes a mechanism to send meta information over
> >   HTTP/2 and HTTP/3 connections that refers to either the entire
> >   connection or a specific stream without changing the semantics of the
> >   HTTP messages.  This mechanism can be used, for example, to gather
> >   information for accounting or logging purposes.
> >
> >
> >
> >
> > The IETF Secretariat
> >
>
>