Subject: Priority inside PUSH_PROMISE frames

From: RUELLAN Herve <[email-masked]>
Date: Thu, 12 Jun 2014 19:29:15 +0000

All,

Currently, when a stream is created by a PUSH_PROMISE, it has a default
priority. It depends on its associated stream and its weight is 16.  In many
case, this default priority has no impact from the client point of view and
doesn't need to be changed.

Recent work on DASH has shown interest in using HTTP/2 push for transmitting
several video segments upon receiving one client request. These video segments
are consecutive parts of the video and should be received sequentially by the
client to allow for a streaming playback of the video. A smart server will
push these video segments sequentially, notwithstanding the default
priorities.
However, the client has no way to know whether the server it is connecting
to is smart or not. To share this knowledge, the PUSH_PROMISE frame should be modified
to optionally include priority information (as is already the case for the
HEADER frame).  The client could rely on this priority information to discover
the server behaviour, and to decide whether or not sending PRIORITY frames to
correct it.

Other scenarios could take advantage of including priority information inside
PUSH_PROMISE frames. For example, a group of images can be pushed in parallel
(the default behaviour), which is useful for starting quickly a progressive
rendering of all the images belonging to a web page. This group of images can
also be pushed sequentially (with non-default priorities), which is useful to
show quickly the first images in a long list of images. In this latter case,
the PUSH_PROMISE frames would contain priority information, indicating to the
client the intended behaviour of the server.

Hervé

---

From: Jeff Pinner <[email-masked]>
Date: Thu, 12 Jun 2014 12:40:21 -0700

This isn't necessary.

The HEADERS frame has an optional priority field to avoid a race condition.
PRIORITY frames cannot be sent on the stream that HEADERS is being sent on
because the HEADERS frame creates the stream. If the request contains no
body, the server may process and send the response before receiving any
subsequent PRIORITY frames on that stream.

For PUSH_PROMISE frames, the stream is opened with the PUSH_PROMISE and
processing cannot complete until a HEADERS frame containing the response
metadata is received. Servers that wish to set a non-default priority can
do so by sending a PRIORITY frame between the PUSH_PROMISE and the HEADERS.
There is no race condition.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 12 Jun 2014 21:19:04 +0000

Emitting a PRIORITY frame from the server doesn’t make sense to begin with – it’s telling the client how to prioritize resources, by the definition of priority, but the client is going to make whatever resource allocation makes sense for its scenario.  I would expect most clients to completely ignore PRIORITY frames.

You’re right than an intelligent server probably has a layer of knowledge beyond what the protocol defines in situations like that; that’s part of why HTTP/2 priorities are strictly advisory – so the server has the freedom to apply additional intelligence.

From: Jeff Pinner [mailto:[email-masked]]
Sent: Thursday, June 12, 2014 12:40 PM
To: RUELLAN Herve
Cc: HTTP Working Group ‎[[email-masked]]‎
Subject: Re: Priority inside PUSH_PROMISE frames

This isn't necessary.

The HEADERS frame has an optional priority field to avoid a race condition. PRIORITY frames cannot be sent on the stream that HEADERS is being sent on because the HEADERS frame creates the stream. If the request contains no body, the server may process and send the response before receiving any subsequent PRIORITY frames on that stream.

For PUSH_PROMISE frames, the stream is opened with the PUSH_PROMISE and processing cannot complete until a HEADERS frame containing the response metadata is received. Servers that wish to set a non-default priority can do so by sending a PRIORITY frame between the PUSH_PROMISE and the HEADERS. There is no race condition.

On Thu, Jun 12, 2014 at 12:29 PM, RUELLAN Herve <[email-masked]<mailto:[email-masked]>> wrote:
All,

Hervé

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Fri, 13 Jun 2014 08:30:00 +0900

If server wants to push resouces in whatever sequence, it just do so and
telling priority to client is not necessary. The priority scheme is
optional and no guarantee to sequential processing. It means that client
cannot know server capability from that.

Best regatds,
Tatsuhiro Tsujikawa

---

From: Roberto Peon <[email-masked]>
Date: Thu, 12 Jun 2014 17:07:54 -0700

The idea was that the client need not re-prioritize if the server sets a
priority that it does like, and does re-prioritize if the server sets a
priority that it doesn't like.

How otherwise would the client know how the server was prioritizing it?

-=R

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jun 2014 17:14:09 -0700

> How otherwise would the client know how the server was prioritizing it?

The point being - I think - that if the client cares, it should reprioritize.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 12 Jun 2014 17:22:24 -0700

A bit more chatty, but sure.

Incidentally, Herve's use-case for DASH is interesting to me as well.
-=R

---

From: David Krauss <[email-masked]>
Date: Fri, 13 Jun 2014 10:00:24 +0800

> The point being - I think - that if the client cares, it should reprioritize.

I suggested this some time ago, as a generalized part of a specific proposal about zero priority weight.

Prioritization by the server should be either assigned some semantics, however hazy, or disallowed. Even if implementations fail to live up to the ideal due to simplicity or bugs, everyone will at least be reaching for the same goal.

I think it makes the most sense that every stream should have the same priority on both ends.

To reiterate my proposal, allowing PRIORITY zero, given a reprioritization policy and a rule against zombie streams, provides a way to ask whether a stream is desired by the other end without resorting to flow control hacks.

POST with Weight=0 implements EXPECT, a server response with Weight≠0 implements CONTINUE. PUSH with Weight=0 gives a client the opportunity to refuse a resource.

The flow control scheme requires adjusting a global setting.
It breaks separation of concerns.
It adds complexity to critical global state. BLOCKED was added just for this debugging.

The two mechanisms can even coexist. It’s true, POST/Weight=0, like EXPECT requires the client to opt-in, but given that, the result is still superior: the initial window-full of upload is avoided. POST/Weight=0 doesn’t carry CONTINUE’s baggage because it’s part of a strictly optional system, not a full-fledged response: proxies can preemptively return a CONTINUE-equivalent without actually breaking the proposed semantics.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Jun 2014 09:57:41 -0700

On 12 June 2014 19:00, David Krauss <[email-masked]> wrote:
> To reiterate my proposal, allowing PRIORITY zero

I think that you are describing something that is different to what
Herve proposed.  It's also more complex to implement correctly than
even that trivial change, and that was not found to have sufficient
interest.  Given the amount of grief we're getting over priority; I'm
wary of these sorts of proposals.

---

From: David Krauss <[email-masked]>
Date: Sat, 14 Jun 2014 09:16:02 +0800

On 2014–06–14, at 12:57 AM, Martin Thomson <[email-masked]> wrote:

> Herve proposed.  

Herve proposed that PUSH_PROMISE priority should be applied to the client-side state.

It’s a small extrapolation to say that if the server ever sends priority info, the client interprets it in the same way, and perhaps requests a priority change in response. I.e., there should always be identical prioritization on both sides.

Otherwise, where server-sent priority has no defined meaning, it should be illegal. This is not fertile ground for application-defined protocols. If a server-side application really wants to manipulate priority (which may decide how clients or client-side proxies allocate bandwidth), it should arrange for the client to adjust it.

The weight-zero business is less important, but…

> It's also more complex to implement correctly than

Prioritization is all optional. My proposal is designed to avoid adding complexity to minimal implementations. I wouldn’t be proposing this except to solve problems, including that flow control is also difficult to implement, especially as flow control throttling may lead to priority inversion (BLOCKED et al). Simplicity is absolutely the motivation.