RE: [EXTERNAL] Re: METADATA frames for HTTP/2 and HTTP/3

> We would be interested to see if other
> folks would also benefit from this capability.
==
> As a protocol extension, my feedback is that this
> seems to be a solution in search of a problem.

FWIW, this is our view as well, so I will +1 interest in seeing documented use cases to see how they require this solution over existing mechanisms for carrying arbitrary data.

Thanks,
Tommy

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Sent: Thursday, July 14, 2022 8:40 AM
To: Cory Benfield <cory@lukasa.co.uk>
Cc: Bence Béky <bnc@google.com>; HTTP <ietf-http-wg@w3.org>; Biren Roy <birenroy@google.com>; Dianna Hu <diannahu@google.com>
Subject: [EXTERNAL] Re: METADATA frames for HTTP/2 and HTTP/3

Hey,

On Thu, 14 Jul 2022, 16:32 Cory Benfield, <cory@lukasa.co.uk<mailto: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<mailto: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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbencebeky%2Fmetadata&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C895cf519a6454d5e251f08da65afb927%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934102674782248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RNKSUaWukRX2Z6AEeSdx6rNWMTVy8tjQ5LFyvGuWbLE%3D&reserved=0>.
>
> Thank you,
>
> Bence
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org<mailto: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<mailto:bnc@google.com>>, Biren Roy <birenroy@google.com<mailto: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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-beky-httpbis-metadata-01.txt&data=05%7C01%7CJensen..Thomas%40microsoft.com%7C895cf519a6454d5e251f08da65afb927%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934102674782248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9YNTT3dHMnbQvDe7PxoMWvx8EWFyM2oKdN2GGuepBJM%3D&reserved=0>
> Status:         https://datatracker.ietf.org/doc/draft-beky-httpbis-metadata/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-beky-httpbis-metadata%2F&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C895cf519a6454d5e251f08da65afb927%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934102674782248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AmeuQF1ZgS%2Fu7Kl3BYWqLgCCZyEjZX%2BNcthdbdpb%2BFs%3D&reserved=0>
> Html:
> https://www.ietf.org/archive/id/draft-beky-httpbis-metadata-01.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-beky-httpbis-metadata-01.html&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C895cf519a6454d5e251f08da65afb927%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934102674782248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PG%2BoQzL28lMslLty3xCQay475%2BAr1N%2BbyO9PkTIeJtI%3D&reserved=0>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-beky-httpbis-metadata<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-beky-httpbis-metadata&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C895cf519a6454d5e251f08da65afb927%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934102674782248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9REqHSyVzT8ctVmu6H0eoi2%2FHvvo11r25c9S7EjbvF4%3D&reserved=0>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-beky-httpbis-metadata-01<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-beky-httpbis-metadata-01&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C895cf519a6454d5e251f08da65afb927%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934102674782248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TnKdAnfNSk0Jnp198mgh4ej3yUETMPROsjsTyiANspY%3D&reserved=0>
>
> 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
>