> 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

Reply via email to