Diminishing priorities in proposal

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.”