From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f99.google.com (mail-la0-f99.google.com [209.85.215.99]) (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 CEA4721F1F5 for ; Tue, 28 Apr 2015 00:14:45 -0700 (PDT) Received: by lamq1 with SMTP id q1so2702298lam.1 for ; Tue, 28 Apr 2015 00:14:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=OXDHM+ibr15wRoOmfWyCbKqL9bQHXJ6tnTuW5WbWoSE=; b=acBf/BgqSJnimiM06N35agSzrrBskkCXWKJsQZ7MigTsBGVrWpwzV9emw5hOZKnRS+ IJkBKbnQ6KRXlNXM1aDPVs+3WC0GS5giR7cV4F8uy9mT2VkqO2pYub6cmBcL8a/eeyLE X58FO5JbbmefnVMpvouaLUsMaeyR9YaDOC43dGSh2jdjeaQJZitSR2oXklI76ic+cKhn En42iIlKT5vdVkH3sxJHRyDdHYpPeaak/ZvGMGP4TRZya1RBPURvpCQHSUIg+gj7sb6g 4YSWXDOJlMk3X1n431pjh5rwV8P5mEuI6Qm1wuWY99diiP+09CDzv2DUtS+JpTjNi5+D OuvQ== X-Gm-Message-State: ALoCoQlW5H8WpQmuAHUUvm4BYElOrfSs8+G8Qc7gjFihzRMfp9aQUCnj9DoOHFpCgNcMEwTbd/F8CMKty3eP/jaHvSRJ97MqOw== X-Received: by 10.180.99.39 with SMTP id en7mr27304915wib.31.1430205282888; Tue, 28 Apr 2015 00:14:42 -0700 (PDT) Received: from mail.la.pnsol.com (eu1sys200aog110.obsmtp.com. [207.126.144.129]) by mx.google.com with SMTPS id s3sm508084wiz.1.2015.04.28.00.14.41 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 28 Apr 2015 00:14:42 -0700 (PDT) X-Relaying-Domain: pnsol.com Received: from mail.la.pnsol.com ([89.145.213.110]) (using TLSv1) by eu1sys200aob110.postini.com ([207.126.147.11]) with SMTP ID DSNKVT8zYWiSl/vCb7CYkzBcYzIOWS5j5a8h@postini.com; Tue, 28 Apr 2015 07:14:42 UTC Received: from git.pnsol.com ([172.20.5.238] helo=roam.smtp.pnsol.com) by mail.la.pnsol.com with esmtp (Exim 4.76) (envelope-from ) id 1Ymzj3-0004rM-8E; Tue, 28 Apr 2015 08:14:37 +0100 Received: from [172.20.5.109] by roam.smtp.pnsol.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Ymzit-0000C3-08; Tue, 28 Apr 2015 07:14:27 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Neil Davies In-Reply-To: <87fv7li76c.fsf@toke.dk> Date: Tue, 28 Apr 2015 08:14:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <72DB0260-F0DF-426F-A3F3-ECF5D8AF228F@pnsol.com> <877fsx3l5a.fsf@toke.dk> <874mo11sdf.fsf@toke.dk> <87fv7li76c.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.1878.6) Cc: bloat Subject: Re: [Bloat] Detecting bufferbloat from outside a node 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, 28 Apr 2015 07:15:14 -0000 On 27 Apr 2015, at 22:37, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: > Neil Davies writes: >=20 > ....... >> One of my adages is that "network quality" doesn' t exist - just like >> you can't buy a box of "dark" and make a room dark by opening the = box, >> you can't buy a box of "network quality" - delivering quality in >> networks is managing (through bounding) the "quality attenuation" >=20 > That much seems obvious. But do you have any analytical models that = can > actual predict the magnitude of the quality attenuation for a given > network, say? And if so, are they available somewhere? Yes, we have models for various network elements (see Lucian's thesis for the stuff at CERN for example - see website) and the rest we = can ascertain by measurement. The problem with a generic model is that is configuration dependent, you = can=20 estimate the overall =E2=88=86Q|V (as a starting point) using existing = queueing theory.=20 The issue is then how such V is distributed on various timescales (see = below). We measure and model this stuff commercially, and customers tend to be = very sensitive about such metrics! We do have a technical report that = provides a lot more background for a specific deployment (funded by a public = body) that has been accepted for publication and should be published soon. >=20 > Also, some of the documents linked to from your web site seems to = allude > to a scheduling algorithm of some sort. Is that available in paper = form > (or better, code!) anywhere? Toke, once you accept that =E2=88=86Q exists and is conserved then the = only role of=20 queueing and scheduling is to "share out the disappointment" (i.e assign = =E2=88=86Q|V to the set of competing streams/flows/aggregates). Yes there is better code (and better approaches, see the patents) but = we've found that the key issue is creating the configurations. Given =E2=88=86Q|V's = conservation and that network elements are overbooked (and they are definitely more = overbooked in=20 the desire for low loss and and consistent low latency than they are for = capacity) the question becomes "what is the overall desired outcome as the network = element reaches saturation" - we can tailor that to any (feasible) collection of = desires - now get people to express, in any way that can be quantified, those desires! The "code" consists of a collection "quality attenuators" - like = cherish/urgency multiplexers, stochastic shaper/policers arranged in an acyclic graph = (all in the=20 patent disclosures) - that make up the data path. Associated with that = is=20 the configuration system: given a set of QTAs - "quantities of quality = required (bounds=20 on =E2=88=86Q) and precedence for breach during saturation" - it = constructs a configuration=20 (if one exists) that fulfils that set of requirements - also returning = probabilistic measures of the extent to which individual QTAs are likely not to be fulfilled. >=20 >=20 > Thanks for your answers, will also take a look at the paper you linked > in your other email. :) >=20 > -Toke Neil