So you agree that single connection is a problem :)? Under mobile, where high RTT is the norm rather than the exception, this has compound negative effect on performance (mistaken long response time as packet loss, reducing the congestion window that makes all flows suffer, etc, etc.). Everything else being equal, applying SPDY on mobile introduced this new mobile "vulnerability", isn't this SPDY's negative impact on Mobile? Sure, if cellular networks has the same delay/packet loss characteristics as wired/wifi, SPDY would fly, but mobile and wired/wifi are clearly not the same. Also, I used that paper just as an example showing SPDY's performance problem on mobile (with very nice detailed analysis why SPDY suffers). My conclusion of "SPDY sucks on mobile" is from my experience, not from that paper. I just use that paper to show my point. Actually, I think their paper's conclusion is a little bit too "polite" toward SPDY. [Edit: adding reference to the paper] In that paper the sentence right before the "conclusion" you quoted is "In cellular networks, there are fundamental interactions across protocol layers that limit the performance of both SPDY as well as HTTP."

I've tested SPDY over wired / wifi but not over mobile so my mobile experience is anecdotal.

That said all my mobile browsing (minus HTTPS) is run over SPDY (via the Google proxy) and I wouldn't describe it as sucking.

Even in the HTTP case it will still depend on what resource the packet loss etc., occurs for e.g. if it's something on the critical rendering path will it make that much difference?

Glad that you brought up the critical rendering path, because SPDY uses single connection for all requests, once a packet loss/re-transmission happens, the entire connection's congestion window will be cut, which will affect all requests, so most definitely it'll hurt requests on the critical rendering path. Actually the good old HTTP1.1 doesn't suffer from this because if multiple connections are used, and only one connection suffers packet loss, only the request using that connection will suffer(assuming pipelining is not enabled), the other requests using other connections won't. This actually reduces the chance of resources on critical rendering path suffer from packet loss.

But is there any research into how often the 'independent' connections actually mitigate against packet loss?

Even on HTTP if the packet loss comes in the middle of negotiating the connection for the CSS, the page is still going to be waiting for the three seconds timeout before re-negotiating the connection.

We've seen in our work, that under high RTT, high packet loss rate (you can simulate similar effect by using things like dummynet, but it wont' be exactly what you'd expect on cellular network due to reasons mentioned in ATT lab's paper), SPDY results in performance degradation over raw HTTP. Also, I'm not saying 'independent' connections can mitigate against packet loss, it can't, and for the case you mentioned, definitely we'd get a performance hit (either first paint or pageload). It's just SPDY makes it worse than the default HTTP behavior, and that's understandable because it only uses single connection, and single connection suffers from different sorts of problem, and you seem to agree this from your first comment.