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 ffects. " 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 ffected 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 ect of TCP backo 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 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
