[Make-wifi-fast] [Cake] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available

[Sebastian Moeller]

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