3 ms·
Why did they take the effort to produce an entire paper, over a research question that has a simple logical answer? The research question (sort of): Is SPDY, w
by tinco 13y ago
Why did they take the effort to produce an entire paper, over a research question that has a simple logical answer?
The research question (sort of): Is SPDY, which was designed to make HTTP work better on connections with more bandwidth and not worse on less bandwidth, increase performance on connections with less bandwidth (and not really related more latency)?
Their answer (sort of): no, as designed SPDY only increases performance on connections with more bandwidth, and performs similar to HTTP on smaller bandwidths.
Their conclusion (sort of): TCP is not very suitable for transmitting data on high bandwidth (relatively) high latency connections, we should use a different transport layer protocol.
What your reaction should be (sort of): No shit sherlocks, that's exactly what everyone thought 15 years ago and only now the idea is picking up steam, with HTML5 including SCTP in the spec, and Google working on the QUIC effort.
- jsnell 13y agoYou're wrong on all counts. First, the results aren't obvious (nor the underlying reasons). In fact Google published results a couple of years ago that got massive amounts of coverage suggesting the opposite (http://googledevelopers.blogspot.com/2012/05/spdy-performance-on-mobile-networks.html http://googledevelopers.blogspot.com/2012/05/spdy-performanc...). I've worked on TCP optimization of mobile networks for the past 3 years, publicly criticized Google's study when it came out, and still the results of this paper are somewhat surprising to me. Second, the underlying issue isn't the latency or the bandwidth of the cellular connection. It's the unpredictability. In fact, the Google study was using dodgy methodology where they assumed that a cellular connection could be modeled simply by bandwidth throttling + delay. Third, it's absolutely not true that everyone has been thinking that replacing TCP is the solution, even if its problems in the cellular context have been acknowledged. If anything, the opposite, nobody has been thinking of it as a viable solution before QUIC. The deployment problems have just been too big -- but Google is in a unique position to fix that.
- tinco 13y agoAh, I did not know Google was actively positioning SPDY as a good solution for mobile networks, I missed that. I sort of want to defend that I counted the unreliableness of cellular as lack of bandwidth, but you're right if that's really wanted to say then I should have said it much differently. But do you really find it surprising that in the light of unreliability SPDY would not perform much better than plain HTTP? To your third point: I wasn't saying everyone said it was a viable idea. Instead I say that only recently, with SCTP in HTML5 and QUIC people are beginning to think it might be a viable idea. But everyone has known for years that TCP just isn't suitable for the modern web, and if only we could, we would have substituted it with SCTP long ago.
- jsnell 13y agoThere are factors favoring SPDY, such as fewer roundtrips thanks to pipelining, or header compression removing the uplink as a bottleneck. There are factors favoring HTTP, such as being less vulnerable to head of line blocking, higher effective congestion/receive windows, and a smaller reduction on the effective congestion window from a single packet loss. Without testing, it's not at all obvious which set of benefits is actually more significant in the real world. But if I'd had to guess, I would have expected a reduction in roundtrips to be the dominant factor. So yes, I'm a bit surprised.
- tinco 13y agoAlright, makes sense :) Thanks for responding.
- thrownaway2424 13y agoThe cited Google paper used a simulated mobile network via USB tethering to a machine with traffic shaping. The AT&T paper used an actual air interface. The conclusion I drew from the paper was a little different from "SPDY no faster than HTTP on mobile." My conclusion was "Mobile sucks equally hard for any application layer protocol."
- gsnedders 13y agoWhere does HTML5 include SCTP? Searching for SCTP in the HTML spec finds nothing! (And why would it, it is agnostic towards the transport layer!)
- tinco 13y agoIt's part of the WebRTC part, which extends the HTML5 environment with UDP communication. Documented here: http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-00 http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-...
- corresation 13y agoSPDY is a significant net benefit for high latency / high bandwidth connections. Indeed, I would say that is its primary strength. I'm starting to find it curious how virtually every "SPDY doesn't improve things" study implements the same two critical flaws, to the point that it starts to seem conspiratorial. a) They compare SPDY, with mandatory TLS, with unencrypted HTTP. HTTP needs to go away, and the only valid comparison would be with HTTPS. b) They implement their test via a non-caching proxy that then proxies request to "top sites". This is identical to the critical fault that the other primary SPDY critical paper makes, because it essentially invalidates the primary value of SPDY (the upstream site becomes the weak link, itself not using SPDY). This is a ridiculous way of demonstrating the strengths or weaknesses of SPDY (akin to declaring a sports car slow by demanding that it drive behind a transport truck), yet this same methodology keeps curiously recurring.