From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 CA04B21F2EF for ; Sun, 12 Apr 2015 16:50:32 -0700 (PDT) Received: from hms-beagle.home.lan ([87.164.165.7]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LaKaw-1Z6N4t3ByI-00m2Of; Mon, 13 Apr 2015 01:50:29 +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: Mon, 13 Apr 2015 01:50:29 +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:CGLvJt/jzT0Y60K8ybv7nVkRK08uzU8ROMNHZt5gg7k4eSTfUqf H/yEiQUrPM72vOwals02wtU8aBwqDz4Cfi0VEfP6aVUWeJq+bH1dLKiBTi+LJY12kLi7b4k 3THGYo9juhaCrKAh1H7KnBr4kvYN94pKoYbDnFfkqSD1taTsAQpXVGv2kVca8VdopxO94WO ZTY11NamDuMXA4oGImuXA== X-UI-Out-Filterresults: notjunk:1; Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] #17 X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 23:51:01 -0000 Hi Dave, On Apr 12, 2015, at 23:59 , Dave Taht wrote: > It is not clear if atm framing and things like pppoe are used at > higher rates on newer technologies like GPON and fiber. To be clear ATM is currently still a legacy tech, used where = deployed, but not actively rolled out anymore. But unfortunately, ATM is = still used between DSLAM and Modems if the modems run either ADSL1, = ADSL2, or ADSL2+, since even in modern FTC dslams far away customers = fall back to ADSL2+, so dropping ATM and per packet overhead support = might not be the best idea. (But note as long as cake can be combined = successfully with tc=92s stab option all users should be fine, = especially, IIRC as ADSL2+ tops out at around 20Mbps/3Mbps). PPPoE on the other hand is still used on DTAG=92s (current) FTTH = roll-out. > They are not > used in cablemodems, for example. But as far as I can tell almost everywhere else = (ADSL/VDSL/Fiber) at least by some of the ISPs supporting such = technologies. > Given the headache it has been to > get that straightened out on DSL AND detect AND configure properly, I > would not mind if we abandoned the idea of supporting alternate > framings in cake, and stuck with what already works in the sqm-scripts > with htb + fq_codel. As far as I can tell most there techs just need a = per-packet-overhead option (the kernel already tries to account for some = overhead so the machinery is in place, we just need to expose it); ATM = is mainly weird due to its insistence on padding out the last =93cell=94 = for each packet individually. As mentioned above, as long as cake can = work with tc=92s stab option all framing and overhead handling should be = available to whoever needs it. (I note that stab will need some love for = GRO packets). I would vote for exposing ATM framing and per packet overhead in = cake to keep with the one-stop-shopping idea of its design (since enough = people will be forced to live with ATM for the foreseeable future). Best Regards Sebastian >=20 >=20 >=20 > On Sun, Apr 12, 2015 at 12:18 PM, Sebastian Moeller = wrote: >> Hi list, hi Dave >>=20 >> On Sat Apr 11 19:33:59 PDT 2015, Dave That = wrote: >> 17) the atm compensation in cake is entirely untested. And it is >> unclear as to how best handle pppoe. >>=20 >> Regarding ATM, it seems from = http://www.bufferbloat.net/projects/codel/wiki/Cake that there is only = one command line argument =93atm=94 to activate accounting for atm = encapsulation. I venture a guess that this will not be sufficient as it = seems necessary to add the per packet overhead before =93expanding=94 = the packet size to the 43 in 53 atm cells. This might be really just a = documentation issue (I have not looked agh cake=92s code, not that I a) = read C well and b) know where to find the cake code repository). In my = experience the relevant per packet overhead on the ATM link needs to be = measured on each link individually (and repeatedly to catch the ISPs = doing funny things like adding an otherwise invisible vlan tag on the = atm link). >>=20 >> PPPoE, is easy, either drill into the packets to get the values used = for hashing, or ask people to activate cake on the pppoe interfaces in = the router (these typically do not show the pppoe headers so that = classifier will find the right values). Or you could argue that a PPPoE = link really is just one flow, and hence does not deserve special = treatment ;) (which other =93multiplexors=94 would deserve the same = special treatment SPDY/HTTP2?). >>=20 >> Best Regards >> Sebastian >>=20 >>=20 >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake >=20 >=20 >=20 > --=20 > Dave T=E4ht > Open Networking needs **Open Source Hardware** >=20 > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67