Re: HTTP/3 Prioritization Proposal

I need to dig into the extensions mechanism a bit but does it require
negotiation (I would imagine it does to some level)? My main concern would
be to figure out how to pull off the prioritization without adding round
trips. If the new prioritization byte also made sense as a "weight" for
most implementations without breaking prioritization for servers that don't
understand the new scheme it might be possible to send the extension frame
and stuff the priorities into the weight field and still have servers that
don't understand the new prioritization do the right thing with the
existing trees.

On Mon, Jan 28, 2019 at 5:21 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> Hey Mark,
>
> On Tue, 29 Jan 2019, 06:58 Mark Nottingham <mnot@mnot.net wrote:
>
>> My sense is that people know that we need to do something about
>> prioritisation, but we're not yet confident about any particular solution.
>> Experimentation with new schemes as HTTP/2 extensions would be very
>> helpful, as it would give us some data to work with. If you'd like to
>> propose such an extension, this is the right place to do it.
>>
>
> The small amount of thinking I did on this lead me to a different
> conclusion. That it would be easier to experiment with new prioritization
> schemes in HTTP/3, due mainly to the removal of priority information from
> the H3 HEADERS frame. This makes it quite feasible to write an extension
> along the lines of "the extension replaces/supersedes the base standard
> PRIORITY frame when negotiated". In contrast, a H2 extension either needs
> to define a new HEADERS format or provide supplemental information in the
> form of a new frame, which is possible but a bit redundant.
>
> There didn't seem to be much appetite for adopting H3 priority placeholder
> design in H2 (I cant remember when this was presented, sorry). I'd be
> curious to know if there is more interest in other alternate priority
> schemes in H2.
>
> Lucas
>
>>