From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) (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 E0B7621F0B3 for ; Thu, 21 Mar 2013 11:28:20 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id k14so3501697oag.11 for ; Thu, 21 Mar 2013 11:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=y+AY1Z4ZyLUWLDyQHRYTCQJWyyYCue2ocLsQnuySEOI=; b=mZLrGZpElScNbgzCYIjxxgQVCbcSxJZbOUBTf0q1boozrage1UKw3HE4ZXDqZBYTSs 77tLSzPLg7Xdjc2caqqwlxX4ypRpv4CeCwORKLdev7FyuBQrE5W3eKsC1BLM+9bDsshZ NcjrC2WPOjGMPlftp9lWaIiC3puzY2C7/9Kz2Ll6mHbF0LfSC2sQ3ElmoL9+0IU0MEpt ouPxWKTaakCPr1WDHNWgxAIZDrAqdKSf5GmW7JT1lcYWFi45qCEL4fF1OcEOBmLA7Qjd wOPq31+OK+sq4Ln674gGY85MPtWerxnif4emrEOipK6G/v9+ZAtjyx/Y9g9/3Hsi8Du8 8nKA== MIME-Version: 1.0 X-Received: by 10.182.2.132 with SMTP id 4mr7637045obu.42.1363890499974; Thu, 21 Mar 2013 11:28:19 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.22.193 with HTTP; Thu, 21 Mar 2013 11:28:19 -0700 (PDT) In-Reply-To: <514B4DEB.3020402@net.t-labs.tu-berlin.de> References: <51408BF4.7090304@cisco.com> <8C48B86A895913448548E6D15DA7553B7D020F@xmb-rcd-x09.cisco.com> <514B484F.2070902@net.t-labs.tu-berlin.de> <514B4DEB.3020402@net.t-labs.tu-berlin.de> Date: Thu, 21 Mar 2013 14:28:19 -0400 X-Google-Sender-Auth: kBAY8P1-QQyFhHUyOH2xcUgs7eM Message-ID: From: Jim Gettys To: Oliver Hohlfeld Content-Type: multipart/alternative; boundary=f46d044519d9c37e3d04d87380f7 Cc: "tsvwg@ietf.org" , bloat Subject: Re: [Bloat] [tsvwg] how much of a problem is buffer bloat today? 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, 21 Mar 2013 18:28:21 -0000 --f46d044519d9c37e3d04d87380f7 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 21, 2013 at 2:14 PM, Oliver Hohlfeld < oliver@net.t-labs.tu-berlin.de> wrote: > > I believe you are actually measuring the *fraction of the time* your > > measurements show bad latency > > Yes. > > > The best data I've seen on how widespread the problem is is the ICSI > > Netalyzr scatter plots results > > One has to be extremely careful on what to conclude from this data. > The Netalyzr data shows that bloated buffers _exist_, not that they > are _used_ in practice. Or as Mark has put it: "[it] shows that large > delays due to buffering can happen, not that they do happen." > Empirical evidence cited in my previous mail suggests that buffer > bloat does not happen often. > Heh. 6% of the time isn't "often"? The measurements is much more a measurement of how much of the time your competing with someone else (or yourself in background) for the bottleneck than anything else. Start up any long lived TCP connection (using a modern TCP; that leaves out Windows XP). Stand back a few seconds. Measure latency. Think uploading/downloading files/videos, or sending email with images attached, etc. More insidious is what visiting a web page with lots of embedded images can do. The cross product of: 1) current web browsers using many more than 2 TCP connections. 2) web site "sharding". 3) the initial window of data in those TCP connections. This causes transients of what is up to hundreds of milliseconds of head of line blocking even on very high speed broadband/wifi connections. Again, I encourage you to do this measurement on your own broadband connection, by visiting any image heavy web site and running ping.... > > > I encourage everyone to run netalyzr and/or the mlabs tests for > > bufferbloat on your own broadband connections, or do simple copy and > > ping tests inside your own house over wifi to your local file servers.... > > While this will identify bloated buffers, it does not help in answering > what fraction of Internet users actually experience the problem. > We've not come across any broadband equipment buffered "correctly". If thought is given at all to buffering, it's been sized to the maximum buffering the device might ever need for a single TCP flow at its maximum bandwidth. Example, plug a current DOCSIS 3 modem (capable up to 300Mbps these days) and use it at 20Mbps; unless the buffersizing amendment has been turned on (no ISP I am aware of yet does so), you'll be overbuffered by a factor of 15. And all the operating systems have problems, to one degree or another (and as they are all adjacent to wireless links these days, they also contribute to the problem. Bufferbloat just waits in hiding to get you when you try to use the network. - Jim > Oliver _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --f46d044519d9c37e3d04d87380f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu= , Mar 21, 2013 at 2:14 PM, Oliver Hohlfeld <oliver@net.t-labs= .tu-berlin.de> wrote:
> I believe you are act= ually measuring the *fraction of the time* your
> measurements show bad latency

Yes.

> The best data I've seen on how widespread the problem is is the IC= SI
> Netalyzr scatter plots results

One has to be extremely careful on what to conclude from this data. The Netalyzr data shows that bloated buffers _exist_, not that they
are _used_ in practice. Or as Mark has put it: "[it] shows that large<= br> delays due to buffering can happen, not that they do happen."
Empirical evidence cited in my previous mail suggests that buffer
bloat does not happen often.

Heh. =A0

6% of the time isn't "often"? =A0The measurements is much mor= e a measurement of how much of the time your competing with someone else (o= r yourself in background) for the bottleneck than anything else.

Start up a= ny long lived TCP connection (using a modern TCP; that leaves out Windows X= P).

<= div style=3D"font-size:small" class=3D"gmail_default"> Stand back a few seconds.

Measure latency.

Think uploading/down= loading files/videos, or sending email with images attached, etc.


More insid= ious is what visiting a web page with lots of embedded images can do.
=

The cross product of:
=A0 =A01) current web browsers using many more than 2 TCP connection= s.
=A0 =A02) we= b site "sharding".
=A0 =A03) the initia= l window of data in those TCP connections.

This causes transients of what is up to hundreds of milliseconds of head of= line blocking even
on very high speed broadband/wifi connections. =A0Again, I encourage y= ou to do this measurement on your own broadband connection, by visiting any= image heavy web site and running ping....


> I encourage everyone to run netalyzr and/or the mlabs tests for
> bufferbloat on your own broadband connections, or do simple copy and > ping tests inside your own house over wifi to your local file servers.= ...

While this will identify bloated buffers, it does not help in answeri= ng
what fraction of Internet users actually experience the problem.

We've not come across any broadband equipment buffered "correctly= ". =A0If thought is given at all to buffering, it's been sized to = the maximum buffering the device might ever need for a single TCP flow at i= ts maximum bandwidth. =A0Example, plug a current DOCSIS 3 modem (capable up= to 300Mbps these days) and use it at 20Mbps; unless the buffersizing amend= ment has been turned on (no ISP I am aware of yet does so), you'll be o= verbuffered by a factor of 15.

And all the operating systems = have problems, to one degree or another (and as they are all adjacent to wi= reless links these days, they also contribute to the problem.

Bufferbloat just waits in hidi= ng to get you when you try to use the network.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 - Jim

=

Oliver=A0
_____________________= __________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/bloat

--f46d044519d9c37e3d04d87380f7--