[Bloat] The Effect of Network and Infrastructural Variables on SPDY's Performance

[Dave Taht <dave.taht@gmail.com>]

Last night's reading was quite good:

http://arxiv.org/pdf/1401.6508.pdf


"As RTT goes up, it becomes increasingly
expensive for HTTPS to establish separate connections for each resource.
Each HTTPS connection costs one round trip on TCP handshaking and
a further two on negotiating SSL setup. SPDY does this only once (per
server) and hence reduces such large waste by multiplexing streams over a
single connection. "

...

"the separation between RTT
and bandwidth is not particularly distinct. This is because HTTPS tends to
operate in a somewhat network-unfriendly manner, creating queueing delays
where bandwidth is low. The bursty use of HTTPS' parallel connections cre-
ates congestion at the gateway queues, causing upto 3% PLR and inflating
RTT by upto 570%. In contrast, SPDY causes negligible packet loss at the
gateway.

The network friendly behaviour of SPDY is particularly interesting as
Google has recently argued for the use of a larger IW for TCP [7]. The
aim of this is to reduce round trips and speed up delivery | an idea which
has been criticised for potentially causing congestion. One question here
is whether or not this is a strategy that is speci cally designed to oper-
ate in conjunction with SPDY. To explore this, we run further tests using

and bandwidth xed at 1Mbps (all other parameters as above). For HTTPS,
it appears that the critics are right: RTT and loss increase greatly
with larger IWs. In contrast, SPDY achieves much higher gains when
increasing the IW without these negative side e\vffects. "

and then they inject packet loss:

we inspect the impact of packet loss on SPDY's performance. We
fix RTT at 150ms"

Sigh, the rest of the paper is pretty good, but they should have looked at
packet loss at 10-30ms at least.

" and BW at 1Mbps, varying packet loss using the Linux
kernel rewall with a stochastic proportional packet processing rule between
0 and 3%.
. Figure 6 presents the results.
Immediately, we see that SPDY is far more adversely a\vffected by packet
loss than HTTPS is. This has been anticipated in other work [29] but never
before tested. It is also contrary to what has been reported in the SPDY
white paper [2], which states that SPDY is better able to deal with loss.
The authors suggest because SPDY sends fewer packets, the negative e\vect
of TCP backo\v is mitigated. We nd that SPDY does, indeed, send fewer
packets (up to 49% less due to TCP connection reuse). However, SPDY's
multiplexed connections persist far longer compared to HTTPS. "


-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article