Re: http/2 prioritization/fairness bug with proxies

On Feb 4, 2013 8:05 AM, "Amos Jeffries" <squid3
<squid3@treenet.co.nz>@<squid3@treenet.co.nz>
treenet.co.nz <squid3@treenet.co.nz>> wrote:
> On 4/02/2013 11:01 p.m., Mark Nottingham wrote:
> > [...]
> Which goes to show why specifying an algorithm for handling opaque
client-selected prioritization is the wrong way to go about this.
>
> You have presented a good argument for specifying a set of standardized
priority labels with criterion for setting each label.
> eg.
>  Priority 1 - user actioned fetch - requires fast answer
>  Priority 2 - background/automated fetch in user-visible window -
requires fast answer but treat as bulk traffic.
>  Priority 3 - automated software fetch - treat as low-speed traffic.
>  Priority 4 - idle software probe - may drop if necessary.
>
> ... then letting the algorithm designers and implementers free to write
their prioritization algorithms around those definitions.

+1, plus priorities for real-time requests?