> On Feb 16, 2017, at 17:15, Aaron Wood <wood...@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? Best Regards > > -Aaron > > On Thu, Feb 16, 2017 at 1:17 AM, Pete Heist <petehe...@gmail.com> wrote: > > > On Feb 16, 2017, at 9:42 AM, Sebastian Moeller <moell...@gmx.de> wrote: > > > >> On Feb 16, 2017, at 08:57, Pete Heist <petehe...@gmail.com> wrote: > >> [… discussion about DSCP to WMM classes mapping] > >> This always makes me wonder what’s to keep someone from just marking all > >> their traffic 0x7 and stomping over everyone else. > > > > I have a gut feeling that an AP in a untrusted/hostile environment > > should monitor the usage of the 4 different WMM classes and step up their > > class accordingly. That is in an environment where there is a lot of AC_VO > > or AC_VI traffic the AP should elevate its normal data packets priority to > > match as not too be drowned out by the other senders. Sort of a reciprocal > > tit-for-tat approach, with the goal that the AP will keep access to a > > decent share of airtime. But since I am a layman in these matters, I might > > be out to lunch on this… > > At first I was thinking to just remove diffserv markings entirely, say with > Cake’s besteffort flag, but I think that “good” and “otherwise unknowing” > users would suffer, which I think in FreeNet is a vast majority of users. > > I think the challenge might be what metric to use to know when classes are > being abused. Maybe roughly if dscp_value * bytes_transferred exceeds some > threshold in some given period of time, that would work. Best effort wouldn’t > affect this metric so they can use this class all they want, and if someone > just uses their connection for typical VoIP usage, the threshold shouldn’t be > exceeded. Only when a lot of data is transferred per period of time in higher > classes would they exceed the threshold. > > For now, we could just measure this (with iptables?) and send an admin email > when the threshold is exceeded, then automate a strategy to combat it if > needed. But I bet most users in a community WISP, if notified, would just try > to help fix the problem… :) > > Pete > > _______________________________________________ > Make-wifi-fast mailing list > make-wifi-f...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast > _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake