From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (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 8C97C21F185; Tue, 12 May 2015 09:00:15 -0700 (PDT) Received: by obfe9 with SMTP id e9so9095488obf.1; Tue, 12 May 2015 09:00:05 -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=pVGU3/XsjbfULoORL1L6zOjbJoHSIIfjrRep36oyTt4=; b=zZCNaMQo2vOZeQwmhSj68t0IuX7iq3n827Vp5XO3QXwseDcXLkx0bQ5Px1pd9Kpd5/ SGWtLq3Nmz18Z7FFXh4IPod+oTfgHvltAnmwqebN6giHsI74F43Uab/vndpdwdJzrfso 7dKzAh+73yKGSs678CNkxekW7f9gAE/TJvilRouLIO6qffhucgb2oPa0UJsUDL8RNcbe 1XAEOLSmPi5840p0rnsJ5tQg/1b8egL4b7aD76o9fbofsod7LtHFe5i6KtDqzcUgvvPt OznkG61oRUkz5QgEDBBcVNQZmzqVsXgykxZzJ41xe8oKy/0HYGQ56Zq8eQ3mDcPY95K0 a9Rw== MIME-Version: 1.0 X-Received: by 10.202.216.135 with SMTP id p129mr1687821oig.133.1431446403457; Tue, 12 May 2015 09:00:03 -0700 (PDT) Received: by 10.202.71.139 with HTTP; Tue, 12 May 2015 09:00:03 -0700 (PDT) Date: Tue, 12 May 2015 09:00:03 -0700 Message-ID: From: Dave Taht To: bloat , "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Cerowrt-devel] better business bufferbloat monitoring tools? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 16:01:06 -0000 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 bufferbloat is happening all the time, everywhere. On one of my main sqm'd network gateways, day in, day out, it reports about 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 be much higher, and a great deal of the bloat, drops, etc, has now moved into the wifi APs deeper into the network where I am not monitoring it effectively. I would love to see tools like mrtg, cacti, nagios and smokeping[1] be more closely integrated, with bloat related plugins, and in particular, as things like fq_codel and other ecn enabled aqms deploy, start also tracking congestive events like loss and ecn CE markings on the bandwidth tracking graphs. This would counteract to some extent the classic 5 minute bandwidth summaries everyone looks at, that hide real traffic bursts, latencies and loss at sub 5 minute timescales. mrtg and cacti rely on snmp. While loss statistics are deeply part of snmp, I am not aware of there being a mib for CE events and a quick google search was unrevealing. ? There is also a need for more cross-network monitoring using tools such as that done by this excellent paper. http://www.caida.org/publications/papers/2014/measurement_analysis_internet= _interconnection/measurement_analysis_internet_interconnection.pdf [1] the network monitoring tools market is quite vast and has many commercial applications, like intermapper, forks of nagios, vendor specific producs from cisco, etc, etc. Far too many to list, and so far as I know, none are reporting ECN related stats, nor combining latency and loss with bandwidth graphs. I would love to know if any products, commercial or open source, did.... --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67