Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“SPDY does not clearly outperform HTTP over cellular networks” [pdf]

conferences.sigcomm.org

Post reply on HN
Print view View original

21–30 of 66 posts

Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]

#21

Post by josteink »

matthewmacleod wrote: post #12
josteink wrote: post #10

It doesn't matter if SPDY offers and technical improvements or not to our good, robust and lasting protcols HTTP. It's Google who is promoting it and all the "hip" hackers will rally for its cause.

That's a non sequitur - SPDY shows markedly improved performance over wired and 802.11 networks. The underlying problem discussed in the paper is down to TCP's interaction with cellular networks, and just happens to particularly punish SPDY somewhat more than HTTP. That's something that can be worked on and indeed there's a recommendation for improving it. I'd hope something like this would be included in HTTP/2.0, o…

Since SPDY was created with DSL MTUs in mind[1] and optimized for them only (unlike plain HTTP which was transport neutral and lasted almost 20 years) I don't find it hard to believe that if you look anywhere outside Google's test-matrix you will see the benefits of SPDY tapering away almost instantly.

[1] Basically, the test was: will one web-request (including all of Google's tracking headers) to google.com or any of its adwords/analytics beacons exceed one TCP packet and cause possible TCP reassembly-issues or not when using regular consumer-grade DSL MTUs?

Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]

#22

Post by d0ugie »

Hey Ilya: Is it possibly in the works to merge QUIC's UDP and magical error correction into whatever SPDY doesn't have that QUIC could complement it with, maybe eventually abandoning QUIC and just going full-force on a further-supercharged SPDY?

Thanks for lowering my bounce by the way..

Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]

#23

Post by d0ugie »

ch0wn wrote: post #8
blueskin_ wrote: post #6

Earlier quoted context omitted.

Because it's a binary protocol without the documentation, intuitiveness, and openness of HTTP. Yes, implementations exist for $whateverWebserver, but most people who add them won't understand the protocol, and can't debug when something goes wrong.

It's a new protocol, what do you expect? Tooling will improve over time.

> It's a new protocol, what do you expect?

It's in use in significant capacities on the most-tracked websites with impressive results you are welcome to easily see for yourself firsthand on your own server. More browsers than Chrome support it. More than one popular server supports it, with Nginx bundling it. CDNs are getting on board. Etc. This is the first somewhat-negative article I've run into about it.

That Google keeps working on it and releasing new drafts rather than kicking back and leaving it alone for the sake of creating an appearance of maturity, tabling better ideas they come up with for later, I don't think is a sign of lack of maturation, rather a sign that the demand for SPDY and improved performance is strong because people are finding out it's helpful and that Google can be relied upon further to make the web faster.

Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]

#24

Post by jsnell »

tinco wrote: post #20

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 incre…

You'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-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.

Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]

#25

Post by tinco »

jsnell wrote: post #24
tinco wrote: post #20

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 incre…

You'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-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 res…

Ah, 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.

Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]

#26

Post by znowi »

josteink wrote: post #10

It doesn't matter if SPDY offers and technical improvements or not to our good, robust and lasting protcols HTTP. It's Google who is promoting it and all the "hip" hackers will rally for its cause.

Their promotion style is rather interesting [1].

Implementers such as AGL are bypassing the WG, choosing to emit I-Ds and implementing and deploying because there is little to be gained from WG discussions. This is not necessarily a bad thing, but it does raise a question of whether what is good for Google is good for the Web as a whole

[2]:

If, a few years ago, Microsoft did the same thing I have no doubt what the public reaction would be.

Sadly, a lot of people still consider Google "don't be evil" heroes of the Internet, despite everything we've seen and heard. The brand loyalty is quite impressive.

[1] http://www.ietf.org/mail-archive/web/tls/current/msg10598.ht... [2] http://www.ietf.org/mail-archive/web/tls/current/msg10616.ht...

Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]

#27

Post by est »

matthewmacleod wrote: post #14
blueskin_ wrote: post #3

I really don't see the point of stuff like SPDY and WEBP/WEBM. They're just google doing what Microsoft did in the 1990s, setting their own proprietary 'standards' instead of working to improve things.

I really don't see the point of stuff like SPDY and WEBP/WEBM. The former is generally more performant that HTTP, and the latter also offer benefits versus other options. They're just google doing what Microsoft did in the 1990s, setting their own proprietary 'standards' instead of working to improve things. This is dangerously wrong, for two reasons: 1. These are open standards. They're not proprietary. 2. What is "…

you know what else offered more benifits?

WMA over MP3, WMV over AVI.

Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]

#28

Post by salient »

blueskin_ wrote: post #3

I really don't see the point of stuff like SPDY and WEBP/WEBM. They're just google doing what Microsoft did in the 1990s, setting their own proprietary 'standards' instead of working to improve things.

No, that's not at all like that. First off, they are proposing them to actually be standards, not just proprietary extensions that no one else can use, like Microsoft was doing.

Second, WebM is actually open source, not proprietary.

Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]

#29

Post by salient »

Isn't SPDY encrypted by default? Why would you assume it should outperform the unencrypted HTTP? Is it because Google made that claim, or why?

Either way, security at the application level on the Internet seems quite broken. We need easy to implement strong security at the Transport and IP levels. Google (or IETF, rather) should be experimenting with a CurveCP-like protocols to encrypt all the packets on the Internet to replace TCP. That's what I'd really like to see.

Re: “SPDY does not clearly outperform HTTP over cellular networks” [pdf]

#30

Post by jsnell »

tinco wrote: post #25
jsnell wrote: post #24

Earlier quoted context omitted.

You'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-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 res…

Ah, 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?…

There 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.

Post reply on HN