From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eu1sys200aog124.obsmtp.com (eu1sys200aog124.obsmtp.com [207.126.144.157]) (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 055A921F5A7; Fri, 25 Jul 2014 07:27:46 -0700 (PDT) Received: from mail.la.pnsol.com ([89.145.213.110]) (using TLSv1) by eu1sys200aob124.postini.com ([207.126.147.11]) with SMTP ID DSNKU9JpXSMbHmuVvuttCprcNESTqrr5LFos@postini.com; Fri, 25 Jul 2014 14:27:47 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 1XAgTF-0004tD-6Y; Fri, 25 Jul 2014 15:27:41 +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 1XAgTE-0000Ct-QI; Fri, 25 Jul 2014 14:27:41 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Neil Davies In-Reply-To: <66FF8435-C8A5-4596-B43A-EC12D537D49E@gmx.de> Date: Fri, 25 Jul 2014 15:27:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03292B76-5273-4912-BB18-90E95C16A9F5@pnsol.com> <66FF8435-C8A5-4596-B43A-EC12D537D49E@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.1878.6) X-Mailman-Approved-At: Fri, 25 Jul 2014 11:16:23 -0700 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 14:27:48 -0000 Sebastian On 25 Jul 2014, at 15:17, Sebastian Moeller wrote: > 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. 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). I see, as I was replying, Martin has sent you some links to the = background. Cheers Neil=