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

Hey Dmitri,

On Tue, Jun 9, 2020 at 3:44 PM Dmitri Tikhonov <dtikhonov@litespeedtech.com>
wrote:

> On Tue, Jun 09, 2020 at 03:15:44PM +0100, Lucas Pardue wrote:
> > I can hypothesize that an implementation with QPACK dynamic support has
> > already crossed the threshold of complexity that means implementing
> > reprioritization is not burdensome. I'd like to hear from other
> > implementers if they agree or disagree with this.
>
> 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.


>   Speaking for lsquic, reprioritization
> had to [1] touch more code and was much more tightly coupled than
> QPACK; on the other had, QPACK encoder logic was a lot more code.
>

Thanks for sharing your experiences. If we take the scheduling aspects out
of consideration, the old HTTP/3 priority tree (+ placeholders etc) scheme
signals were pretty tough to implement. I suspect that extensible
priorities' reprioritization would be relatively more simple. But it would
be interesting to hear from someone that implemented the old scheme
compared with the new one.

Cheers
Lucas