From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (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 0DDAB21F11C for ; Thu, 9 May 2013 16:01:05 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id u16so6913211iet.28 for ; Thu, 09 May 2013 16:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XtO2TYAvD33CRKL6QliLhd0p3pFa1kzqLJD7LalaLUY=; b=h0uOI6BtyuzlJVrx6D6ONLKf5Dzzbw3O2atRfzKnehhaTmE7fDlYW/5xNuP0v66CFD 2RHRf3Yv3A/dbxPGNMcjqXm2dkYw2p5peQr3rR5YmN8zGyx0Kyv3z7S3omETzQAYQNsJ W0DvGvZgZOy1CKGlxZeoTzU+3WPx4g47V1a7qayJZeZM5hzUPZU76fcmA6qceXxmNmeT 2WW48d6QPHHnHTIxbTnekw4/0VuzKZw7gTC+y/DOkIXdQcy8WVTzPg3aUvGN0uPrn+SN 0Hb8jsSYc3j+EccQt0nmwrgih7tK5pOFgczXG/I7mCZnvsnK5CPz7rPvPwU4IiJfJ4XW BDzg== MIME-Version: 1.0 X-Received: by 10.50.92.4 with SMTP id ci4mr61494igb.96.1368140465241; Thu, 09 May 2013 16:01:05 -0700 (PDT) Received: by 10.64.58.97 with HTTP; Thu, 9 May 2013 16:01:05 -0700 (PDT) In-Reply-To: <20130509213939.GB4170@virgo.local> References: <20130509213939.GB4170@virgo.local> Date: Thu, 9 May 2013 16:01:05 -0700 Message-ID: From: Dave Taht To: Hagen Paul Pfeifer Content-Type: multipart/alternative; boundary=e89a8f3bb2476f046504dc510616 Cc: bloat Subject: Re: [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 23:01:06 -0000 --e89a8f3bb2476f046504dc510616 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, May 9, 2013 at 2:39 PM, Hagen Paul Pfeifer wrote: > * Dave Taht | 2013-05-09 13:55:18 [-0700]: > > >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 o= r > >other indication of losses at the sender > > Btw: Nandita introduced a new MIB entry: LINUX_MIB_TCPLOSSPROBES. > > $ nstat -a | grep TCPLossProbes > > will show fired probes. > > > I have to admit that the 96% figure strongly suggests some degree of bufferbloat in the tested mix here. I am curious however as to what other causes there might be, ranging from tcp bugs to glitches in the matrix? > > Hagen > > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --e89a8f3bb2476f046504dc510616 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, May 9, 2013 at 2:39 PM, Hagen Pa= ul Pfeifer <hagen@jauu.net> wrote:
* Dave Taht | 2013-05-09 13:55:18 [-0700]:

>While this appears to make a great deal of sense
>
>http://tools.ietf.org/html/draft-dukkipati-tcpm-tc= p-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<= br> >
>Measurements on Google Web servers show that approximately 70% of
> =A0 retransmissions for Web transfers are sent after the RTO timer
> =A0 expires, while only 30% are handled by fast recovery. =A0Even on > =A0 servers exclusively serving YouTube videos, RTO based retransmissi= ons,
>
>96% of the timeout episodes occur without any preceding duplicate ACKs = or
>other indication of losses at the sender

Btw: Nandita introduced a new MIB entry: LINUX_MIB_TCPLOSSPROBES.

$ nstat -a | grep TCPLossProbes

will show fired probes.



I have to admit that the 96% figure= strongly suggests some degree of bufferbloat in the tested mix here. I am = curious however as to what other causes there might be, ranging from tcp bu= gs to glitches in the matrix?

Hagen




--
Dave T=E4= ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowr= t/subscribe.html=20 --e89a8f3bb2476f046504dc510616--