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 5108D21F308 for ; Wed, 25 Feb 2015 05:25:23 -0800 (PST) Received: from hms-beagle-2.lan ([134.2.89.70]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LjeWC-1Xp4Hm0rqS-00bZJf; Wed, 25 Feb 2015 14:25:18 +0100 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, 25 Feb 2015 14:25:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1D438EDC-358D-4DD5-9B8D-89182256F66C@gmx.de> References: <201502250806.t1P86o5N011632@bagheera.jungle.bt.co.uk> <4A80D1F9-F4A1-4D14-AC75-958C5A2E8168@gmx.de> <3F47B274-B0E4-44F2-A434-E3C9F7D5D041@ifi.uio.no> <87twyaffv3.fsf@toke.dk> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:H2A51YugGrH3pj70FG2Ll+YxeJmKlp94Cg2ap8UEl7WEnlRiTqN x8i7BuFYeCp80XKe4JhJmWRgUGRNZQ3XBTfiPdQEypprBJbjWw//4kuAifPZMSteRF2Z7Dh 1o1YJvDYSwiyyBX+BtNgV3vwVUcAWfmoL3Sapmwr8d4ozoqsNVuEbRDaeGDkumqw4pPH/qm GsPN3sBOG2HJGtS0V6w/Q== X-UI-Out-Filterresults: notjunk:1; Cc: "bloat@lists.bufferbloat.net" Subject: Re: [Bloat] RED against bufferbloat 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, 25 Feb 2015 13:25:53 -0000 Hallo Mikael, On Feb 25, 2015, at 11:47 , Mikael Abrahamsson wrote: > On Wed, 25 Feb 2015, Toke H=F8iland-J=F8rgensen wrote: >=20 >> While the academic side of me enjoys studying AQMs (and I'm still far = from anything resembling a thorough understanding of them), the = practical "I just want my network to work" side of me has become = increasingly convinced (in part by doing the experiments in the above = mentioned talk) that FQ is more important than AQM in many scenarios. As = such, I think that excluding FQ from the conversation is mostly of, = well, academic interest ;) >=20 > To me, FQ is important especially for lower speeds. This also maps = well into the CPU based nature of FQ (that it's hard to do in = "silicon"). >=20 > We're not going to see FQ_CODEL on a 200 interface large router = designed to push 100 gigabit/s of traffic, at least not in any = interesting price point. >=20 > So one question that I would be interested in understanding is this = scenario: >=20 > INTERNET----AR---CPE--HOST >=20 > Let's now say the AR has a stupid token bucket based policer (which = doesn't queue, just drops packets) rate-limiting the traffic = input/output towards the CPE to, let's say 120 megabit/s averaged with 1 = second worth of burst bytes (because the ISP wants to make sure the = customer can speed-test to 100 megabit/s of TCP throughput). >=20 > Can we do bidirectional traffic FQ_CODEL on the CPE to try to achieve = basically zero loss in the AR policer for any normal kind of use = scenario using TCP. I have not seen any simulations looking at this. Yes, we can. Openwrt=92s qos-scripts and cerowrt=92s sqm-scripts = allow exactly that. But we really could need some help from the station = on the other end of the bottleneck-link, so either a cmts or a dslam = (what ever these are called today). The shaper for the ingress link to = the CPE is best positioned in front of the boot;neck instead of behind = it in the CPE (in the CPE we need to sacrifice more bandwidth and in = case of a sudden inrush of packets ill still see more AR policer action = than we would like). The only argument for ingress shaping on the CPE is that this = allows the end user to define her own QOS criteria independent of the = ISPs wishes. Best of both worlds would be user configurable QOS-shaping = on the slam/bras/whatever=85 Best Regards Sebastian >=20 > What about 12 megabit/s policer to a 10 megabit/s service? What about = a 12 megabit/s FIFO shaper (that would actually delay packets, but = because it's FIFO we just rarely want to see buffering there). >=20 > Because my belief is that even though we might say we love FQ here, = we're not going to see high speed FQ on higher end ISP aggregation = routers. So if we want FQ, we're going to have to do it in the CPEs. >=20 > I am using terminology that is explained in this article: > = http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-polic= ing/19645-policevsshape.html >=20 > --=20 > Mikael Abrahamsson email: = swmike@swm.pp.se_______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat