Re: Concerns about HTTP/2 Priority

I am with Mark when he says: "many share your concerns about the overall
shape of priorities;"

We have not had the time or environment to even begin to experiment with
priorities and it scares me that we are at LC and there has been no
widespread testing of the proposed standard.

However, Mark does also indicate the get-out-goal card that will need to be
played:  "Also, it’s important to note that priorities are hints to the
server, not directives; it is expected that servers will use local
knowledge (e.g., “serve JS and CSS before images”) in combination with
priorities, rather than being strict slaves to them."

Specifically, I think that the server's view of priority will often be
entirely different to the clients and what is expressed by the Tree/or
Dag.  The currently priority mechanism is very much focused on how to
allocated network resources to frames from various streams.  A server is
going to be more focused on which streams to allocate CPU/memory resources
to in order to generate frames to send, and once generated those frames
have a higher priority to be sent so that memory can be freed to be used
for other frame generation.    Just because a high priority stream is
blocked does not mean that a server will wish to allocated more resources
to a connection to perhaps progress a low priority stream.   Maximising
fair allocation of CPU/memory/cache resources on the server will probably
trump any attempt to maximise network utilisation on the client end of a
connection.

My current guess is that the server is going to implement it's own
heuristic based priority mechanism that will use very little input from
client supplied priorities, specially not dynamically provided ones.
Hopefully I'm wrong and the current tree/weights will be useful to the
server side, but only experimentation will tell.

The jetty project is near to the point where we can experiment with http2
scheduling, push and priorities.  We intend to spend time on the
December/January time frame to come up with at least a basic
implementation.  It is a pity that we have lost the race with LC to be able
to well contribute the knowledge so learnt.    Hopefully whatever we do
learn will be able to be represented in some way by the current scheme, but
I find it of great concern that Chad has identified use-cases that cannot
be expressed.

cheers



On 6 November 2014 02:35, Roberto Peon <grmocg@gmail.com> wrote:

> SGTM-- moving this from unreliable to reliable behavior seems like a
> definite win for intermediaries, and potentially others.
> -=R
>
> On Tue, Nov 4, 2014 at 4:40 PM, Ilya Grigorik <igrigorik@gmail.com> wrote:
>
>> On Wed, Nov 5, 2014 at 8:42 AM, Mark Nottingham <mnot@mnot.net> wrote:
>>
>>> What do other people think about the general idea?
>>
>>
>> I like it. I think it moves the discussion from "you could bend the
>> protocol to do this assuming you have a cooperating client+server", which
>> is not something we can reasonably rely on as a browser, to a plausible
>> "PRIORITY is allowed on idle stream, treat such streams as 'group
>> anchors'"... i.e. allowing priority on idle stream means servers *must*
>> deal with this case, which makes using and deploying such mechanism much
>> more plausible.
>>
>> ig
>>
>
>


-- 
Greg Wilkins <gregw@intalio.com>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.