Re: HTTP/3 Prioritization Proposal

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.
>