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

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

[Kevin Darbyshire-Bryant]

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

Genuine question.  For the reduced bandwidth tins in diffserv3/4/8 a different rate and hence different target & interval values are also calculated.  I get why a target/interval calculation is desirable for the ‘main’ tin - this forms a ‘best case’ of how long each byte takes to transmit and is fundamental to the shaper.  What I’m less clear on is why increased targets & intervals are used for the reduced threshold tins.

To my mind it means those tins can be more ‘bursty’ before codel jumps on them.  That’s possibly ok on an egress path but I’m not so convinced on an ingress path.

Please point out the error in my thinking!


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 --]

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

[Sebastian Moeller]

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



> On Jun 24, 2020, at 16:33, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
> 
> Genuine question.  For the reduced bandwidth tins in diffserv3/4/8 a different rate and hence different target & interval values are also calculated.  I get why a target/interval calculation is desirable for the ‘main’ tin - this forms a ‘best case’ of how long each byte takes to transmit and is fundamental to the shaper.  What I’m less clear on is why increased targets & intervals are used for the reduced threshold tins.
> 
> To my mind it means those tins can be more ‘bursty’ before codel jumps on them.  That’s possibly ok on an egress path but I’m not so convinced on an ingress path.
> 
> Please point out the error in my thinking!
> 
> 
> Cheers,
> 
> Kevin D-B
> 
> gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

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

[Kevin Darbyshire-Bryant]

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



> On 24 Jun 2020, at 15:40, Sebastian Moeller <moeller0@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

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

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

[Jonathan Morton]

> On 25 Jun, 2020, at 4:40 pm, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
> 
> 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.

You might be forgetting about ack clocking.  This gives the sender information about how quickly data is reaching the receiver, and normally the sender will generate either one or two packets for each packet acked.  So even without an immediate AQM action, there is still *some* restraint on the sender's behaviour within approximately one RTT.

This is one of the many subtle factors that Codel relies on.

 - Jonathan Morton