Re: HTTP/3 Prioritization Proposal

Primarily for H3. Essentially to remove the ability for streams to be
dependent on other streams and require any logical grouping be explicit.

It's kind of a merging of the existing spec and the proposal to have the
individual streams still used the proposed prioritization but to keep the
grouping offered by placeholders (and to remove the ability to do
dependencies with streams themselves).

On Wed, Jan 30, 2019 at 9:14 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> Clarification question:
>
> Is your what if thinking based on H3, or did you have H2 in mind for this.
>
> H3 already has the mechanics to articulate a scheme like this, we'd just
> need some different rules about what is allowed to be a PRIORITY frame
> target.
>
> The other reason I ask is because H3 placeholders are just a logical
> construct already, divorced from concerns about stream lifetime management.
> But as FF has shown, you can achieve that kind of design in H2 with streams.
>
> On Wed, 30 Jan 2019, 22:47 Patrick Meenan <patmeenan@gmail.com wrote:
>
>> Another what-if thought. May be more complication than originally thought
>> but what it:
>>
>> - Only PLACEHOLDER streams can be parents of streams so that the tree
>> structure can only be defined by PLACEHOLDERs (let's call them "GROUPS" for
>> the purpose of this discussion).
>> - Groups can only be parents to either other groups or streams but not
>> both (i.e. only leaf nodes can contain streams).
>> - The weights on groups continue to operate the way they do today with
>> bandwidth being split between groups based on their weight relative to the
>> bandwidth available at that point in the tree.
>> - The weights on streams are changed to be a priority instead (as defined
>> by the priority proposal).
>> - The root is an implicit group "0" that behaves like all other groups
>> (can only contain either groups or streams).
>>
>> That would allow for easy aggregation of clients/tabs/CONNECT
>> streams/whatever or for splitting bandwidth between websockets, video
>> streams and http objects.  It would also make it more explicit that the
>> structure and streams are separate from each other.
>>
>> On Tue, Jan 29, 2019 at 6:47 PM Patrick Meenan <patmeenan@gmail.com>
>> wrote:
>>
>>> 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.
>>>> > >
>>>>
>>>