[Make-wifi-fast] [Cake] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available

Pete Heist peteheist at gmail.com
Thu Feb 16 11:51:30 EST 2017

> On Feb 16, 2017, at 5:21 PM, Sebastian Moeller <moeller0 at gmx.de> wrote:
>> On Feb 16, 2017, at 17:15, Aaron Wood <woody77 at gmail.com> wrote:
>> The approach that's in all of the Cisco documentation (FWIW) about such things for wired networks is that the higher-priority traffic classes for VoIP and video are also bandwidth limited to a fraction of the total (and less than a majority, at that).  But that's in an environment where you _can_guarantee a minimum level of service.  With the changing throughput rates of wifi, that's a bit harder.
>> But I can certainly see the case being made that the VO and VI queues are never allowed to be over X% of traffic.
> 	I guess the problem is that any station can just decide by itself to just send AC_VO and in a typical home steup the AP will not get a say in that. This is why I propose the AP to escalate its own priority marking to get its packets distributed… In a sense if there are thresholds for permissible VO/VI traffic fractions below which the AP will not escalate its own priority this will come close to throttling the high priority senders, no? 

I thought Aaron’s suggestion sounds both sensible and not difficult to implement. That way we wouldn’t even have to regularly monitor it, and anyone who is marking all their packets thinking they’re doing themselves a favor is just limiting their max throughput.

Could there be another keyword in Cake to do this automatically, say “fairdiffserv", or would this just be feature bloat for what is already a sophisticated shaper? I don’t know if there are sensible mappings from dscp value to max percentage throughput that would work most of the time, or if there could also be an adjustable curve parameter that controls the percentage backoff as you go up dscp levels.

Sebastian, I wasn’t sure what you meant by the AP’s “own packets”, ones that originate from the AP? One thing with might happen if you raise some priorities is there may be an arms race, and also once packets are forwarded to an upstream router with an already elevated priority they might unfairly compete there, but maybe you meant only to treat some packets differently in the AP, not to actually change the value in the DSCP field...


More information about the Make-wifi-fast mailing list