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

On Tue, 26 Jul 2022 at 14:49, 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.

I want to pull on this thread a little bit.

I agree that the reason HTTP is extensible is to allow you to extend
it. I also agree that this is one such extension that you might want.

What I'm struggling to motivate is why this extension is any business
of this WG. You don't need the WG's permission to do this, you're
already doing it. The only reason to standardise it is if you want
arbitrary other folks to do this in a way that interoperates, and you
can only really make the case that we need to standardise that if we
have some reason to assume that arbitrary peers can be made to
understand each other's metadata. I think the bar there is that we
need to have some reason to believe that a client and a server that
have no relationship to one another can successfully use this
extension to achieve a goal that they have. No-one has made the case
yet.

Cory

> 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.
>
> David
>
> On Mon, Jul 25, 2022 at 1:03 PM Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:
>>
>> Hi Biren,
>>
>>
>>
>> On Fri, Jul 22, 2022 at 8:56 PM Biren Roy <birenroy@google.com> wrote:
>>>
>>>
>>>
>>> On Thu, Jul 14, 2022 at 11:40 AM Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:
>>>>
>>>> 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.
>>>
>>>
>>> I'm not very familiar with the capsule protocol, but there seem to be two major differences: 1) we are looking for a mechanism for conveying information hop-by-hop, and it looks like capsule protocol is end-to-end; 2) we wanted something that does not affect, or is not affected by existing HTTP semantics. Unless I'm missing something, it doesn't seem possible to interleave the capsule protocol with a regular HTTP transaction.
>>
>>
>> I'd say this comes back to better understanding use-cases and whether there is general applicability. If the idea is to create a special single hop relationship between two elements, then that's a common design pattern. For example, the PROXY protocol [1].
>>
>> It sounds like your use case intermixes the actual request/response HEADERS and DATA with METADATA frames that have little to do with the HTTP request/response semantics. That's fine. Other ways to do this involve just mixing in fields directly into the messages themselves, which suffers from the problem that you have limited points during the entire interaction to do so. Either way, there is usually a "special relationship" between the client and server that are doing this handling, which is transparent to the end-user client or origin server.
>>
>> My suggestion to use the capsule protocol as an alternative is then a strawman idea that one can use encapsulation to avoid intermixing of messages and per hop metadata. For instance, a front end server that receives a request on an HTTP/2 stream would not forward it on directly, but instead issue a FOO request that enables the capsule protocol for the single hop. HTTP headers, HTTP content, and extra metadata are then encapsulated in new capsule types. The recipient of capsules either consumes the capsule (i.e. the metadata intended for it) or decapsulates the HTTP message back into a format to pass to a conventional HTTP recipient.
>>
>> Cheers
>> Lucas
>>
>> [1] - https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
>>
>>>

Received on Wednesday, 27 July 2022 16:02:29 UTC