Subject: HTTP/2 Priorities Proposal

From: Jeff Pinner <[email-masked]>
Date: Tue, 8 Apr 2014 16:23:14 -0700

I believe it would be simpler (both conceptually and in practice) to
slightly modify the priority structure.

Currently we have group-ids with weights and (possibly-exclusive) stream
dependencies. The default is for the a stream to create a new group with an
id equal to its stream identifier and some default priority.

Conceptually this is the same as saying that the priority is a
non-exclusive stream dependency of 0, but this dependency is special in
that it is weighted.

When depending on an existing stream, the stream has an implicit weight of
1 / total # of dependent streams (rounded appropriately to integers).

This conceptually creates a "weighted groups of dependency trees" but it
seems that this can equivalently be thought of as a single "weighted tree"
with implicit or explicit weights.

I am suggesting that it would be easier both conceptually and in
implementation to replace the idea of groups entirely with weighted
dependencies. Implementations already have to handle weights at some point
to deal with groups. Thus determining priority is the traversal of a single
weighted tree.

The on-the-wire implementation then only requires a single flag for
signaling priority information, with the frame layout always containing a
weight and a stream dependency (possibly 0) with an "exclusive" bit.

The defaulted priority information is then a dependency of 0 with the
default weight (16). This is identical to a new group with the group-id ==
stream-id.

I believe this proposal has the benefit in that the wire format is
simplified, the overall complexity of the implementation is reduced, and
all priority information is proxy-able. The drawback is that in the
existing implementation, you can add a stream to a named group and share
it's weight is automatically divided equally amongst the roots of the trees
in the group. In this implementation, doing so would require sending
priority frames to re-weight the root streams.

Thoughts?

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 9 Apr 2014 09:50:00 +0900

>
> When depending on an existing stream, the stream has an implicit weight
of 1 / total # of dependent streams (rounded appropriately to integers).
> Thoughts?

The one dependency tree is easily collapsed to multiple trees in usual
situation. For example, if 5 streams depend on stream A, and A is closed,
those 5 streams become root for each subtree. And changing weight of them
requires 5 priority frames. If the benefit of this proposal outweighs this
cost, it is worth considering. I don't know proxy case outweighs this
though. If changing weight for a group is happening frequently and it is
the base idea of dependency based priority, then I think the keeping -11 is
way to go.

As for framing, the complexity of current format is very small compared to
the rest of priority handling.

Best regards,
Tatsuhiro Tsujikawa

---

From: Roberto Peon <[email-masked]>
Date: Tue, 8 Apr 2014 17:57:16 -0700

I like it that this solves the proxy problem in its entirety.
Since I do proxy nearly everything, as do many large sites and CDNs, this
seems like a good thing.

-=R

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 8 Apr 2014 18:20:40 -0700

> requires 5 priority frames.
>
One way to consider this: stream A, as the root of the its dependency tree,
had a weighted edge from stream 0 (this is equivalent to saying it was in a
group with some weight). When A closes, it's 5 dependents each now become
roots of their own subtrees, so each has a edge from stream 0. The question
posed is on stream closure, what should those weights be? If the weight of
the edge to A is distributed to the dependents in proportion to their
weights on A, no changing of weights is required and we maintain
equivalence with the draft-11 proposal.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Apr 2014 20:49:06 -0700

On 8 April 2014 18:20, Jeff Pinner <[email-masked]> wrote:
> If the weight of the edge to A is distributed to the dependents in
> proportion to their weights on A, no changing of weights is required and we
> maintain equivalence with the draft-11 proposal.

That's what I would do when A is removed.  Though I'd note that A
should not be removed until it is either necessary, or the server is
willing to bet that it won't be referred to again.

A fully conservative approach toward retention would have nodes remain
until all sub-nodes are closed plus an extra round trip.

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 9 Apr 2014 21:24:20 +0900

On Wed, Apr 9, 2014 at 10:20 AM, Jeff Pinner <[email-masked]> wrote:

> One way to consider this: stream A, as the root of the its dependency
> tree, had a weighted edge from stream 0 (this is equivalent to saying it
> was in a group with some weight). When A closes, it's 5 dependents each now
> become roots of their own subtrees, so each has a edge from stream 0. The
> question posed is on stream closure, what should those weights be? If the
> weight of the edge to A is distributed to the dependents in proportion to
> their weights on A, no changing of weights is required and we maintain

My concern is chaining weight of streams in general, which happens *after*
direct descendants of A becomes root (linked from stream 0) and A's weight
was distributed.

In -11, after closure of A, all descendants are still in the same group, we
can take one of the root and specify weight. It is done with 1 PRIORITY.
 In the proposed plan, descendants are now root of its own subtree,
disconnected each other. To change all weights, we have to issue PRIORITY
frames for each root.

The well known example of this usecase is tab browsing.  People change tab.
Browser wants to change weights of streams, grouped by a tab.

Best regards,
Tatsuhiro Tsujikawa

---

From: Jeff Pinner <[email-masked]>
Date: Wed, 9 Apr 2014 08:05:04 -0700

>
> To change all weights, we have to issue PRIORITY frames for each root.
>
>
Yes, changing the weight of a stream would require issuing a PRIORITY frame
for each stream. With this proposal you cannot do it by changing the weight
of the group.

I believe that this is an acceptable tradeoff.

Let me give a similar example where we reached the same conclusion:

At one point we considered whether or not RST_STREAM should have an
ASSOCIATED flag. The argument was that the server could send PUSH_PROMISE
frames for some stream that the client did not want to receive pushes for.
With the flag, the client could reset all of those streams with a single
frame. We decided it was perfectly acceptable to send one frame for each
stream and dropped the flag.

With this change, to change the weight of multiple streams, you must issue
one frame per stream, but IMHO this is worth it given the reduced
complexity of the change, and more importantly, the ability that this
change introduces of being able to completely proxy the priority
information.

---

From: Jeff Pinner <[email-masked]>
Date: Wed, 9 Apr 2014 10:46:33 -0700

Are there any objections to me opening a pull requests with these changes
as a more concrete proposal?

On Wed, Apr 9, 2014 at 8:05 AM, Jeff Pinner <[email-masked]> wrote:

> Yes, changing the weight of a stream would require issuing a PRIORITY
> frame for each stream. With this proposal you cannot do it by changing the
> weight of the group.
>

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Thu, 10 Apr 2014 12:21:33 +0900

>
> With this change, to change the weight of multiple streams, you must
issue one frame per stream, but IMHO this is worth it given the reduced
complexity of the change, and more importantly, the ability that this
change introduces of being able to completely proxy the priority
information.

Proxy friendliness is a strong point for this proposal. I am not sure it
really reduces the overall complexity without concrete specification since
detail matters a lot in this case. I have no strong objection here.

Does this block next implementation draft?

Best regards,
Tatsuhiro Tsujikawa

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 10 Apr 2014 16:33:04 +1200

On 10/04/2014 3:21 p.m., Tatsuhiro Tsujikawa wrote:
> 2014/04/10 0:05 "Jeff Pinner":
>>>
> Proxy friendliness is a strong point for this proposal.

Indeed. Squid would very likely not have implemented PRIORITY beyond the
forced behaviour of dropping it on the floor. Simply being able to relay
values and let the endpoints sort the stream management out makes it a
lot more useful to everybody as a protocol feature.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 10 Apr 2014 14:41:42 +1000

> Does this block next implementation draft?

It sounds like there's enough interest to delay for a day or two, while Jeff prepares a pull request. 

I know that we're very schedule-focused right now, but given that interop isn't scheduled until early June, I think we can spend a day or two here.

Make sense?

--
Mark Nottingham   http://www.mnot.net/

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Thu, 10 Apr 2014 21:15:54 +0900

On Thu, Apr 10, 2014 at 1:41 PM, Mark Nottingham <[email-masked]> wrote:

> I know that we're very schedule-focused right now, but given that interop
> isn't scheduled until early June, I think we can spend a day or two here.
>
> Make sense?
>
>
Yes.  I'd like to see the pull request.

Best regards,
Tatsuhiro Tsujikawa

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 10 Apr 2014 12:25:31 +0000

Absolutely.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 10 Apr 2014 21:23:22 +0000

We have no objection to you creating a pull request -- we'd like to review the specifics before we weigh in on the proposal itself.

Sent from Windows Mail

From: Jeff Pinner<mailto:[email-masked]>
Sent: ?Wednesday?, ?April? ?9?, ?2014 ?10?:?50? ?AM
To: Tatsuhiro Tsujikawa<mailto:[email-masked]>
Cc: httpbis mailing list<mailto:[email-masked]>

Are there any objections to me opening a pull requests with these changes as a more concrete proposal?

On Wed, Apr 9, 2014 at 8:05 AM, Jeff Pinner <[email-masked]<mailto:[email-masked]>> wrote:
To change all weights, we have to issue PRIORITY frames for each root.

Yes, changing the weight of a stream would require issuing a PRIORITY frame for each stream. With this proposal you cannot do it by changing the weight of the group.

At one point we considered whether or not RST_STREAM should have an ASSOCIATED flag. The argument was that the server could send PUSH_PROMISE frames for some stream that the client did not want to receive pushes for. With the flag, the client could reset all of those streams with a single frame. We decided it was perfectly acceptable to send one frame for each stream and dropped the flag.

With this change, to change the weight of multiple streams, you must issue one frame per stream, but IMHO this is worth it given the reduced complexity of the change, and more importantly, the ability that this change introduces of being able to completely proxy the priority information.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Apr 2014 08:47:35 +1000

For those who haven't seen it:
  https://github.com/http2/http2-spec/pull/453

Cheers,

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 15 Apr 2014 09:56:08 -0700

A question was raised on the pull request of whether or not we should allow
exclusive root dependencies, i.e. whether or not to allow inserting a
stream between the connection and all of its children.

Client authors, do you thing this is an important use case to support with
no additional frame overhead?

(I will note that this can still be achieved with a non-exclusive
dependency followed by re-prioritizing all children onto the new stream.)

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 15 Apr 2014 10:49:34 -0700

I have no current plans to leverage something like this, but I could
conceive of needing this. My two cents is that if it's any non-trivial
complexity, don't support it, since it can already be done by other means.
But if it's trivial complexity, then sure, maybe we'll use it. And by
complexity, I don't mean just implementation complexity, but also spec
complexity. Cheers.

On Tue, Apr 15, 2014 at 9:56 AM, Jeff Pinner <[email-masked]> wrote:

> A question was raised on the pull request of whether or not we should
> allow exclusive root dependencies, i.e. whether or not to allow inserting a

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Apr 2014 10:54:52 -0700

On 15 April 2014 10:49, William Chan (陈智昌) <[email-masked]> wrote:
> complexity. .

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Apr 2014 10:56:43 -0700

>> complexity, I don't mean just implementation complexity, but also spec

Arguably, the special case adds complexity to implementations and
spec.  But it's pretty minor.  The only reason we might want to
prohibit this is if it could be (for example) used to create DoS or it
could trigger bugs, etc...

It's hard to imagine either of those.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 15 Apr 2014 11:18:08 -0700

+1 to what Martin says.
Also, remember that proxies are clients too, and must manage far more
streams.
-=R

---

From: David Krauss <[email-masked]>
Date: Wed, 16 Apr 2014 16:47:59 +0800

I like the priority tree proposal. Hierarchy is already useful to prioritize connections against each other, so it’s natural to extend the concept into streams.

I’m concerned about the method of priority redistribution, though. When a stream closes, its priority is distributed proportionally among its dependents, so they will have each only a fraction of the original priority. The child nodes are moved up the hierarchy to take the place of their former parent. This eliminates the distinction between one of many resources which load after the foreground (high-priority) page HTML completes, and one of only a few resources which load after a background (low-priority) page HTML completes.

The collection of images on a page will initially load with speed proportional to the original page priority, but the last image to complete (which may be much larger than the others) does not inherit the total original priority but only its own fraction. With groups, on the other hand, stragglers get the full specified priority to themselves. A group better represents the task of loading a multi-resource page.

On the other hand, the browser may reprioritize any resource that takes significant time to load. After all, there’s usually no point in parallel requests that aren’t served in time on the order of a round trip. However, my point is that a browser which doesn’t do so will be broken. It’s one more failure point.

Specifying node erasure from the dependency tree may be unnecessary. The effect of closing a stream clearly should be the same as if it were blocked, which is effectively what the specification says anyway if it never mentions closure. Implementations may prune or collapse the tree to reclaim memory, but it’s only a minor detail. Both endpoints already know a closed stream is finished and won’t unblock again. A permanently blocked stream has no effect whatsoever on the hierarchy.

Also, consider an image mentioned in the penultimate frame of the HTML stream. The browser requests it with a dependency which is stale by the time it reaches the origin, who already closed the stream. To handle such a race condition, the server must remember the priorities of recently-closed streams. This implies that something like deferred erasure (or priority groups) is necessary to a usable implementation.

I suggest removing the paragraph “When a stream is closed … weights of its dependencies.” The proposal appears to be more self-consistent after this change, because it already says (emphasis added) “Inside the dependency tree, a dependent stream SHOULD only be allocated resources if the streams that it depends on *are either closed*, or it is not possible to make progress on them” and “An endpoint receiving a PRIORITY frame that changes the priority of a closed stream SHOULD alter the dependencies of the streams *that depend on it*, if it has retained enough state to do so.”

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Apr 2014 16:21:53 -0700

This all depends on what order resources are removed.

Say you have a simple arrangement where P = w12 and two children have
C1 = w1 and C2 = w3.

If P goes first, you get C1 = w3 and C2 = w9.  Then when C2 goes, you
get C1 = w3 still.  That's as Jeff has described.

But if C2 goes first, then you get P = w12, C1 = w3, which ultimately
leads to C1 = w12 when C2 is removed.

So yes, there is a problem.  The problem is premature loss of
information.  In the first scenario, we don't know that C1 and C2 were
former siblings and so we have to share resources around globally,
rather than taking the share from C2 and giving it all to C1.  So yes,
ideally, nodes shouldn't be dropped.   But...

We have to allow servers to limit their state commitment, and having a
specified practice for handling a very common case somewhat gracefully
is a good idea.  Including a warning about the consequences of early
tree pruning is probably the best that can be done.

On 16 April 2014 01:47, David Krauss <[email-masked]> wrote:
> I like the priority tree proposal. Hierarchy is already useful to prioritize
> connections against each other, so it’s natural to extend the concept into
> streams.
>
> I’m concerned about the method of priority redistribution, though. When a
> stream closes, its priority is distributed proportionally among its
> dependents, so they will have each only a fraction of the original priority.
> The child nodes are moved up the hierarchy to take the place of their former
> parent. This eliminates the distinction between one of many resources which
> load after the foreground (high-priority) page HTML completes, and one of
> only a few resources which load after a background (low-priority) page HTML
> completes.
>
> The collection of images on a page will initially load with speed
> proportional to the original page priority, but the last image to complete
> (which may be much larger than the others) does not inherit the total
> original priority but only its own fraction. With groups, on the other hand,
> stragglers get the full specified priority to themselves. A group better
> represents the task of loading a multi-resource page.
>
> On the other hand, the browser may reprioritize any resource that takes
> significant time to load. After all, there’s usually no point in parallel
> requests that aren’t served in time on the order of a round trip. However,
> my point is that a browser which doesn’t do so will be broken. It’s one more
> failure point.
>
> Specifying node erasure from the dependency tree may be unnecessary. The
> effect of closing a stream clearly should be the same as if it were blocked,
> which is effectively what the specification says anyway if it never mentions
> closure. Implementations may prune or collapse the tree to reclaim memory,
> but it’s only a minor detail. Both endpoints already know a closed stream is
> finished and won’t unblock again. A permanently blocked stream has no effect
> whatsoever on the hierarchy.
>
> Also, consider an image mentioned in the penultimate frame of the HTML
> stream. The browser requests it with a dependency which is stale by the time
> it reaches the origin, who already closed the stream. To handle such a race
> condition, the server must remember the priorities of recently-closed
> streams. This implies that something like deferred erasure (or priority
> groups) is necessary to a usable implementation.
>
> I suggest removing the paragraph “When a stream is closed … weights of its
> dependencies.” The proposal appears to be more self-consistent after this
> change, because it already says (emphasis added) “Inside the dependency
> tree, a dependent stream SHOULD only be allocated resources if the streams
> that it depends on *are either closed*, or it is not possible to make
> progress on them” and “An endpoint receiving a PRIORITY frame that changes
> the priority of a closed stream SHOULD alter the dependencies of the streams
> *that depend on it*, if it has retained enough state to do so.”
>

---

From: David Krauss <[email-masked]>
Date: Thu, 17 Apr 2014 09:14:48 +0800

> So yes, there is a problem.  The problem is premature loss of

Well, the other problem is that the revision (pull request) still mentions dependencies in the CLOSED state, so something’s gotta give.

> is a good idea.  

It’s a good idea, but not necessarily a must-have for an initial release. The amount of state is small. I think it can be managed well enough. Perhaps a LRU cache is a good approximation of behavior?

> Including a warning about the consequences of early

A set of guidelines for clients to judge the validity of a closed stream as a dependency would be nice. I’m not even sure how to specify this, though. (And I didn’t have any idea how to maintain the set of priority groups, either.) The server ideally should maintain a closed stream/priority group for each tab, and the client re-prioritizes those as the user clicks different tabs. But, there is no limit to the number of tabs in a window, and sloppy users really do open a lot.

I recall my earlier proposal where the server sends a reply PRIORITY to override a client request. This could be a valid pattern for any received PRIORITY that the server cannot service…

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Apr 2014 19:37:47 -0700

The real risk with further specificity here is that it encroaches on
implementation authority and autonomy.  Some of that autonomy is needed
because endpoints need to be able to handle abnormal load situations. In
those situations, dropping state might be the right answer.

I think that the best we can do is provide advice in this space anyhow.
>From an external perspective, it is almost impossible to validate the
behaviour of a peer anyway.

So, yes, LRU sounds like a great recommendation. Just don't expect a 'MUST'
to go it :)

We can't forbid the creation of dependencies on closed streams though. That
one's pure physics. Besides, I think that it will be very useful.
On Apr 16, 2014 6:14 PM, "David Krauss" <[email-masked]> wrote:

> Well, the other problem is that the revision (pull request) still mentions
> dependencies in the CLOSED state, so something’s gotta give.
>
> It’s a good idea, but not necessarily a must-have for an initial release.
> The amount of state is small. I think it can be managed well enough.
> Perhaps a LRU cache is a good approximation of behavior?
>
> A set of guidelines for clients to judge the validity of a closed stream
> as a dependency would be nice. I’m not even sure how to specify this,
> though. (And I didn’t have any idea how to maintain the set of priority
> groups, either.) The server ideally should maintain a closed
> stream/priority group for each tab, and the client re-prioritizes those as
> the user clicks different tabs. But, there is no limit to the number of
> tabs in a window, and sloppy users really do open a lot.
>
> I recall my earlier proposal where the server sends a reply PRIORITY to
> override a client request. This could be a valid pattern for any received
> PRIORITY that the server cannot service…
>
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Apr 2014 18:17:56 -0700

> slightly modify the priority structure.

Looking back at this, this proposal makes the following two changes:

1. removes priority groups

2. adds weights at all levels of the dependency tree (as opposed to
just at the grouping layer)

The first removes some capabilities, as has been noted elsewhere.  The
ability to create and weight a named thing that is independent of any
stream is a features, but it's also complexity.  This is a net
complexity loss.

The second is arguably an expansion of the capabilities, which could
be perceived as an increase in complexity, except for the fact that it
basically just removes a special case.  This is an increase in
capability, which might be perceived equally as an increase in
complexity or an increase in uniformity.

Personally, I'd like to hear more of what others think about this.
The comments I've seen are generally favourable, but I know that Mike
wants more time to consider the implications.

Is there anyone else on the fence, or - probably more importantly -
opposed to making this change?

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 Apr 2014 16:37:37 +1000

To magnify this a bit --

So far, I've heard reactions that range from neutrality to general support for Jeff's proposal <https://github.com/http2/http2-spec/pull/453>. 

We're late for declaring our next implementation draft, and have a few issues to clean up. So, unless I hear significant pushback on doing so in the next ~3 days, we'll incorporate Jeff's pull request into -12 and call that an implementation draft (along with any other changes we agree upon).

Keep in mind that this is deciding what to put into the next implementation draft -- we may still add to it or even change it based upon our experience with it and NYC. That said, we also have a strong desire to finish this work, so we don't have too many iterations to play with it.

Regards,

> stream is a features, but it's also complexity.  This is a net

I think you mean "improvement" here...

---

From: RUELLAN Herve <[email-masked]>
Date: Fri, 18 Apr 2014 15:11:12 +0000

I rather like the overall simplification of the proposal.

I however have one concern: priority groups are structures that the client knows will be persisted by the server. As such, a client changing the priority of a group is certain that the server will be able to apply it.
This is useful for example for the tab focusing use-case. Assuming the client creates a priority group for each tab, it can easily change the priorities for the different tabs when the user changes the foreground tab, and is certain that these changes will be applied by the server.
With the proposal, the client has no certainty that the server has retained enough information to apply priority changes for a tab switching. It can update the priorities (the weight) for the streams at the top of the sub-trees corresponding to each tab, but the server may already have discarded all information regarding these streams and be unable to apply the priority changes.

A possible workaround would be to strongly suggest to server implementations that keeping information about top level streams is helpful to client that want to reprioritize a whole set of streams.

Hervé.

> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: vendredi 18 avril 2014 03:18
> To: Jeff Pinner
> Cc: HTTP Working Group
> Subject: Re: HTTP/2 Priorities Proposal
>

---

From: Mike Bishop <[email-masked]>
Date: Fri, 18 Apr 2014 15:28:38 +0000

No objections to the change.  We still don't plan to implement this scheme at this point.

Sent from Windows Mail

From: RUELLAN Herve<mailto:[email-masked]>
Sent: ?Friday?, ?April? ?18?, ?2014 ?8?:?15? ?AM
To: Martin Thomson<mailto:[email-masked]>, Jeff Pinner<mailto:[email-masked]>
Cc: HTTP Working Group<mailto:[email-masked]>

Herv?.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Apr 2014 09:41:09 -0700

> I however have one concern: priority groups are structures that the client knows will be persisted by the server. As such, a client changing the priority of a group is certain that the server will…

There are no guarantees.  Groups can be discarded in the same way that
priority information for an individual stream can be.  There might be
a greater incentive to keep it for longer, but it's still expendable
in case of memory pressure.  (I note here that memory pressure had
better be extreme for you to want to save this tiny amount, though I
can devise schemes where it could make sense.)

---

From: David Krauss <[email-masked]>
Date: Sat, 19 Apr 2014 02:53:05 +0800

> complexity or an increase in uniformity.

An increase in uniformity is a decrease in complexity.

I’m still in the process of implementation, but my reaction was that I plan to implement a hierarchy of groups anyway.

I’d be in favor of simply allowing the priority-group and priority-dependency flags to coexist. There’s no reason a group shouldn’t be allowed to depend on something.

Conceptually, group dependency allows the client to form a plan to download different types of resources: First get the critical markup, then all the small images, then bigger images, then bring interactive elements to life. Each category gets a group and each group depends on the last.

There’s no way to do this with dependencies alone or weighting alone. Workarounds would include picking one resource to use as a dependency-target proxy for its group, which falls apart if it completes too soon, or dynamically re-weighting groups, which loses some efficiency and is probably trickier to get working flawlessly on both the client sides.

If complexity goes up, there’s still plenty of room for graceful degradation. Website responsiveness is the only thing on the table here, we might as well provide more tools. (I’m tempted to suggest that PRIORITY frames be replaced by a variety of header frame, restricted to a set of connection-level headers, so the toolbox doesn’t need to be closed at all.)

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sat, 19 Apr 2014 09:15:35 +0900

+1 to include Jeff's proposal. Primary complexity of dealing with stream
dependency tree is not reduced much, but framing gets simpler and we don't
need stream group.

Best regards,
Tatsuhiro Tsujikawa
 2014/04/18 15:37 "Mark Nottingham" <[email-masked]>:

> To magnify this a bit --
>
> So far, I've heard reactions that range from neutrality to general support
> for Jeff's proposal <https://github.com/http2/http2-spec/pull/453>.
>
> We're late for declaring our next implementation draft, and have a few
> issues to clean up. So, unless I hear significant pushback on doing so in
> the next ~3 days, we'll incorporate Jeff's pull request into -12 and call
> that an implementation draft (along with any other changes we agree upon).
>
> Keep in mind that this is deciding what to put into the next
> implementation draft -- we may still add to it or even change it based upon
> our experience with it and NYC. That said, we also have a strong desire to
> finish this work, so we don't have too many iterations to play with it.
>
> Regards,
>
>
>

---

From: RUELLAN Herve <[email-masked]>
Date: Tue, 22 Apr 2014 16:05:43 +0000

> Sent: vendredi 18 avril 2014 18:41
> To: RUELLAN Herve
> Cc: Jeff Pinner; HTTP Working Group
> > I however have one concern: priority groups are structures that the client
> knows will be persisted by the server. As such, a client changing the priority of
> a group is certain that the server will be able to apply it.
> 

I agree that there are no guarantees, but I think that if a group is discarded by the server due to memory pressure, then that means that the server is relinquishing any pretension to do any prioritization based on client hints.
On the other hand, a server need to discard closed streams and if it is too eager to discard top level streams, the client lose some ability to re-prioritize a whole sub-tree of streams.

Hervé.

---

From: [email-masked]
Date: Tue, 22 Apr 2014 10:31:13 -0700

Will's original document on priorities included a few use cases that I'm fuzzy on how they would work in this new proposal. For example, let's say my browser is set to open two tabs to webpage1 and webpage2 when I first launch it. Let's say that webpage1 is the foreground tab initially but I immediately decide to click on webpage2 while both pages are loading. Changing the priority of the objects to reflect this was an easy thing to do with priority groups but I'm fuzzy on how this would work using Jeff's priorities proposal.  Can someone clarify?

Thanks in advance,

Peter

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 22 Apr 2014 10:53:10 -0700

On Tue, Apr 22, 2014 at 10:31 AM, <[email-masked]> wrote:

> Will's original document on priorities included a few use cases that I'm
> fuzzy on how they would work in this new proposal. For example, let's say
> my browser is set to open two tabs to webpage1 and webpage2 when I first
> launch it. Let's say that webpage1 is the foreground tab initially but I
> immediately decide to click on webpage2 while both pages are loading.
> Changing the priority of the objects to reflect this was an easy thing to
> do with priority groups but I'm fuzzy on how this would work using Jeff's
> priorities proposal.  Can someone clarify?
>
> Thanks in advance,
>
> Peter
>
>
Simply send a PRIORITY frame for the root dependency of webpage2 to
increase its weight.

For example, let's say you have

root --(256)-- webpage1/ .... webpage 1 dependencies
      \--(16)-- webpage2/ .... webpage 2 dependencies

where webpage1 has weight 256 because it was the foreground tab. If the
user clicks on webpage2, send a PRIORITY frame for webpage2 with the same
0x0 dependency but with a higher weight. You can even send another for
webpage1 with the a lower weight.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 23 Apr 2014 11:43:46 +1000

OK, let's wrap this up.

I don't hear anyone objecting, and there seems to be broad support for this change (albeit not fervent).

Martin, let's go ahead and incorporate it. 

Regards,

On 23 Apr 2014, at 3:53 am, Jeff Pinner <[email-masked]> wrote:

> Simply send a PRIORITY frame for the root dependency of webpage2 to increase its weight.
> 
> where webpage1 has weight 256 because it was the foreground tab. If the user clicks on webpage2, send a PRIORITY frame for webpage2 with the same 0x0 dependency but with a higher weight. You can even send another for webpage1 with the a lower weight.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Apr 2014 11:26:53 -0700

> Martin, let's go ahead and incorporate it.

In progress.

Folks, it's an error to create a dependency from A -> A, but what if B
depends on A, then A is reprioritized to depend on B?

Option 1: It's possible to address this by moving B to the place of A first.
Option 2: Explode.

(This is an existing bug, not a special fault of Jeff's change.)

---

From: Roberto Peon <[email-masked]>
Date: Wed, 23 Apr 2014 12:31:40 -0700

option 1, please.
-=R

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Apr 2014 12:42:05 -0700

> option 1, please.

That's good, because I have all the text for that :)  It's a good
example to show because it's the most complex example (and a good test
case, implementers).

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Apr 2014 12:49:31 -0700

> Martin, let's go ahead and incorporate it.

Incorporated: https://github.com/http2/http2-spec/commit/c9147e7062ccad0702cfd8edfc241f4a2ffcacb7

There are two significant changes from what Jeff proposed.

The first is the addition of text that covers the reprioritization of
a stream to depend on one of its dependencies:
https://github.com/http2/http2-spec/commit/c9147e7062ccad0702cfd8edfc241f4a2ffcacb7#diff-8894168382f6487e5e38c4306e613a88R1269

The second is text covering a second reason for needing to keep
priority state for closed streams, as we discussed at some length:
https://github.com/http2/http2-spec/commit/c9147e7062ccad0702cfd8edfc241f4a2ffcacb7#diff-8894168382f6487e5e38c4306e613a88R1302

Other than that, there are a few minor differences that I hope are
perfectly harmless.  It was a pretty good pull request, so the changes
are minimal.

---

From: [email-masked]
Date: Thu, 24 Apr 2014 08:55:31 -0700

Thanks Jeff. Makes sense to me.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Apr 2014 09:47:27 -0700

> Thanks Jeff. Makes sense to me.

Note that you need a single root dependency for the page.  The good
news there is that this is always the case when web browsing.  Not
necessarily so in other contexts, which might need >1 PRIORITY frames.

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Fri, 25 Apr 2014 02:10:58 +0900

On Fri, Apr 25, 2014 at 1:47 AM, Martin Thomson <[email-masked]>wrote:

> news there is that this is always the case when web browsing.
>

​... as long as server retains closed stream state​ in dependency tree,
right?
​If server forgets those streams, we easily see multiple roots even in web
browsing.​

​Best regards,
Tatsuhiro Tsujikawa​

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Apr 2014 10:29:44 -0700

On 24 April 2014 10:10, Tatsuhiro Tsujikawa <[email-masked]> wrote:
> ... as long as server retains closed stream state in dependency tree, right?
> If server forgets those streams, we easily see multiple roots even in web
> browsing.

Yep.  That is bound to happen, though I think that a good
implementation would keep direct root dependency as long as possible,
discarding other nodes first.