From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C4DEF21F5DB for ; Fri, 25 Jul 2014 09:02:59 -0700 (PDT) Received: from hms-beagle.lan ([134.2.89.70]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LrevR-1WWJ0Z1v0H-013KAL; Fri, 25 Jul 2014 18:02:48 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 25 Jul 2014 18:02:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03292B76-5273-4912-BB18-90E95C16A9F5@pnsol.com> <66FF8435-C8A5-4596-B43A-EC12D537D49E@gmx.de> To: Neil Davies X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:nH8I2nlGc/el3zcLjEl479075oWpfeWZPfsyeiQqie2i6m/Gi1d kLsfgpXyqvA5KGAp71NVM8A4dDC275KhXKKV42oW0mOSbmGgIYM6A77ynpTDEC+/XLy+BpF JaPs5vqEx0gKyQIdgz615/QoS1b1LOgvN3hhFilJu9DcEMm8Ri1hDVmKHlME+L3oVwK0znO q9KTbiaC76V4nBFwgGbbA== Cc: cerowrt-devel , bloat Subject: Re: [Cerowrt-devel] [Bloat] Check out www.speedof.me - no Flash 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: Fri, 25 Jul 2014 16:03:02 -0000 Hi Neil, On Jul 25, 2014, at 16:27 , Neil Davies wrote: > Sebastian >=20 > On 25 Jul 2014, at 15:17, Sebastian Moeller wrote: >=20 >> But how do you propose to measure the (bottleneck) link capacity = then? It turns out for current CPE and CMTS/DSLAM equipment one = typically can not relay on good QoE out of the box, since typically = these devices do not use their (largish) buffers wisely. Instead the = current remedy is to take back control over the bottleneck link by = shaping the actually sent traffic to stay below the hardware link = capacity thereby avoiding feeling the consequences of the = over-buffering. But to do this is is quite helpful to get an educated = guess what the bottleneck links capacity actually is. And for that = purpose a speediest seems useful. >=20 >=20 > I totally agree that what you are trying to do is to take control = "back" for the upstream delay and loss (which is the network level = activity that directly influences QoE). Observationally the = "constraining link" is the point at which the delay and loss start to = grow as the the offered load is increased (there are interesting = interactions with the scheduling in the CMTS/3GPP node B - but they are = tractable) if we don't have direct access to the constraint (which in = the CPE, for ADSL you have) we track that "quality attenuation" = inflection point. Saturating the path is a bit of a sledgehammer (and = has nasty cost/scaling implications). What else can I do to make sure that my network still works = satisfactory in the =93worst case=94 than to test and tune it for the = worst case? Also, coming from a biology background, I like systems that = operate well in the capacity limited state ;) >=20 > I see, as I was replying, Martin has sent you some links to the = background. Interesting read, do you have a pointer on how to calculate = deltaQ though? best regards Sebastian >=20 > Cheers >=20 > Neil