Re: Diminishing priorities in proposal

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 <potswa@gmail.com> 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.”
>

Received on Wednesday, 16 April 2014 23:22:20 UTC