Re: Priority straw man

On 8 February 2014 10:22, Jeff Pinner <jpinner@twitter.com> wrote:
> In contrast to dependencies, where the incoming request looks something
> like:
>
> G1 (80% w/ S1 <-- S3) and G2 (20% w/ S5 <-- S7)
>
> I can proxy these approximately to the backend server as something like:
>
> Gn (1/"n"% w S1 <-- S3 & S5 <-- S7)

Unless I misunderstand, that's not entirely correct.  The
prioritization schemes that both Will and I described wouldn't permit
that.  You would have to choose (S1, S3) <-- (S5, S7) or (S1, S5) <--
(S3, S7) or (S1) <-- (S3, S5) <-- (S7), or something like that.

In all cases, the end states produced by the dependency schemes Will
and I wrote up (I don't know what Roberto is talking about here) are
exactly equivalent to the scheme Osama described unless there are more
layers of dependencies than there are allowed priorities.

The real difference between the schemes is how they handle transitions
into the desired end state, particularly when an intermediary needs to
translate multiple ways between connections.

It seems to me that a dependency scheme has some advantages when it
comes to transitions (the video reprioritization thing, maybe some
proxy cases).  It may be that a dependency scheme also has advantages
when it comes to translating, but I'm not sure that it's a clear win
without full tree-based dependencies.  The cost of these purported
advantages is largely borne by the server, which has to deal with the
additional complexity of managing dead streams, garbage collection.

I'll also point out that we have to be careful not to raise the bar
too high for the server implementers, otherwise we will find that they
start ignoring priority more than we would like.  That creates
incentives for browsers to hold back requests, apply heuristics,
etc...

Received on Monday, 10 February 2014 18:02:22 UTC