From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id B86A720016C for ; Tue, 8 Jan 2013 08:40:30 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r08GeQTF015063; Tue, 8 Jan 2013 08:40:26 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 367FC5AAAAC; Tue, 8 Jan 2013 11:40:26 -0500 (EST) To: dpreed@reed.com From: Mark Allman In-Reply-To: <1357658975.013413296@apps.rackspace.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Touch, Peel and Stand MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma19450-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 08 Jan 2013 11:40:26 -0500 Sender: mallman@icir.org Message-Id: <20130108164026.367FC5AAAAC@lawyers.icir.org> Cc: Ingemar Johansson S , Keith Winstein , "end2end-interest@postel.org" , "bloat@lists.bufferbloat.net" Subject: Re: [Bloat] [e2e] bufferbloat paper X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: mallman@icir.org List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 16:40:30 -0000 ----------ma19450-1 Content-Type: text/plain Content-Disposition: inline David- I completely agree with your "measure it" notion. That is one of the points of my paper. > First, it's important to measure the "right thing" - which in this > case is "how much queueing *delay* builds up in the bottleneck link > under load" That said, as often is the case there is no "right thing", but rather a number of "right thingS" to measure. And/or, when you go off to measure the "right thing" there are additional facets that come to light that one must understand. Certainly understanding how much possible delay can build up in a queue is a worthwhile thing to measure. There are good results of this in the netalyzr paper. Further, as Injong mentioned there are results of this potential queue buildup from mobile networks in his recent IMC paper. However, the point of my contribution is that if this queue buildup happens only in the middle of the night on the second Sunday of every leap year for 1.5sec, that'd be good to know and probably it'd make the behavior something to not specifically engineer around in a best effort network. So, then, lets ask about the scale and scope of this behavior and answer it with systematic, empirical assessment instead of anecdotes and extrapolation. Surely that is not a controversial position. My results are modest at best. Other people have different (probably better) vantage points. They should look at some data, too. allman ----------ma19450-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlDsS/oACgkQWyrrWs4yIs5ljACbB6P6KTpE1z8vMJZk8iA1TtND kVMAnjAWTiN53tXIZN8gmI8aivFa4hHB =LKlY -----END PGP SIGNATURE----- ----------ma19450-1--