Re: http/2 prioritization/fairness bug with proxies

Note that these priority labels would be suboptimal for browser usage.
As I understand it, all requests within a page load would fall within
a single priority level, probably priority 1 in your case. In my
presentation, I demonstrated how browsers want to do resource request
prioritization within the HTTP protocol level. Different resources
have very different prioritization requirements within a page load,
and unless the protocol supports client advisory priorities, the
browser must make a link underutilization vs contention tradeoff.
Specifically, the browser will withhold making HTTP requests for low
priority resources under higher priority HTTP requests complete, so as
to avoid contention. This achieves some amount of prioritization at
the risk of underutilizing the link.

As I understand it, your proposal also requires trustworthy clients to
set the appropriate priority level, unless the proxy has some
mechanism for determining the appropriate priority level by inspecting
the stream, at which point the client requested priority is useless.
I'm not sure that trusting clients to set the appropriate priority
level for shared sessions is advisable. Opaque levels where only
relative priority matters within a "group" is resilient to this
problem.

On Mon, Feb 4, 2013 at 8:46 AM, Nico Williams <nico@cryptonector.com> wrote:
>
> On Feb 4, 2013 8:05 AM, "Amos Jeffries" <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?

Received on Monday, 4 February 2013 17:50:22 UTC