Re: http/2 prioritization/fairness bug with proxies

Prioritization is, admittedly, no where near my strongest area so if this
is a silly notion please do not hesitate to point it out... Just throwing
this in off the top of my head, but, could we not allow for priority quotas
per session? Allow an intermediary to open a limited number of concurrent
connections with the server, each with a specific set of priority quotas.
If an intermediary is remuxing requests, it would pass those through
without modifying the priorities, but could choose which connection to send
it along on based on the available quota. Certain connections would be
weighted to give the highest quota to high priority streams, others
weighted for lower priority.
On Feb 4, 2013 8:50 AM, "Nico Williams" <nico@cryptonector.com> wrote:

>
> 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?
>