Re: SPDY Review

On Thu, Jun 7, 2012 at 9:12 AM, Martin Thomson <martin.thomson@gmail.com>wrote:

> Interesting, thorough and well-considered review.  A few opinions
> included inline:
>
> On 7 June 2012 07:18, Martin Nilsson <nilsson@opera.com> wrote:
> >  By adding priority information to the requests the server can take
> >  active decision in which resource to send first.
>
> I don't think priority is as big a deal as people are making out.  On
> the contrary, it's a distraction.
>

I didn't put in priorities because I wanted them - I put them in because
the first version of SPDY, which didn't have them was slower than HTTP :-)
 The problem is that once the client can flood the server with requests,
the server gets inundated with a set of low priority (usually images) and
high priority requests. Without priorities, these all compete for the same
bandwidth leading to materially slower page load times.  I encourage you to
remove priorities and see this for yourself - it is evident with every
benchmark we ran.


> 1. The server is probably more likely to know what resources need to
> be acquired first.
>

Again, this is not true.  You should look into the resource loaders for
firefox or webkit before making such claims.  Only the browser knows which
resources are blocking rendering.  The client can prioritize best and MUST
be given a mechanism to tell the server which resources are needed first.
 This is actually an area where browsers can continue to improve.  The JS
file that the renderer is blocked on right now is more important than the
others.  Chrome, at least, doesn't yet make this distinction (but in the
future it could!)  Also, browsers are multi-tabbed beasts these days.  The
tab which the user is active on should have higher priority than all other
tabs.  The server, of course, has no idea which request is coming from
which tab or which tab is most important.

Of course, server implementors can ignore the browser hint (this is allowed
in the protocol today), but I strongly advise against it.



> 2. The client has the ultimate control over what resources are
> requested, so they already have control over priority (if resource A
> is more important than resource B, just don't request resource B).
>

It's about the round trips, not the ordering.  100ms delays are simply not
acceptable anymore.

Mike




>
> Beyond this, the main reason you might use priority is for large
> concurrent representation (i.e., file) transfers.  Bittorrent has this
> feature for torrents with multiple files.  The utility for HTTP is
> somewhat limited.  That's not to say that it isn't a useful feature,
> but I don't see it as a core necessity.
>
> >  [...]  While the concerns is valid, flow control looks like
> >  overkill to something where a per-channel pause control frame could
> >  do the same job with less implementation and protocol overhead.
>
> The problem with a pause frame is the time that it takes to propagate.
>  During that time, you can end up getting a lot of data that you can't
> do anything with.  Flow control is a well understood mechanism that
> solves the problem.
>
> I'm going to argue that flow control is the necessity and priority is
> the unnecessary feature gold plating.
>
> >  The problem with [asynchronous headers] is that it creates a situation
> where a
> >  potentially critical header for the interpretation of the content is
> >  sent last, thus forcing the receiver to put data processing on hold.
>
> If you read the guidance on trailing headers (footers?), the key
> message is that they should not be critical.  The same guidance should
> apply to any asynchronous headers.
>
> The utility of a trailer can be significant.  For instance, if you
> have to calculate a hash of the representation, they represent a
> significant performance gain.  In this case, I can imagine wanting to
> send supplementary information after the representation; Link headers,
> for instance.
>
> > 2.6. Push
>
> Is not sufficiently justified to warrant the significant change in
> protocol semantics.
>
>