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 DAC8F21F22F; Wed, 10 Jun 2015 13:54:17 -0700 (PDT) Received: from hms-beagle-6.home.lan ([217.237.71.188]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LfkJC-1ZMzOh1Fxy-00pKx1; Wed, 10 Jun 2015 22:54:13 +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: Wed, 10 Jun 2015 22:54:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?windows-1252?Q?Dave_T=E4ht?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:kv2IiwI6Zb5PIKMiURmRVFQixjky+IFGupgNRM8dX8rSvjz+2mo NNc+Mz9y7mE2B2XzEyLBl/6Be/D8VSe2gK/LvAb2esX4A0FoUiqlG8FKT/N1vAVPORJSQkd uCdeDMObHof7HiVf7tXoDnVKZ3Cr1j0WxEkaYX8nMxHRrESeohiNNN6WLlkea/uMlCeY3JP NbsDQC73oJxRpZxD1iQ+Q== X-UI-Out-Filterresults: notjunk:1; Cc: cake@lists.bufferbloat.net, Daniel Havey , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] [Cake] active sensing queue management 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: Wed, 10 Jun 2015 20:54:46 -0000 Hi Dave, On Jun 10, 2015, at 21:53 , Dave Taht wrote: > http://dl.ifip.org/db/conf/networking/networking2015/1570064417.pdf >=20 > gargoyle's qos system follows a similar approach, using htb + sfq, and > a short ttl udp flow. >=20 > Doing this sort of measured, then floating the rate control with > "cake" would be fairly easy (although it tends to be a bit more > compute intensive not being on a fast path) >=20 > What is sort of missing here is trying to figure out which side of the > bottleneck is the bottleneck (up or down). Yeah, they relay on having a reliable packet reflector upstream = of the =93bottleneck=94 so they get their timestamped probe packets = returned. In the paper they used either uplink or downlink traffic so = figuring where the bottleneck was easy at least this is how I interpret = =93Experiments were performed in the upload (data flowing from the users = to the CDNs) as well as in the download direction.". At least this is = what I get from their short description in glossing over the paper. Nice paper, but really not a full solution either. Unless the = ISPs cooperate in supplying stable reflectors powerful enough to support = all downstream customers. But if the ISPs cooperate, I would guess, they = could eradicate downstream buffer bloat to begin with. Or the ISPs could = have the reflector also add its own UTC time stamp which would allow to = dissect the RTT into its constituting one-way delays to detect the = currently bloated direction. (Think ICMP type 13/14 message pairs "on = steroids", with higher resolution than milliseconds, but for buffer = bloat detection ms resolution would probably be sufficient anyways). = Currently, I hear that ISP equipment will not treat ICMP requests with = priority though. Also I am confused what they actually simulated: =93The modems = and CMTS were equipped with ASQM, CoDel and PIE,=94 and =93However, the = problem pop- ularly called bufferbloat can move about among many queues = some of which are resistant to traditional AQM such as Layer 2 MAC = protocols used in cable/DSL links. We call this problem bufferbloat = displacement.=94 seem to be slightly at odds. If modems and CTMS have = decent AQMs all they need to do is not stuff their sub-IP layer = queuesand be done with it. The way I understood the cable labs PIE = story, they intended to do exactly that, so at least the =93buffer = displacement=94 remedy by ASQM reads a bit like a straw man argument. = But as I am a) not of the cs field, and b) only glossed over the paper, = most likely I am missing something important that is clearly in the = paper... Best Regards Sebastian >=20 > --=20 > Dave T=E4ht > What will it take to vastly improve wifi for everyone? > https://plus.google.com/u/0/explore/makewififast > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake