moeller0 at gmx.de
Sun Apr 12 15:18:00 EDT 2015
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?).
More information about the Cake