Re: Priority implementation complexity (was: Re: Extensible Priorities and Reprioritization)

On Jun 9, 2020, at 12:41 PM, Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
> On Tue, Jun 09, 2020 at 08:22:10PM +0100, Lucas Pardue wrote:
>> On Tue, Jun 9, 2020 at 3:44 PM Dmitri Tikhonov <dtikhonov@litespeedtech.com>
>> wrote:
>>> 
>>> I don't think we can judge either way.  If Alice implements QPACK and
>>> Bob implement reprioritization, results will vary based on their level
>>> of competence.  The degree of burden will also vary for each
>>> particular implementation.
>> 
>> I agree that, all things considered, QPACK and prioritization are
>> dissimilar. However, this thread is specifically exploring the mechanics of
>> the reprioritization mechanism, which requires a signal received on one
>> stream (the control stream) to affect the send behaviour on another. There
>> is always a possibility of a race here. My conjecture is that the
>> priorities race ends up being is similar to QPACK'S (i.e. handling blocked
>> streams). And therefore if Alice implements QPACK dynamic support
>> competently, then implementing reprioritization is no more difficult.
> 
> My point was that Alice may have no problem implementing repriotization,
> but Bob very well might!  That is to say, there may be more than one
> person working on an HTTP/3 stack.  After Bob gives up after three
> months leaving reprioritization a steaming pile of crap, Alice (who's
> grown to hate that fool) inherits Bob's code, but may not be able to
> make a good implementation given tight deadlines.  Alice gets blamed;
> Bob gets promoted.  The story gets sadder and sadder in my mind, so
> I better stop.

Umm, yeah.

May I suggest that we include all of the signals necessary to reprioritize and
leave it up to the recipients whether or not to implement them? That's what
we have to deal with anyway given the latency issues.

....Roy

Received on Tuesday, 9 June 2020 22:41:43 UTC