Re: Design Issue: PUSH_PROMISE and Stream Priority

My apologies,  i accidentally excluded the list in this reply.
On Apr 26, 2013 12:11 AM, "James M Snell" <jasnell@gmail.com> wrote:

>
> On Apr 25, 2013 10:29 PM, "William Chan (陈智昌)" <willchan@chromium.org>
> wrote:
> >
> > 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.
> >
>
> Waiting for the data is fine. I'm not opposed to a prioritization frame
> but I worry about creating too many special purpose frame types at too fine
> gained a level. We'll need to be careful.
>
> > 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.
> >
>
> This hits the core of the problem.. Are we creating a general purpose
> bidirectional framing protocol that we can layer http onto or are we
> creating a new http based on frames.  If the former, then push stream
> priority may make sense.  If the latter, it could be dangerous and
> completely unnecessary.
>
> For now, let's just say that only client initiated streams have a
> priority. Doing so eliminates many potentially messy issues.  If someone
> wants to experiment with prioritized push streams later on down the road ,
> they can do so.
>
> - James
>
> > 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.
> >>> >
> >>>
> >
>