From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from post.qlsys.ca (ns1.quicklaw.com [192.139.142.99]) (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 E15EB200B1B for ; Wed, 14 Sep 2011 08:17:44 -0700 (PDT) Received: from lngcanexcp002.legal.regn.net ([192.139.142.50]) by post.qlsys.ca (8.13.1/8.13.1) with ESMTP id p8EFHegP004690; Wed, 14 Sep 2011 11:17:41 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 14 Sep 2011 11:17:55 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Hmmn, this is in part a capacity planning/management problem. Thread-Index: Acxy8XpQ4YzWyw3mTE6niMo+E7xqXg== From: "Collier-Brown, David (LNG-CAN)" To: X-Mailman-Approved-At: Tue, 20 Sep 2011 08:45:48 -0700 Cc: "Collier-Brown, David \(LNG-CAN\)" , davecb@spamcop.net Subject: [Bloat] Hmmn, this is in part a capacity planning/management problem. 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, 14 Sep 2011 15:17:45 -0000 I was reading the latest article in LWN, and commented there, but part of the comment may be relevant to the list... -- reply to mlankhorst (subscriber, #52260) -- Changing the subject slightly, there's a subtle, underlying problem in that when developing products and protocols, we tend to work with what's easy, not what's important. We work with the bandwidth/delay product because it's what we needed in the short run, and we probably couldn't predict we'd need something more at the time. We work with buffer sizes because that's dead easy. What we need instead is to work in the delay, latency and/or service time of the various components. It's easy to deal with performance problems that are stated in time units and are fixed by varying the times things take. It's insanely hard to deal with performance problems when all we know is a volume in bytes. It's a bit like measuring the performance of large versus small cargo containers when you don't know if they're on a truck, a train or a ship! If you expose any time-based metrics or tuneables in your investigation, please highlight them. Anything that looks like delay or latency would be seriously cool. One needs very little to analyze this class of problems. Knowing the service time of a packet, the number of packets, and the time between packets is sufficient to build a tiny little mathematical model of the thing you measured. From the model you can then predict what happens when you improve or disimprove the system. More information allows for more predictive models, of course, and eventually to my mathie friends becoming completely unintelligible (;-)) --dave (davecb@spamcop.net) c-b -- As you might guess, I'm a capacity planner, and might be able to help a bit on the modeling side. Besides, I'm looking for a networking example for my next book (;-)) --dave