Re: HTTP/3 Prioritization Proposal

I like it and can see an easy way this could be specced up with a SETTING
that toggles the PRIORITY frame handling rule set. In other words, a
straightforward textual change, rather than a harder-to-do extension

On Wed, 30 Jan 2019, 23:20 Patrick Meenan <patmeenan@gmail.com wrote:

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