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

31–40 of 66 posts

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

#31

Post by gsnedders »

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…

Where does HTML5 include SCTP? Searching for SCTP in the HTML spec finds nothing! (And why would it, it is agnostic towards the transport layer!)

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

#32

Post by gsnedders »

fsiefken wrote: post #17
justinsb wrote: post #2

I think QUIC is supposed to address this: http://blog.chromium.org/2013/06/experimenting-with-quic.htm...

thx, something like that would be great to use over packet radio & gsm. If someone builds a QUIC proxy server service with client to speed up browsing over slow links like Opera does with their always open 'socket' connection we have another choice. The Opera solution is actually quite usable. I wonder if similar performance gains can be achieved by using openvpn with udp with or without ziproxy. If so you wouldn't b…

Opera Max is meant to be something like that — a generic VPN that compresses all non-encrypted transfers (which are, of course, increasingly infrequent).

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

#33

Post by tinco »

jsnell wrote: post #30
tinco wrote: post #25

Earlier quoted context omitted.

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

Alright, makes sense :) Thanks for responding.

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

#35

Post by gsnedders »

salient wrote: post #29

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…

The problem is plenty of boxes (esp. consumer-grade NAT stuff!) drops any IP packet that is not TCP or UDP, hence introducing anything at that layer is as hard as introducing IPv6 (i.e., it might happen, eventually, maybe). This is why Google's QUIC is layered on top of UDP — as UDP is a thin enough layer (on top of IP) it doesn't add too much bloat.

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

#36

Post by tinco »

gsnedders wrote: post #31
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…

Where does HTML5 include SCTP? Searching for SCTP in the HTML spec finds nothing! (And why would it, it is agnostic towards the transport layer!)

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

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

#37

Post by corresation »

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…

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

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

#38

Post by username223 »

josteink wrote: post #21
matthewmacleod wrote: post #12

Earlier quoted context omitted.

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…

If they want to save a bit of bandwidth, how about removing this HTTP header?

> P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&a... for more info."

I can't believe they're still adding that...

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

#40

Post by BitMastro »

est wrote: post #27
matthewmacleod wrote: post #14

Earlier quoted context omitted.

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.

And both are proprietary.. moreover you're mixing formats and containers
Post reply on HN