Re: HTTP/3 Prioritization Proposal

On Tue, Jan 29, 2019 at 06:47:13PM -0500, Patrick Meenan wrote:
> The sequential ordering of resources is intentional and desired for pretty
---- 8< ----
> weight, effectively making them the lowest priority resource instead of
> highest.

Thank you for the explanation.

> My proposal explicitly allowed for that with the "no cuncurrency" groups
> which transfer resources sequentially by stream ID using 100% of the
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is what really differentiates this proposal.  The current
prioritization mechanism does not have a way to order streams by
their IDs.  This behavior would be difficult to mimic using just
the placeholders, so I take back what I stated in my previous
email.

> bandwidth. The ordering is based on the order requested (which is normally
> the order they are in the document as discovered by the parser) and if
> something needs to jump ahead it can be given a higher priority bin.

Your proposal is custom-made for Chrome's use case, but it drops
the tree structure that may be useful for CDNs, as described in
a different email in this thread.  (It is interesting that Chrome
chooses to use the linear list model even with the problem we are
discussing.  Note that using placeholders would alleviate at least
the problem of reparenting at the root node, which would be
strictly better than HTTP/2.)

We could take the idea of prioritization by stream ID and add it
to the current prioritization scheme, thereby keeping the tree
and making it possible to construct linear dependency lists.  For
example, we have four unused bits in the PRIORITY frame [1].  We
can take one bit to mean "weigh by stream ID" or the like.

  - Dmitri.

1. https://tools.ietf.org/html/draft-ietf-quic-http-18#section-4.2.3

Received on Wednesday, 30 January 2019 16:38:19 UTC