Subject: Priority straw man

From: Martin Thomson <[email-masked]>
Date: Sun, 26 Jan 2014 13:34:04 -0800

As requested, a writeup on prioritization.

As a pull request: https://github.com/http2/http2-spec/pull/364

In HTML form:
http://martinthomson.github.io/drafts/priority.html#StreamPriority
http://martinthomson.github.io/drafts/priority.html#PRIORITY

Comments or pull requests happily accepted.

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 27 Jan 2014 10:38:25 -0800

Comments from github:

It would be cleaner if priority groups had the same cardinality as stream
identifiers. That would remove the edge case of more open streams than
groups.

If you increase the groups to 31 bits, then you could use the reserve bit
in the stream id in the priority frame payload to indicate that this stream
becomes its own group with identifier defaulted to its stream id with a
given weight, rather than being dependent upon another stream.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Jan 2014 10:43:12 -0800

> identifiers. That would remove the edge case of more open streams than

I assume here that you are talking about the case where you want to
maintain greater than 2^24 open groups.

I'm really not sympathetic to that scenario to be honest.  That's 16+
million concurrent partitions.  Of course, I'd be impressed if you
could prove that you were able to manage 16+ million-way-concurrency
with anything better than random results.

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 27 Jan 2014 10:59:37 -0800

> with anything better than random results.

assume independent clients so each connection becomes its own stream in its
own group

16+ million-way-concurrency -- beyond our capability currently, maybe
google can?
1+ million-way-concurrency -- possible on today's hardware

so we're within an order of magnitude or so of the limit for
application-specific software

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Jan 2014 11:34:21 -0800

> assume independent clients so each connection becomes its own stream in its

That's a reasonable thing to do.  The key questions are:
 - do you want fate sharing to that degree?
 - is there a meaningful distinction, priority-wise, that can be made
at this point?
 - would the cost of a collision (two clients hitting the same
priority group) be noticeable?

I'll also note that at 16m groups, each client gets, on average, 128
requests before you need to make a new connection.  That's not very
many.  I'd have thought that you would be better off asking for more
stream identifiers (I'll note that we could use that reserved bit with
this scheme, but that only doubles the space).

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 27 Jan 2014 11:40:39 -0800

On Mon, Jan 27, 2014 at 11:34 AM, Martin Thomson
<[email-masked]>wrote:

> i capitulate that the cost of collision would probably not be noticeable
nor would any distinction in priorities be necessarily meaningful

> this scheme, but that only doubles the space).

for web browsing, sure, but for streaming services a single request per
client is enough

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 29 Jan 2014 22:51:05 +0900

http://martinthomson.github.io/drafts/priority.html#rfc.section.6.3

says:

"""
The PRIORITY frame is associated with an existing stream. If a PRIORITY
frame is received with a stream identifier of 0x0, the recipient MUST
respond with a connection error (Section
5.4.1<http://martinthomson.github.io/drafts/priority.html#ConnectionErrorHandler>)
of type PROTOCOL_ERROR<http://martinthomson.github.io/drafts/priority.html#PROTOCOL_ERROR>
.
"""

This means that if the endpoint just want to change the weight of the
priority group, it has to
issue PRIORITY frame wit the active stream ID and fill the current correct
dependency in the payload.
The stream ID and stream dependency are completely redundant in this case.

So I propose that PRIORITY can be sent to stream ID = 0. In this case,
stream dependency
field must be 0 and the receiver of this frame changes the weight of the
specified priority group and does not change the relative ordering inside
it.
Using stream ID = 0 makes sense in a mean that priority groups belong to
the connection
rather than the stream.

The valid use case is that if browser assigns priority group for each tab,
and user change the tab, then browser send PRIORITY frames with stream ID =
0 to just change the weight of their priority groups.

Sorry if this has been discussed already.

Best regards,
Tatsuhiro Tsujikawa

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Jan 2014 09:25:33 -0800

> specified priority group and does not change the relative ordering inside

Interesting proposal.  It is more code to handle another scenario,
maybe; but definitely less work required to reprioritize.

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Fri, 31 Jan 2014 01:03:21 +0900

> maybe; but definitely less work required to reprioritize.

The additional implementation cost is negligible compared to the whole
priority stuff, isn't it?
Also we did similar thing in WINDOW_UPDATE frame; checking stream ID for 0
and non-0 case.
My proposal is also not affected by the pathological case where the stream
in the header disappear due to the asynchronous nature of the protocol, if
endpoint just wants to change the weight of the group.

Best regards,
Tatsuhiro Tsujikawa