<div dir="ltr">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.<div><br></div><div>But I can certainly see the case being made that the VO and VI queues are never allowed to be over X% of traffic.</div><div><br></div><div>-Aaron</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 16, 2017 at 1:17 AM, Pete Heist <span dir="ltr"><<a href="mailto:peteheist@gmail.com" target="_blank">peteheist@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Feb 16, 2017, at 9:42 AM, Sebastian Moeller <<a href="mailto:moeller0@gmx.de">moeller0@gmx.de</a>> wrote:<br>
><br>
>> On Feb 16, 2017, at 08:57, Pete Heist <<a href="mailto:peteheist@gmail.com">peteheist@gmail.com</a>> wrote:<br>
>> [… discussion about DSCP to WMM classes mapping]<br>
>> This always makes me wonder what’s to keep someone from just marking all their traffic 0x7 and stomping over everyone else.<br>
><br>
>       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…<br>
<br>
</span>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.<br>
<br>
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.<br>
<br>
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… :)<br>
<span class="HOEnZb"><font color="#888888"><br>
Pete<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
Make-wifi-fast mailing list<br>
<a href="mailto:Make-wifi-fast@lists.bufferbloat.net">Make-wifi-fast@lists.<wbr>bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/make-wifi-fast</a></div></div></blockquote></div><br></div>