Re: HTTP/3 Prioritization Proposal

The sequential ordering of resources is intentional and desired for pretty
much everything except for images. Scripts and CSS loaded in the order that
they block the parser using 100% of the bandwidth lets you pipeline the
loading and parse/execution so you can be executing the first script while
the second is transferring. If you load them concurrently then they all
complete at the same time (later than individual ones) and then you need to
do the parse/execution of all of them. The Chrome chaining of requests is
to achieve exactly that while the Safari and Firefox models end up with the
parallel loading and sharing of bandwidth (but they do better for images
which benefit from parallel loading). This is a real problem in the field
today where things discovered late that get inserted early in the chain
(visible images or fonts) try to attach to a stream that already finished
from the server's perspective, miss, and attach to the root with a low
weight, effectively making them the lowest priority resource instead of
highest.

My proposal explicitly allowed for that with the "no cuncurrency" groups
which transfer resources sequentially by stream ID using 100% of the
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.

On Tue, Jan 29, 2019 at 6:04 PM Dmitri Tikhonov <dtikhonov@litespeedtech.com>
wrote:

> My point is that placeholders allow a fixed structure that
> survives individual streams' lifetimes.  As for Chrome's lining
> them all up in a single chain (this seems to be a bit extreme):
> perhaps this is a case of "doctor it hurts when I do that?"
> In this scenario, there may not be enough placeholders and, true,
> one wouldn't be able to represent this -- but neither would the
> scheme you propose, which does not have dependencies at all.
>
> The type of prioritization your proposal put forth can be
> achieved -- or something close thereto -- using placeholders,
> dependencies, and weights of the current prioritization mechanism.
> In other words, clients can use this type of dependency-less
> prioritization now.
>
>   - Dmitri.
>
> On Tue, Jan 29, 2019 at 04:37:50PM -0500, Patrick Meenan wrote:
> > I don't see how that would help for the Chrome linear-list case where
> > streams of the same "priority" are attached to the end of the last stream
> > with the same "priority" (and ahead of streams with a lower priority).
> >
> > Root -> Placeholder X -> Stream A -> Placeholder Y -> Stream B ->
> > Placeholder Z -> Stream C
> >
> > If you want to insert Stream D after Stream B you would literally need a
> > placeholder between EVERY stream and they would have to live forever,
> > otherwise you risk trying to attach to a placeholder or stream that may
> > have already completed. At that point you'll blow through any placeholder
> > limit and you may as well keep all of the stream ID's indefinitely. You
> > can't sparsely populate the placeholders because you don't know where you
> > will be inserting future streams or what previous streams may be
> in-flight
> > when you go to do the insert. Even moving the placeholder to always
> > represent the "end" of a list would be racy relative to the stream that
> the
> > placeholder is currently attached to.
> >
> > On Tue, Jan 29, 2019 at 4:13 PM Dmitri Tikhonov <
> dtikhonov@litespeedtech.com>
> > wrote:
> >
> > > On Tue, Jan 29, 2019 at 02:53:55PM -0500, Patrick Meenan wrote:
> > > > As far as I can tell, the placeholder streams serve to handle the
> Firefox
> > > > use case of using idle streams for groupings, not to eliminate the
> need
> > > to
> > > > synchronize tree states. When you chain streams after each other (the
> > > > Chrome case) you need to make sure the stream you are attaching to is
> > > still
> > > > known by the server.
> > >
> > > The solution is to use placeholders: do not make one stream depend
> > > on another, but put a placeholder in between.
> > >
> > >     Some Node -> Stream A -> Placeholder X -> Stream B
> > >
> > > If Stream A goes away, Stream B is not moved:
> > >
> > >     Some Node -> Placeholder X -> Stream B
> > >
> > >   - Dmitri.
> > >
>