Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
* [Cake] Thinking about ingress shaping & cake
@ 2020-04-10 13:16 Kevin Darbyshire-Bryant
  2020-04-10 14:14 ` Jonathan Morton
  0 siblings, 1 reply; 6+ messages in thread
From: Kevin Darbyshire-Bryant @ 2020-04-10 13:16 UTC (permalink / raw)
  To: Cake List

[-- Attachment #1: Type: text/plain, Size: 1765 bytes --]

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


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-04-12 13:13 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-10 13:16 [Cake] Thinking about ingress shaping & cake Kevin Darbyshire-Bryant
2020-04-10 14:14 ` Jonathan Morton
2020-04-12  8:23   ` Kevin Darbyshire-Bryant
2020-04-12  9:47     ` Sebastian Moeller
2020-04-12 11:02     ` Jonathan Morton
2020-04-12 13:12       ` Kevin Darbyshire-Bryant

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox