W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

Re: HTTP/3 Prioritization Proposal

From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
Date: Tue, 29 Jan 2019 18:04:23 -0500
To: Patrick Meenan <patmeenan@gmail.com>
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20190129230422.GA27841@ubuntu-dmitri>
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.
> >
Received on Tuesday, 29 January 2019 23:04:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 29 January 2019 23:04:52 UTC