Re: [Cake] Playing with ingredients = ruined the CAKE

[Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>]

> On 29 May 2020, at 11:06, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
> 
> I’m trying to create a ‘diffserv5’ for the purposes of implementing a 'Least Effort’ class: something like LE=Bittorrent, BK=Backups/long term down/uploads, BE=Best Effort/Normal, VI=Streaming media/facetime/zoom, VO=VOIP/SIP.  Not too hard you’d think, take diffserv4 and add a tin.
> 
> I did this with tin allocation: 0=LE, 1=BE, 2=BK, 3=VI, 4=VO.  BW allocation relative to base rate = LE>>8, BE>>0, BK>>4, VI>>1, VO>>2.  Tin display order = 0, 2, 1, 3, 4.  In theory I don’t mind LE being starved hence the above order.  This pretty much ‘jammed' the shaper as soon as any traffic went into LE with other higher priority tins seeing huge latencies, lots of drops and general bad news all over.
> 
> I tried again with a slightly different tin allocation: 0=BE, 1=LE, 2=BK, 3=VI, 4=VO more in keeping with the existing arrangement and display order 1, 2, 0, 3, 4. The shaper doesn’t appear to obviously wedge, though I have seen some latency spikes that I don’t normally see, so it feels like there’s still a corner case being hit.
> 
> Does anyone have any ideas?

Pondering out loud:  Is setting different (i.e. increased) codel intervals & targets sensible for ‘artificially’ reduced bandwidths, especially in ingress mode?  If I have a 100mbit link and I wish to have a minimum reservation for a low bandwidth, low priority tin e.g. 1mbit. Does it make sense to make that tin respond slower as if it were a 1mbit link whereas it’s a minimally reserved portion of a 100mbit link and it could burst up 100 times quicker than I think?  Egress I suspect is less of a problem in that we’ll queue the packets and eventually throw them in the floor, but ingress???

Kevin