Re: HTTP/3 Prioritization Proposal

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. It is, of course, solvable by either a FIN/ACK before
deleting completed streams or the server keeping completed streams long
enough that the client will know they are completed (something larger than
BDP).

If the bar is too high this late in the process to change things then
that's fine and we can revisit it later with extension frames or HTTP/4 in
a few years. My hope was to introduce something that was easy enough to
plug into existing browser and server architectures that it would be able
to be used effectively. Yes, "programming is hard" but if that difficulty
prevents effective adoption and utilization of the protocol then it becomes
a problem for everyone.

On Tue, Jan 29, 2019 at 2:40 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> Ok, Dmitri's hit the nail of my thought  here so I'll be explicit
>
> You might be able to achieve close to Pat's target design by declaring a
> certain number of placeholders and assigning weights to them, meanwhile
> ignoring other priority types in H3.
>
> There are, of course, other options in this space. The elephant in the
> room of the discussion is negotiang this stuff.
>
> On Wed, 30 Jan 2019, 04:00 Dmitri Tikhonov <dtikhonov@litespeedtech.com
> wrote:
>
>> On Tue, Jan 29, 2019 at 09:51:36AM -0500, Patrick Meenan wrote:
>> > The biggest issue (at least currently) that I know of with the need to
>> > synchronize the current priority trees is when adding new streams as a
>> > child of a stream somewhere in the existing tree. The client has to hope
>> > that the server still knows about the parent stream that the new stream
>> is
>> > being attached to, otherwise it gets dumped to the root with a weight of
>> > 16. This is a very real edge-case that, while known, impacted at least
>> the
>> > h2o and Google HTTP/2 server implementations serving traffic to Chrome.
>> My
>> > initial test for HTTP/2 prioritization triggered the edge case quite
>> > reliably (unintentionally). h2o has since worked around it by
>> "remembering"
>> > some completed streams but I believe the Google edges are still impacted
>> > (and I'm not sure about other implementations).
>>
>> The current prioritization scheme in HTTP/3 (I am referring to the
>> current draft at version 18 [1]) uses placeholders, which solve
>> this exact problem.  The client no longer has to rely on hope.
>>
>> Are there other problems the current prioritization scheme possesses
>> that cannot be boiled down to "programming is hard?"  I agree with
>> Amos Jeffries, who writes:
>>
>> > On Mon, Jan 28, 2019 at 9:19 PM Amos Jeffries <squid3@treenet.co.nz>
>> wrote:
>> > > The rational conclusion then is that better Browser implementations
>> > > would solve these particular annoyances. So what problems exactly are
>> > > preventing that better implementation happening?
>>
>> For this proposal to be accepted at this late stage in the game, it
>> should be demonstrably, non-marginally better than the current
>> mechanism.  It may be better than HTTP/2; but I don't see how it is
>> better than HTTP/3 [1].
>>
>>   - Dmitri.
>>
>> 1. https://tools.ietf.org/html/draft-ietf-quic-http-18
>>
>>