> 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
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
