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

Hey,


On Thu, 14 Jul 2022, 16:32 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.
>
> 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.
>

I'll echo the points Cory made.

I'd push the use case queation further and ask why would I use METADATA
frames rather than the capsule protocol to do the equivalent thing? I
expect you probably already have an answer to that,  so explaning the
tradeoffs might help.

Cheers
Lucas



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