[Cake] #17

[Sebastian Moeller]

Hi Dave,


On Apr 12, 2015, at 23:59 , Dave Taht <dave.taht at gmail.com> 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’s 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’s (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 “cell” for each packet individually. As mentioned above, as long as cake can work with tc’s 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


> 
> 
> 
> On Sun, Apr 12, 2015 at 12:18 PM, Sebastian Moeller <moeller0 at gmx.de> wrote:
>> Hi list, hi Dave
>> 
>> On Sat Apr 11 19:33:59 PDT 2015, Dave That <dave.taht at gmail.com> wrote:
>> 17)  the atm compensation in cake is entirely untested. And it is
>> unclear as to how best handle pppoe.
>> 
>> Regarding ATM, it seems from http://www.bufferbloat.net/projects/codel/wiki/Cake that there is only one command line argument “atm” 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 “expanding” the packet size to the 43 in 53 atm cells. This might be really just a documentation issue (I have not looked agh cake’s 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).
>> 
>> 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 “multiplexors” would deserve the same special treatment SPDY/HTTP2?).
>> 
>> Best Regards
>>        Sebastian
>> 
>> 
>> _______________________________________________
>> Cake mailing list
>> Cake at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
> 
> 
> 
> -- 
> Dave Täht
> Open Networking needs **Open Source Hardware**
> 
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67