From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7439021F11C for ; Thu, 9 May 2013 13:55:19 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c13so6626517ieb.10 for ; Thu, 09 May 2013 13:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=bmbxr80Oh43DVBK7sET3ii7ZVe1U4sQj3n5rhQKVxvw=; b=cA4pgPODIsQ+Bus+sbLqp+VDTMvBsKLCF1GNT0QwDnM5T0XCr04y52mmI3jEFrIqH2 sY1MhhpJbbMvL5N35XRc8LkW5D2e8NQkQeFVVoFIIfcsv9rsM54HAfIGS346hoT0X1yT VmZ8/YDwPQa17vpSKCLymKh93ODIAOGa/hr83Yi6aBCySeUAAw5smtycTSaMsdNo11pH MwO7uk3DcxSAGY+ObpX5mf6w0m7jRVRi9MrZri1uXjINZ81s5W9T5+sFsvppPnnjjgkR JVP6XdvQT6U/WVl+xOUmNP7plOX8FruuJ5zs5GasZ/PpGpM/pyP8RhEoYYhzaD3Uzn0y XXhA== MIME-Version: 1.0 X-Received: by 10.50.36.169 with SMTP id r9mr9900481igj.96.1368132918682; Thu, 09 May 2013 13:55:18 -0700 (PDT) Received: by 10.64.58.97 with HTTP; Thu, 9 May 2013 13:55:18 -0700 (PDT) Date: Thu, 9 May 2013 13:55:18 -0700 Message-ID: From: Dave Taht To: bloat Content-Type: multipart/alternative; boundary=14dae934032b9fb0a704dc4f444e Subject: [Bloat] tcp loss probes in linux 3.10 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, 09 May 2013 20:55:19 -0000 --14dae934032b9fb0a704dc4f444e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable While this appears to make a great deal of sense http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 and just landed in http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id= =3D6ba8a3b19e764b6a65e4030ab0999be50c291e6c I was intrigued by several of the pieces of data that drive this stuff Measurements on Google Web servers show that approximately 70% of retransmissions for Web transfers are sent after the RTO timer expires, while only 30% are handled by fast recovery. Even on servers exclusively serving YouTube videos, RTO based retransmissions, 96% of the timeout episodes occur without any preceding duplicate ACKs or other indication of losses at the sender And especially this, in the context of a post-delay-aware-aqm world. The key takeaway (with TLP) is: the average response time improved up to 7% and the 99th percentile improved by 10%. Nearly all of the improvement for TLP is in the tail latency (post-90th percentile). The varied improvements across services are due to different response-size distributions and traffic patterns. For example, TLP helps the most for Images, as these are served by multiple concurrently active TCP connections which increase the chances of tail segment losses. Application Average 99% Google Web Search -3% -5% Google Maps -5% -10% Google Images -7% -10% TLP also improved performance in mobile networks -- by 7.2% for Web search and Instant and 7.6% for Images transferred over Verizon network. To see why and where the latency improvements are coming from, we measured the retransmission statistics. We broke down the retransmission stats based on nature of retransmission -- timeout retransmission or fast recovery. TLP reduced the number of timeouts by 15% compared to the baseline, i.e. (timeouts_tlp - timeouts_baseline) / timeouts_baseline =3D 15%. Instead, these losses were either recovered via fast recovery or by the loss probe retransmission itself. The largest reduction in timeouts is when the sender is in the Open state in which it receives only insequence ACKs and no duplicate ACKs, likely because of tail losses. Correspondingly, the retransmissions occurring in the slow start phase after RTO reduced by 46% relative to baseline. Note that it is not always possible for TLP to convert 100% of the timeouts into fast recovery episodes because a probe itself may be lost. Also notable in our experiments is a significant decrease in the number of spurious timeouts -- the experiment had 61% fewer congestion window undo events. The Linux TCP sender uses either DSACK or timestamps to determine if retransmissions are spurious and employs techniques for undoing congestion window reductions. We also note that the total number of retransmissions decreased 7% with TLP because of the decrease in spurious retransmissions, and because the TLP probe itself plugs a hole. --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --14dae934032b9fb0a704dc4f444e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable While this appears to make a great deal of sense

http://tools.iet= f.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01

and just lande= d in

http://git.kernel= .org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3D6ba8a3b19e764b6a= 65e4030ab0999be50c291e6c

I was intrigued by several of the pieces of data that drive this stuff<= br>
Measurements on Google Web servers show that appr=
oximately 70% of
   retransmissions for Web transfers are sent after the RTO timer
   expires, while only 30% are handled by fast recovery.  Even on
   servers exclusively serving YouTube videos, RTO based retransmissions,96%
   of the timeout episodes occur without any preceding duplicate ACKs or
   other indication of losses at the sender




And especial=
ly this, in the context of a post-delay-aware-aqm world.



The key takeaway (with TLP) is: the
   average response time improved up to 7% and the 99th percentile
   improved by 10%.  Nearly all of the improvement for TLP is in the
   tail latency (post-90th percentile).  The varied improvements across
   services are due to different response-size distributions and traffic
   patterns.  For example, TLP helps the most for Images, as these are
   served by multiple concurrently active TCP connections which increase
   the chances of tail segment losses.


Application        Average   99%

   Google Web Search  -3%       -5%

   Google Maps        -5%       -10%

   Google Images      -7%       -10%


   TLP also improved performance in mobile networks -- by 7.2% for Web
   search and Instant and 7.6% for Images transferred over Verizon
   network.  To see why and where the latency improvements are coming
   from, we measured the retransmission statistics.  We broke down the
   retransmission stats based on nature of retransmission -- timeout
   retransmission or fast recovery.  TLP reduced the number of timeouts
   by 15% compared to the baseline, i.e. (timeouts_tlp -
   timeouts_baseline) / timeouts_baseline =3D 15%.  Instead, these losses
   were either recovered via fast recovery or by the loss probe
   retransmission itself.  The largest reduction in timeouts is when the
   sender is in the Open state in which it receives only insequence ACKs
   and no duplicate ACKs, likely because of tail losses.
   Correspondingly, the retransmissions occurring in the slow start
   phase after RTO reduced by 46% relative to baseline.  Note that it is
   not always possible for TLP to convert 100% of the timeouts into fast
   recovery episodes because a probe itself may be lost.  Also notable
   in our experiments is a significant decrease in the number of
   spurious timeouts -- the experiment had 61% fewer congestion window
   undo events.  The Linux TCP sender uses either DSACK or timestamps to
   determine if retransmissions are spurious and employs techniques for
   undoing congestion window reductions.  We also note that the total
   number of retransmissions decreased 7% with TLP because of the
   decrease in spurious retransmissions, and because the TLP probe
   itself plugs a hole.
--
Dave T=E4ht

Fixing bufferbloat w= ith cerowrt: http://www.teklibre.com/cerowrt/subscribe.html=20 --14dae934032b9fb0a704dc4f444e--