[Cake] Why are target & interval increased on the reduced bandwidth tins?

[Kevin Darbyshire-Bryant]

> On 24 Jun 2020, at 15:40, Sebastian Moeller <moeller0 at gmx.de> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20200625/87f919ca/attachment.sig>