This is pretty much a thinking out loud experiment/meander as I understand it to be in cake.
I have a 80/20mbit FTTC line into the house. Egress shaping/control with cake is simple, easy, beautiful and it works. Tell it to use 19900Kbit, set some min packet size, a bit of overhead and off you go. Ingress has more problems: Assuming I do actually get 80Mbit incoming then the naive bandwidth setting for CAKE would be 80Mbit. Cake internally dequeues at that 80Mbit rate and therefore the only way any flows can accumulate backlog is when they’re competing with each other in terms of fairness(Tin/Host) and quantums become involved…I think. The backlog is controlled by the cake egress rate. There’s an ‘ingress’ mode within cake that AFIUI says ‘even though you dropped a packet, still include it in the ‘bandwidth occupied’ count, because the data still arrived through the link, even though we dropped it’ BUT we’re still operating at the output/egress side of cake and not looking at all at how much data is arriving on the queue input side…the upstream ISP shaper is doing that for us. I’ve been wondering about how to control the rate on the input side to cake, and an ingress policer is available under linux. If that policer is set a little below the ISP rate then IT, in theory, will shoot packets first and harder than the ISP one, therefore the congestion/control point is with us. And I also think we’ve the potential of running cake in ‘unlimited’ mode… ie. it doesn’t have to do the shaping (at the wrong point - egress). It just does ‘flow/host’ fairness ‘backpressure’. Does any of that make sense? Cheers, Kevin D-B gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
