From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (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 894B321F2DF; Wed, 13 May 2015 06:36:47 -0700 (PDT) Received: by obblk2 with SMTP id lk2so29718283obb.0; Wed, 13 May 2015 06:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JBomkqtnX8Tf/cs99zLpMS2P28wFuRDq0YYZZv2d1zI=; b=qPBIpgSw/yjWAWxkj9YNijLF891KX4sJC/zRrnA5LxNP1nXiyf+7OTVHAZjPnpX536 /UQCHuebk5PIYV70rqE/A/0Am8HIAjfpu5xB9yYoh2h1nSbinx7jKD8PrTCuX4WoSFvS b33YUz35r1py7bFm+i4UfEzP7wrPtaBPaCrGlOWVF4uK1fN7VTi0q4UZv2HQmdRHoqSQ dhx/fA3077gGDhkt19wWyORh8HctaCLtVKQNuZkgX3b73pacJPMeOSTLJ3vu9lPeYR37 TJrFhMzOx7Nffdm0+WLwx7a2e8LgMNTfq9f6CYAgemgJVmL8NliRBVoaR5Vy8tgeO02h t/kA== MIME-Version: 1.0 X-Received: by 10.202.223.131 with SMTP id w125mr15057722oig.108.1431524207065; Wed, 13 May 2015 06:36:47 -0700 (PDT) Received: by 10.202.71.139 with HTTP; Wed, 13 May 2015 06:36:46 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 May 2015 06:36:46 -0700 Message-ID: From: Dave Taht To: "Bill Ver Steeg (versteb)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Bloat] better business bufferbloat monitoring tools? 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: Wed, 13 May 2015 13:37:17 -0000 On Wed, May 13, 2015 at 6:20 AM, Bill Ver Steeg (versteb) wrote: > Time scales are important. Any time you use TCP to send a moderately larg= e file, you drive the link into congestion. Sometimes this is for a few mil= liseconds per hour and sometimes this is for 10s of minutes per hour. > > For instance, watching a 3 Mbps video (Netflix/YouTube/whatever) on a 4 M= bps link with no cross traffic can cause significant bloat, particularly on= older tail drop middleboxes. The host code does an HTTP get every N secon= ds, and drives the link as hard as it can until it gets the video chunk. It= waits a second or two and then does it again. Rinse and Repeat. You end up= with a very characteristic delay plot. The bloat starts at 0, builds until= the middlebox provides congestion feedback, then sawtooths around at about= the buffer size. When the burst ends, the middlebox burns down its buffer = and bloat goes back to zero. Wait a second or two and do it again. The dslreports tests are opening 8 or more full rate streams at once. Not pretty results. Web browsers expend most of their flows entirely in slow start. Etc. I am very concerned with what 4k streaming looks like, and just got an amazon box to take a look at it. (but have not put out the cash for a suitable monitor) > You can't fix this by adding bandwidth to the link. The endpoint's TCP se= ssions will simply ramp up to fill the link. You will shorten the congested= phase of the cycle, but TCP will ALWAYS FILL THE LINK (given enough time t= o ramp up) It is important to keep stressing this point as the memes propagate outward= s. > > The new AQM (and FQ_AQM) algorithms do a much better job of controlling t= he oscillatory bloat, but you can still see ABR video patterns in the delay= figures. It has generally been my hope that most of the big movie streaming folk have moved to some form of pacing by now but have no data on it. (?) Certainly I'm happy with what I saw of quic and have hope that http/2 will cut the number of simultaneous flows in progress. But I return to my original point in that I would like to continue to find more ways to make the sub 5 minute behaviors visible and comprehensible to more people... > Bvs > > > -----Original Message----- > From: bloat-bounces@lists.bufferbloat.net [mailto:bloat-bounces@lists.buf= ferbloat.net] On Behalf Of Dave Taht > Sent: Tuesday, May 12, 2015 12:00 PM > To: bloat; cerowrt-devel@lists.bufferbloat.net > Subject: [Bloat] better business bufferbloat monitoring tools? > > One thread bothering me on dslreports.com is that some folk seem to think= you only get bufferbloat if you stress test the network, where transient b= ufferbloat is happening all the time, everywhere. > > On one of my main sqm'd network gateways, day in, day out, it reports abo= ut 6000 drops or ecn marks on ingress, and about 300 on egress. > Before I doubled the bandwidth that main box got, the drop rate used to b= e much higher, and a great deal of the bloat, drops, etc, has now moved int= o the wifi APs deeper into the network where I am not monitoring it effecti= vely. > > I would love to see tools like mrtg, cacti, nagios and smokeping[1] be mo= re closely integrated, with bloat related plugins, and in particular, as th= ings like fq_codel and other ecn enabled aqms deploy, start also tracking c= ongestive events like loss and ecn CE markings on the bandwidth tracking gr= aphs. > > This would counteract to some extent the classic 5 minute bandwidth summa= ries everyone looks at, that hide real traffic bursts, latencies and loss a= t sub 5 minute timescales. > > mrtg and cacti rely on snmp. While loss statistics are deeply part of snm= p, I am not aware of there being a mib for CE events and a quick google sea= rch was unrevealing. ? > > There is also a need for more cross-network monitoring using tools such a= s that done by this excellent paper. > > http://www.caida.org/publications/papers/2014/measurement_analysis_intern= et_interconnection/measurement_analysis_internet_interconnection.pdf > > [1] the network monitoring tools market is quite vast and has many commer= cial applications, like intermapper, forks of nagios, vendor specific produ= cs from cisco, etc, etc. Far too many to list, and so far as I know, none a= re reporting ECN related stats, nor combining latency and loss with bandwid= th graphs. I would love to know if any products, commercial or open source,= did.... > > -- > Dave T=C3=A4ht > Open Networking needs **Open Source Hardware** > > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67