> On 24 Jun 2020, at 15:40, Sebastian Moeller <[email protected]> wrote: > > Hi Kevin, > > so the way codel is designed target is best understood as a function of > interval (allowing 5-10% of interval as standing queue allows a fine > trade-off between bandwidth utilization and latency under load increase). > Now, interval is basically akin to the time you are willing to give a flow to > react to signals, it should be in the same order of magnitude as the path > RTT. Now reducing the bandwidth allocation for a traffic class will increase > its saturation load RTT and hence increasing the target seems justified; > target just follows along due to still wanting a reasonable bandwidth/latency > trade-off. > So in short these scale the shaper to work well under loaded conditions. But > Jonathan & Toke will be able to give the real explanation ;) > > Best Regards > Sebastian
So crudely interval is the delay before we start jumping on packets. And I think that’s the wrong thing to do for ingress. So the scenario I have in my head says that BK traffic could burst at full bandwidth rate (or higher) filling upstream ISP buffers and thus inducing delays on all other traffic because "we think it’s a slow link and have high interval and target values” delaying our response to the burst. Whereas if we retain the default interval & target from the true link capacity calculation we’ll jump on it in time. The same thing happens in traditional egress mode but it doesn’t matter as much as we are in control of our own buffer/queue and we’ll see the higher priority traffic and skip to servicing that and gradually bring the BK tin back under control. What’s the error in my thinking? Kevin
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
