Re: Design Issue: Separate HEADERS and PRIORITY Frames, Eliminate HEADERS+PRIORITY

The color of my shed:

I would like to see us remove HEADERS+PRIORITY entirely and add a separate
PRIORITY frame.

I don't agree that separating them will simply cause an additional 4 bytes
to be sent on every request. While it might be true that most browsers will
set the priority of a request, I don't think that all clients necessarily
will (I have a mobile client that uses HTTP for API requests and have not
found the priority mechanism necessary -- at least not yet).

I could imagine that it would be acceptable to send the PRIORITY frame
before the HEADERS frame and still mandate that HEADERS frames (and now
only HEADERS frames) initiate streams. While this does cause some extra
state allocation, we already have to do something similar with PUSH_PROMISE
where we must track that the "stream identifier MUST be a valid choice for
the next stream sent" and then initiate the stream later.

This would also give us a mechanism to send priority changes for
outstanding requests at the framing layer, and could allow priorities to be
set for pushed responses should it prove useful.

- Jeff


On Tue, May 21, 2013 at 2:55 PM, James M Snell <jasnell@gmail.com> wrote:

> On Tue, May 21, 2013 at 2:43 PM, Roberto Peon <grmocg@gmail.com> wrote:
> > Sending the PRIORITY frame *MUST* cause state allocation at the receiver,
> > else it was useless to send before the HEADERS frame. As you point out,
> at
> > minimum it must allocate a stream ID and priority field, and for most
> > implementations it will also need to include so mechanism of pointing out
> > that the headers don't exist, so, probably between 16 to 24 bytes worth
> of
> > allocation on a 64 bit machine.
> >
>
> Sorry, I wasn't clear in my initial response. Yes, there is some state
> that would need to be allocated but not the same as that when the
> initial HEADERS frame is received, for instance.
>
> > If the PRIORITY frame was renamed to CHANGE_PRIORITY, would that clarify
> > anything? Priority changing is the current intent of that frame type.
> >
>
> Not particularly, because we'd still have the question of when to use
> HEADERS+PRIORITY vs. the combination of HEADERS and a CHANGE_PRIORITY.
> Can HEADERS+PRIORITY be used any time? For instance, could I send an
> initial HEADERS frame on a stream then later send a HEADERS+PRIORITY
> on the same stream? I honestly don't care how it ultimately ends up so
> long as (a) It's the simplest thing that could possibly work and (b)
> Is easy to explain in the spec and easy for a developer to implement.
>
> > btw, I am not particularly partial to the "any frame opening up a stream"
> > thing. I'm not completely against it though :)
> > My reason for slightly preferring that streams must begin with HEADERS or
> > HEADERS+PRIORITY is that it is an explicit statement of intent, and thus
> > off-by-one, uninitialized var, etc. errors are more likely to be
> detectable
> > in a world where such is required.
> >
>
> I would very much like to see us mandate that streams always initiate
> with a HEADERS / HEADERS+PRIORITY frame.
>
> - James
>
> >
> >
> > -=R
> >
> >
> > On Tue, May 21, 2013 at 2:19 PM, James M Snell <jasnell@gmail.com>
> wrote:
> >>
> >> On Tue, May 21, 2013 at 10:30 AM, William Chan (陈智昌)
> >> <willchan@chromium.org> wrote:
> >> > Thanks for describing these cases now. I had not thought of them.
> >> >
> >> > If everyone's sold on reprioritization, then let's go ahead and do
> this
> >> > and
> >> > have the debate about ditching HEADERS+PRIORITY or not. I want to keep
> >> > it. I
> >> > don't like the idea of sending a PRIORITY frame first. Is sending a
> >> > PRIORITY
> >> > frame going to trigger stream state allocation at the receiver? What's
> >> > the
> >> > expectation? And if you don't have a priority for the HEADERS, then
> you
> >> > have
> >> > the race that Roberto described.
> >> >
> >>
> >> There is no reason to assume that sending a PRIORITY frame first would
> >> trigger stream state allocation at the receiver. At most, it would
> >> reserve the stream ID and store the priority value. The full state
> >> allocation would not occur until the HEADERS frame is received. That
> >> said, I'm not 100% dead set on removing HEADERS+PRIORITY, I would just
> >> like to simplify the protocol where it makes sense to, and even then
> >> only after it's been proven out in implementation. Having separate
> >> HEADERS, HEADERS+PRIORITY and PRIORITY frames is confusing, if we can
> >> do without separating them, we ought to do so.
> >>
> >> - James
> >>
> >> >
> >> > On Tue, May 21, 2013 at 2:09 PM, Patrick McManus <
> pmcmanus@mozilla.com>
> >> > wrote:
> >> >>
> >> >>
> >> >> On Tue, May 21, 2013 at 12:32 PM, William Chan (陈智昌)
> >> >> <willchan@chromium.org> wrote:
> >> >>>
> >> >>>
> >> >>> I support adding a new additional PRIORITY frame for stream
> >> >>> reprioritization.
> >> >>
> >> >>
> >> >> me too. Specifically I support this as a mechanism for the client to
> be
> >> >> able to explicitly prioritize an open pushed stream. I can wait for
> >> >> more
> >> >> evidence about re-prioritizing, but in cases where the client hasn't
> >> >> ever
> >> >> explicitly set the stream's priority I think we have evidence that
> its
> >> >> time
> >> >> to do something.
> >> >>>
> >> >>>
> >> >>> Unless there's a reason this needs to be in the current http/2 draft
> >> >>> sooner rather than later, I'd rather punt on this discussion until
> we
> >> >>> have
> >> >>> implementation experience that can guide this debate.
> >> >>
> >> >>
> >> >> I think there is experience here specifically related to push.
> >> >>
> >> >> e.g. You can easily configure mod_spdy to push images when html is
> >> >> pulled.
> >> >> but you can't effectively dictate the relative priorities of those
> two
> >> >> things.
> >> >>
> >> >> Sure, you can define an explicit priority for those images but
> priority
> >> >> implementations are all about relative levels and the client set the
> >> >> priority of the html.
> >> >>
> >> >> You can argue that mod_spdy should have defined relative priorities
> >> >> (+/-
> >> >> the associated stream) instead of constants.. that would be better
> but
> >> >> the
> >> >> client still has no way to make sure those streams are at a higher
> >> >> priority
> >> >> than a "save as" background stream (I've seen this one happen as
> >> >> mod_spdy
> >> >> defaults to lowest priority when pushing), or a lower priority than a
> >> >> real-time video stream..
> >> >>
> >> >> plus there is no scale for the server to work with.. it might set a
> +2
> >> >> priority for pushed images but the client might be using +3 for
> pulled
> >> >> images causing a mismatch in something that was intended to be
> equally
> >> >> weighted.
> >> >>
> >> >> at least with a priority frame the client can make those adjustments
> in
> >> >> a
> >> >> RTT.
> >> >>
> >> >> Cheefully,
> >> >> -Patrick
> >> >>
> >> >>
> >> >
> >> >
> >>
> >
>
>