SPDY stream prioritization

[Robert]

Hi,

just a thought:
When the SPDY protocol spec is nearly finished, people will start
coding and just want to see it running.
But: A major benefit of SPDY is that streams can be prioritized. I
assume that some quick hacks of the protocol implementations will have
bad performance due to bad prioritization of streams and frame
"scheduling".
Would it be good to give people an abstract reference how an
implementation of a client and server can achieve good performance and
benefit from stream priority? With abstract reference I want to say
that people do not get a reference implementation in C or Java - but
some guidelines.
Frame scheduling with stream priorization seems to have the same
semantic as process/thread schedulers in operating systems. Maybe SPDY
implementations can borrow scheduling experiences for example from the
Linux O(1) process scheduler.

Robert

[Bram Cohen]

On Nov 18, 11:58 am, Robert <robert.st...@googlemail.com> wrote:
>
> Would it be good to give people an abstract reference how an
> implementation of a client and server can achieve good performance and
> benefit from stream priority?

The simplest strategy is to just give priority based on what content
type something is. In descending order: css, html, js, gif, jpg, flv,
mpg

[Roberto Peon]

Yup. Also, when we add flow control, we're likely to introduce priority 'groups' as well as the individual priority.

The reason behind that is so that we can allow the client to specify how much 'speculative' stuff they want, e.g. X-Associated-Content.

Note that server-push != 'speculative', as we may implement 'subscription' or 'notification' channel stuff in the future.

-=R

[Robert]

Sure, priorities for content is based on content type (a clear N-to-1
mapping).
But: the question is: Shall we give implementors of the protocol
implementation (the code, that handles frames and stream of all
connections) an abstract reference code how to implement an effective
stream/frame scheduler? Means: code, that provides the throughput that
SPDY shall provide.

Robert

[Roberto Peon]

As users open tabs in the background, change tabs, etc, the heuristics involved for picking priorities may not be as straightforward as we think today.

I personally think that it is perfectly reasonable to leave it up in the air-- I would like for browser maintainers to play around with this and have competition amongst them "choose" the best priority assignment scheme.

-=R

[Bram Cohen]

On Nov 18, 2:04 pm, Roberto Peon <fe...@google.com> wrote:
> As users open tabs in the background, change tabs, etc, the heuristics
> involved for picking priorities may not be as straightforward as we think
> today.
>
> I personally think that it is perfectly reasonable to leave it up in the
> air-- I would like for browser maintainers to play around with this and have
> competition amongst them "choose" the best priority assignment scheme.

There's a much bigger problem lurking in there. Simple per-object
priorities don't take into account the fact that some tabs are
foreground and some are background, and it's possible to switch them
back and forth. The simplest way to deal with this is to let the
client report groupings to the server, and let it inform the server
that a particular grouping has switched between the foreground and
background. It would also be then important to allow a single request
and belonging to multiple groupings, because it should be downloaded
quickly if it's in a foreground one even if it was previously in a
background one.

This sort of functionality is something which I think definitely
should be added to SPDY.

[Roberto Peon]

We've had some rather short conversations about this, but no work was done on it yet.

Part of the interesting complexity is thinking about how this interacts with flow control on an intermediary (e.g. reverse proxy).

-=R