From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 218C821F22A for ; Thu, 17 Apr 2014 10:22:21 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u57so708165wes.22 for ; Thu, 17 Apr 2014 10:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=TyLwUSvRk07LYyh6YqsUeY17lQWe0p4UaCc64DRgoJw=; b=BLcL/m/sy+Q1KyKcpzbjTMUNL5KIPhduThC5V/Sj23V6DBK9HAdm3f2TSbMi/1Ijtq ALlwSiFZgN9zdWvWcpWtt6M1u5tHWd57xAge1gkik5ojlT44rnJOrFZJYoYYKb66+Yzz hsfHaeQcu44BY79DOrbxwJfbC+TfpetkH3NIW+lX007uFDLJSNMP4KOr2fy3iQixi7wv HNkCd2OXIgrONg4gFrKhByuXRAnbrOVCXADAxiuohRLk7/7jGrQaJJ51a21fKGjW/3u8 xYurrGj7iBfc204Iif9CstTjBqTIfX4H73mlE2vzXnY2q2OervS0AtM/ZK/AGdav9lPE VRsA== MIME-Version: 1.0 X-Received: by 10.180.76.166 with SMTP id l6mr13249762wiw.17.1397755340037; Thu, 17 Apr 2014 10:22:20 -0700 (PDT) Received: by 10.216.177.10 with HTTP; Thu, 17 Apr 2014 10:22:20 -0700 (PDT) Date: Thu, 17 Apr 2014 10:22:20 -0700 Message-ID: From: Dave Taht To: bloat , "aqm@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Bloat] The Effect of Network and Infrastructural Variables on SPDY's Performance X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 17:22:22 -0000 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=0Bffects. " 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=0Bffected 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=0Bect of TCP backo=0B 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. " --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article