Interested readers may want to read the original research paper (PDF) by @mikebelshe.

Basically, Belshe is saying that increasing the client's bandwidth is not as effective as reducing round-trip time (RTT).

[I]f users double their bandwidth without reducing their RTT significantly, the effect on Web Browsing will be a minimal improvement. However, decreasing RTT, regardless of current bandwidth always helps make web browsing faster. To speed up the Internet at large, we should look for more ways to bring down RTT. What if we could reduce cross-atlantic RTTs from 150ms to 100ms? This would have a larger effect on the speed of the internet than increasing a user’s bandwidth from 3.9Mbps to 10Mbps or even 1Gbps.

The gist of his argument is that, while increasing bandwidth does in fact reduce latency, there are diminishing returns on this benefit as bandwidth increases.

Belshe concedes that this issue can be addressed by reducing the number of HTTP requests that are made, but the designers of SPDY seem to feel that there's value to be added by changing HTTP itself. SPDY has done a few things in the direction of reducing RTTs (and # of requests made in serving a typical website), and claim that "SPDY's latency savings also increased proportionally with increases in RTTs, up to a 27% speedup at 200 ms" in this white paper.

In a world of web services, it's the latency that gets you.

This is why aggressive caching strategies abound, and 4-person weekend hacks inevitably become huge operational undertakings.

Yup, it's still the latency that dominates.

Latency is everywhere, and it's expensive.

Kudos to them for trying new things as long as they don't move away from HTTP altogether.