RE: Design Issue: PUSH_PROMISE and Stream Priority

[RUELLAN Herve <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> William Chan (???)
> Sent: vendredi 26 avril 2013 07:29
> To: Roberto Peon
> Cc: Martin Thomson; James Snell; HTTP Working Group
> Subject: Re: Design Issue: PUSH_PROMISE and Stream Priority
> 
> We have not proposed a reprioritization frame since there was some mild
> resistance before at the Tokyo interim meeting, although most of that
> concern was about the larger prioritization proposal and not strictly
> reprioritization. We promised to go get data and come back and report. We
> have not gotten said data yet (it's in progress), so I don't have much to report
> (no data, only status if people are interested. I'm inclined to wait until I have
> data). If reprioritization is not controversial, then we can go ahead and
> propose a frame for that and revisit the rest of the larger prioritization
> proposal when we have data.
> 
> As far as the priority being useless to send with push streams, the only
> reason I can see that as being useful is perhaps saving a reprioritization frame
> (meh) or if you have a "smart" server that's doing some learning process to
> decide how to prioritize push streams in absence of client information, then
> perhaps this would allow for informing the client as you're learning. That's a
> weak argument too because you can just log that information server side to
> evaluate your learning process.
> 
> Actually, if we don't strictly assume HTTP style client initiated
> request/response application protocol semantics, then at the framing layer
> with fully bidirectional streams, the server may be requesting that the client
> send data back to the server according to the server advisory priority. That is,
> since streams are bidirectional, you can imagine servers initiating a
> request/response pair.
> 
> Now, as to the push stream priority default, in general for a web browsing
> case, the "parent" stream will be the root document of a page load, and the
> push streams will be subresources, which should generally be lower priority
> than the root document. So I don't think priority inheritance is advisable for
> this scenario, and at least for the HTTP case, it's not really important since it's
> a server-side implementation detail - in absence of client advisory priorities,
> the server just sends streams in whatever order it wants. No need to spec a
> required default or anything, let server implementations innovate here. A
> reprioritization frame would enable the client to send advisory priorities here
> to better inform the server. And I would recommend we allow clients to do
> so.

My reading of this is that a server could set a priority on a pushed stream as an information for the client: the priority value is the priority selected by the server for the stream. Then, if the client is not happy with this server defined priority it could use a reprioritization frame to change the priority of the stream.

Hervé.