> On Feb 16, 2017, at 8:05 PM, Pete Heist <petehe...@gmail.com> wrote:
>> On Feb 16, 2017, at 6:19 PM, Jonathan Morton <chromati...@gmail.com 
>> <mailto:chromati...@gmail.com>> wrote:
>>> On 16 Feb, 2017, at 18:51, Pete Heist <petehe...@gmail.com 
>>> <mailto:petehe...@gmail.com>> wrote:
>>> 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.
>> That’s not what the “besteffort” flag does.  It ignores DSCPs and puts all 
>> traffic into a single tin, but doesn’t remove the DSCP marking.
> Thanks, I had mixed this with “squash”.
>>>> 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.
> Aha, that sounds like just what we need as far as diffserv is concerned! I’ll 
> punt on trying to understand what that means for Wi-Fi just yet, but will 
> come back to it.
> Even though I’m sticking to point-to-point Wi-Fi, I would like to use Cake if 
> possible since we’re shaping on external routers, so I’m testing it more 
> extensively (especially vs sfq since that’s what’s in use now) and will add 
> to my tests:
> - diffserv markings (‘rrul’, where so far I’ve done only ‘rrul_be’ for 
> simplicity to get my test setup verified)
> - flow isolation (triple-isolate), by simulating P2P-like flows, maybe with 
> Flent’s rrul_torrent somehow, also on multiple IPs? Will figure it out.
> - VoIP (if I can get d-ITG working finally)
> This reminds me, I found this location for the latest Cake man page and 
> finally read it in detail, as I should have earlier:
> http://static.lochnair.net/bufferbloat/tc-cake.8.html 
> <http://static.lochnair.net/bufferbloat/tc-cake.8.html>
> 1) Should I be using the Ethernet keyword when running Cake on routers 
> connected to the AP (or station) via Ethernet? And overheads for Wi-Fi also, 
> is that even possible to get right, or if not, what’s closest?
> 2) Is there a more official link for the man page? The one installed with the 
> source from here (git://kau.toke.dk/cake/iproute2/ 
> <https://github.com/dtaht/sch_cake>) seems older.
> Thanks for taking the time to explain!

3) And a followup question from this statement on the man page:

"CAKE can divide traffic into "tins" based on the Diffserv field. Each tin has 
its own independent set of flow-isolation queues, and is serviced based on a 
WRR algorithm. To avoid perverse Diffserv marking incentives, tin weights have 
a "priority sharing" value when bandwidth used by that tin is below a 
threshold, and a lower "bandwidth sharing" value when above. “

If each diffserv tin has its own flow isolation queues, doesn’t that mean (if 
this is run on a backhaul router) that if one host is abusing the VoIP diffserv 
marking, for example, that they’ll impact other users by using up the bandwidth 
in the tin?
Cake mailing list

Reply via email to