Pete Heist <petehe...@gmail.com> writes:

>  On Feb 16, 2017, at 10:03 PM, Sebastian Moeller <moell...@gmx.de> wrote:
>
>  On Feb 16, 2017, at 18:19, Jonathan Morton <chromati...@gmail.com> wrote:
>
>  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? 
>
>  I thought Aaron’s suggestion sounds both sensible and not difficult to 
> implement. That way we wouldn’t even have to regularly monitor it, and anyone 
> who is marking all their packets thinking they’re doing themselves a favor is 
> just limiting their max throughput.
>
>  Could there be another keyword in Cake to do this automatically, say 
> “fairdiffserv", or would this just be feature bloat for what is already a 
> sophisticated shaper? I don’t know if there are sensible mappings from dscp 
> value to max percentage throughput that would work most of
>  the time, or if there could also be an adjustable curve parameter that 
> controls the percentage backoff as you go up dscp levels.
>
>  This is actually what Cake already does by default (the “diffserv3” mode).  
> If you look at the detailed statistics (tc -s qdisc), you’ll see that each 
> tin has a “threshold” bandwidth.  If there’s more traffic than that threshold 
> in that tin, the tin will be deprioritised - it can still use all of the
>  bandwidth left spare by other tins’ traffic, but no more than that.
>
>  Additionally, diffserv3 mode uses more aggressive AQM settings on the 
> “voice” tin than the “best effort” tin, on the grounds that the former is a 
> request for minimum latency.  This should also discourage bulk traffic from 
> using unnecessarily high DSCPs.
>
>  However, in both the “besteffort” and “diffserv3” cases, the DSCP may be 
> interpreted independently by the NIC as well as Cake.  In the case of wifi, 
> this affects the medium grant latency and priority.  If the link isn’t 
> saturated, this shouldn’t affect Cake’s prioritisation strategy much if
>  at all, but it does have implications for the effect of other stations 
> sharing the frequency.
>
>  Here is part of the problem: the more aggressive airtime access of the VI 
> and VO classes will massively cut down the actual achievable bandwidth over 
> all classes. And I might add this effect is not restricted to the AP and 
> station under one’s control, but all other stations and APs using
>  the same frequency that are in the close RF neighborhood will affect the 
> available airtime and hence achievable bandwidth. If you look how wifi 
> achieves its higher bandwidth it is by using longer periods of airtime to 
> make up for the rather fixed time “preamble” that wastes time without
>  transmission of user data. VI users in the vicinity will drastically (IIRC) 
> reduce the ability to send those aggregates. In other words link saturation 
> is partly a function of which AC classes are used and not a nice and fixed 
> entity as for typical wired connections. Now if you can control both
>  sides of your transfer _and_ all other users of the same frequency that are 
> RF-visible to your endpoints, it might be possible to thnk of a wifi link in 
> similar terms as a wired one, but I would be cautious…
>
> Thanks for that info. In my testing I’m focusing on point-to-point Wi-Fi, but 
> I see the complexity that WMM presents, especially when there's more than one 
> station.
>
> It's perplexing that at least two concerns- packet retransmission and 
> prioritization, occur at multiple layers in the stack. 802.11 ack frames are 
> sent in response to every data frame (aggregation aside), and retransmission 
> occurs at this layer, but also higher up in the TCP layer. Prioritization
> can occur at the IP layer, but then again in the media layer with WMM. This 
> seems to violate separation of concerns, and makes it difficult to ascertain 
> and control what’s going on in the system as a whole.
>
> It feels like WMM went a step too far. There may have been (may still be) 
> valid performance reasons for Wi-Fi to take on such concerns, but as the data 
> rates get higher and processing power increases, it feels like it would be 
> better to have a wireless technology that just delivers frames,
> and to push reliability, prioritization and aggregation back up into the 
> higher layers so that long-term innovation can take place in software. The 
> 802.11 spec is on my reading list so I might learn if and where this goes off 
> the tracks.

Note that WMM also affects max aggregation sizes; the VO queue doesn't
do aggregation at all, for instance; and the max aggregate size for VI
is smaller than for BE. This *should* be an incentive to not use the
higher queues for bulk traffic.

That being said, I do believe there are issues with how the QoS levels
are currently handled in the Linux WiFi stack, and looking into that in
more detail is on my list somewhere... :)


-Toke
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Reply via email to