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.

-Aaron

On Thu, Feb 16, 2017 at 1:17 AM, Pete Heist <peteheist@gmail.com> wrote:

>
> > On Feb 16, 2017, at 9:42 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
> >
> >> On Feb 16, 2017, at 08:57, Pete Heist <peteheist@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-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>