Re: Priority implementation complexity (was: Re: Extensible Priorities and Reprioritization)

On Fri, Jun 19, 2020 at 11:51 PM Tom Bergan <tombergan@chromium.org> wrote:

> The way I think of it is that reprioritzation can turn bad pushes into
> neutral pushes, but it can't turn bad or neutral pushes into good pushes. I
> validated the bad -> neutral hypothesis in a contrived / toy HTTP/2 sandbox
> a few years ago. What's missing is a really convincing case where push is a
> win (many good pushes). Despite a lot of looking, the only real-world case
> I've found is that paper from Akamai a few years back.
>
> I think my last email was too strong w.r.t. your above question. I don't
> think we should decide the push question now and I don't think
> reprioritzation alone is a motivating factor to maintain push. All I meant
> to say is: I believe that reprioritization is helpful for push, assuming we
> keep both.
>

Apologies. I could have phrased my question more clearly, the original
intent was "Assume that server push is here to stay. There may be cases
where reprioritizing in-flight pushes is useful, so does that make the
reprioritization feature more attractive on the whole?".

Regardless I think your additional description still stands. A server could
unwittingly push something at a higher priority than the client wants,
affecting the priority of things it does want. Without reprioritization the
only recourse is to starve the pushed stream of flow control or to close
the stream. I just don't know how often that would occur in practice.

Cheers
Lucas