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

Maybe I'm missing something but the priority updates don't need to
coordinate across multiple data streams, just between the one stream that
is being reprioritized and the control stream.

Would something like this not work?
- Control stream gets priority update for stream X
- If stream X is known and the request side is complete/closed then update
the priority as requested
- If stream X is either not known or still in the process of receiving
request details, store the priority update for stream X in a fixed
queue/map (size can be small but a safe size would be the max number of
streams supported)
- If there is already a pending priority update for stream X, discard it
and replace it with the current priority update
- If the pending priority update queue is full, drop the oldest and insert
the new update
- When a new request stream closes, check the pending priority update queue
to see if there is an update waiting for the stream. If so, remove it from
the queue and apply the new priority

There should be no DOS concerns since the queue is fixed and small. The
performance overhead would be trivial if we assume that out-of-order
reprioritizations are rare (i.e. the list will almost always be empty).

On Tue, Jun 9, 2020 at 10:48 AM 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.  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.
>
> At a higher level, I don't understand the concern with complexity.
> If you look up "complexity" in the dictionary, you will see
>
>     complexity (n), see QUIC.
>
>   - Dmitri.
>
> 1. Before it was ripped out of the spec, that is, thanks a lot...
>
>