From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx12.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D580221F170 for ; Tue, 26 Mar 2013 10:49:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,913,1355126400"; d="scan'208";a="34224530" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 26 Mar 2013 10:49:50 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2QHnoef006408; Tue, 26 Mar 2013 10:49:50 -0700 (PDT) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht03-prd.hq.netapp.com (10.106.76.241) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 26 Mar 2013 10:49:50 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0342.003; Tue, 26 Mar 2013 10:49:49 -0700 From: "Scheffenegger, Richard" To: Mirja Kuehlewind , "aqm@ietf.org" Thread-Topic: [tsvwg] [aqm] [Bloat] how much of a problem is buffer bloat today? Thread-Index: AQHOKkb4bz1RAbJaNkyIcjxYVOA1Q5i4PtEA Date: Tue, 26 Mar 2013 17:49:49 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24ACFA86@SACEXCMBX02-PRD.hq.netapp.com> References: <51408BF4.7090304@cisco.com> <201303261825.47601.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201303261825.47601.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 26 Mar 2013 12:18:08 -0700 Cc: "tsvwg@ietf.org" , bloat Subject: Re: [Bloat] [tsvwg] [aqm] 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: Tue, 26 Mar 2013 17:49:52 -0000 Hmm... TCP measures RTT;=20 one could create a global histogram of all measured RTTs by TCP (whenever a= valid measurement is taken), and export that with "netstat -sp tcp"... Of = course, vastly different paths would be gobbled up together, but when inves= tigating specific paths, that should be good enough as a high level startin= g point. Richard Scheffenegger > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Mirja Kuehlewind > Sent: Dienstag, 26. M=E4rz 2013 18:26 > To: aqm@ietf.org > Cc: bloat; tsvwg@ietf.org > Subject: Re: [tsvwg] [aqm] [Bloat] how much of a problem is buffer bloat > today? >=20 > Hi, >=20 > +1. Would be nice to have such statictics available for the user in every > OS! >=20 > Mirja >=20 >=20 > On Friday 22 March 2013 05:27:31 Mikael Abrahamsson wrote: > > On Thu, 21 Mar 2013, Jim Gettys wrote: > > > Every more modern TCP can easily fill any sized buffer given time > > > with a single TCP connection. > > > > I agree with this, I made this discovery myself back in 2004 or so, > > and had to implement Fairqueue and WRED on my home connection to make > > it bearable to use any interactive application while transferring files= . > > > > In IETF75 in Stockholm in 2009, I made proposals in both TCP and at > > open mic in one of the sessions, that I would like to see statistics > > and performance numbers on packet loss, delay variation etc from > > actual traffic. The IP stack has great insight in what the network > > conditions are (especially with TCP Timestamping), but as far as I > > know it's not really exported in any usable format to the user. My > > idea was to have some kind of dashboard for the user to show if > > currently the network was the limiting factor, if the tcp window was > > maxed out etc. Would also be nice if there was output that could be > > cut/pasted and attached to a fault report in case the customer talks > > to customer support. It would be good if this was actually a standard s= o > all OSes did the same. > > > > I am not aware of any such work going on, so I'd like to know if > > anyone else is aware of work in this area? >=20 >=20 >=20 > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart >=20 > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > -------------------------------------------------------------------