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

On Tue 16 Jun 2020 at 01:06, Kazuho Oku <kazuhooku@gmail.com> wrote:

>
> In such a deployment, I would argue that the H3 reverse proxy should
> respect the priorities when choosing a request from the queue, regardless
> of the prioritization signal being initial or reprioritization. Otherwise,
> the H3 reverse proxy would end up providing responses to requests mostly in
> the order of the requests being issued.
>

That I agree with. But some prioritisation choices are discrete - for
backend requests the request is either queued or sent to back end or
completed by the backend. I wouldn’t try to interrupt that after it’s been
sent to the back end. So you use the best prioritisation signals available
at the time when choosing which request to the backend.

If 8 items come in at medium priority and they all require back end calls,
and we can only have 8 backend resources in flight at same time, then send
them. If a 9th high priority request then comes in while those 8 are being
processed then tough - there are no free slots to the backend for that
request despite it being high priority - those backend slots were filled
with the best prioritisation signals available at the time.

Of course if 10 items need backend resources, with differing priorities,
then use that priorities to decide which 8 of those to send first. But I’m
Just saying this is less likely to happen until all the back end slots are
filled because 10 things do not come in at once - they come in one by one
and I’d argue they should be sent to the back end ASAP and then left to
complete, rather than holding back requests or interrupting requests
already sent to back end. So initially, until all backend slots are filled,
prioritisation is not used here because effectively there is no queue
initially.

Either way, after the back end process is complete for one or more requests
and returned to the web server, we’ve another queue of bytes to return to
the browser and so another opportunity to use prioritisation to select
which stream’s bytes to send back.

Basically what I’m saying is only use prioritisation when there’s a queue
and a choice to be made.

However, as there is more likely to be queuing on the final return step to
the client, we’ll end up using prioritisation more there (which is no bad
thing!).