Re: HTTP/3 Prioritization Proposal

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

Received on Tuesday, 29 January 2019 18:57:34 UTC