> On Feb 16, 2017, at 17:15, Aaron Wood <[email protected]> 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 <[email protected]> wrote:
>
> > On Feb 16, 2017, at 9:42 AM, Sebastian Moeller <[email protected]> wrote:
> >
> >> On Feb 16, 2017, at 08:57, Pete Heist <[email protected]> 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
> [email protected]
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
