Re: HTTP/3 Prioritization Proposal

Ok, Dmitri's hit the nail of my thought  here so I'll be explicit

You might be able to achieve close to Pat's target design by declaring a
certain number of placeholders and assigning weights to them, meanwhile
ignoring other priority types in H3.

There are, of course, other options in this space. The elephant in the room
of the discussion is negotiang this stuff.

On Wed, 30 Jan 2019, 04:00 Dmitri Tikhonov <dtikhonov@litespeedtech.com
wrote:

> On Tue, Jan 29, 2019 at 09:51:36AM -0500, Patrick Meenan wrote:
> > The biggest issue (at least currently) that I know of with the need to
> > synchronize the current priority trees is when adding new streams as a
> > child of a stream somewhere in the existing tree. The client has to hope
> > that the server still knows about the parent stream that the new stream
> is
> > being attached to, otherwise it gets dumped to the root with a weight of
> > 16. This is a very real edge-case that, while known, impacted at least
> the
> > h2o and Google HTTP/2 server implementations serving traffic to Chrome.
> My
> > initial test for HTTP/2 prioritization triggered the edge case quite
> > reliably (unintentionally). h2o has since worked around it by
> "remembering"
> > some completed streams but I believe the Google edges are still impacted
> > (and I'm not sure about other implementations).
>
> The current prioritization scheme in HTTP/3 (I am referring to the
> current draft at version 18 [1]) uses placeholders, which solve
> this exact problem.  The client no longer has to rely on hope.
>
> Are there other problems the current prioritization scheme possesses
> that cannot be boiled down to "programming is hard?"  I agree with
> Amos Jeffries, who writes:
>
> > On Mon, Jan 28, 2019 at 9:19 PM Amos Jeffries <squid3@treenet.co.nz>
> wrote:
> > > The rational conclusion then is that better Browser implementations
> > > would solve these particular annoyances. So what problems exactly are
> > > preventing that better implementation happening?
>
> For this proposal to be accepted at this late stage in the game, it
> should be demonstrably, non-marginally better than the current
> mechanism.  It may be better than HTTP/2; but I don't see how it is
> better than HTTP/3 [1].
>
>   - Dmitri.
>
> 1. https://tools.ietf.org/html/draft-ietf-quic-http-18
>
>