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.




On Thu, Apr 25, 2013 at 7:36 PM, Roberto Peon <grmocg@gmail.com> wrote:

> I am traveling but should be back by Monday. I'll be slow before then as
> I'm having to type in the phone.
> On Apr 25, 2013 6:50 PM, "Martin Thomson" <martin.thomson@gmail.com>
> wrote:
>
>> Good point.  The hope was that a reprioritization frame would be
>> proposed (Will, Roberto, we're all still waiting).
>>
>> If that's enough, then adding a default (maybe 2^30) would fix this.
>>
>> On 25 April 2013 11:03, James M Snell <jasnell@gmail.com> wrote:
>> > https://github.com/http2/http2-spec/issues/75
>> >
>> > The current draft (-02) says, "The endpoint establishing a new stream
>> > can assign a priority for the stream."
>> >
>> > However, the spec does not define how a stream established using
>> > PUSH_PROMISE can assign the priority for a stream, nor does the spec
>> > discuss whether the notion of stream priority applies to push streams.
>> >
>> > The spec currently states that PUSH_PROMISE is followed later on by a
>> > HEADERS frame.
>> >
>> > If priority applies to push streams, then we need to add that priority
>> > can be assigned by allowing the use of a HEADERS+PRIORITY frame.
>> > Otherwise, we need to clarify the spec text to say that push streams
>> > have no priority.
>> >
>>
>>