The implementation of ControlledDelay: https://github.com/TritonDataCenter/node-cueball/blob/master/lib/codel.js
References this specification: https://queue.acm.org/appendices/codel.html
I believe the implementation diverges from this reference specification in cases where a queue has entries that each take CODEL_INTERVAL duration to complete through the queue.
In the reference specification, this would place the queue in the "dropping" state, but the value of drop_next would be re-calculated each time.
In the current implementation, the following would happen:
okToDrop would be set to true:
|
var okToDrop = this.canDrop(now, start); |
We'd be in the drop state:
And for requests arriving at CODEL_INTERVAL, we'd drop them:
|
} else if (now >= this.cd_drop_next) { |
|
dropClaim = true; |
|
this.cd_count += 1; |
|
} |
This doesn't invoke getDropNext to calculate the next plausible drop time -- it just leaves the old value, which is already in the past. This is where the behavior diverges from the reference specification -- in the reference spec, the value of drop_next is recalculated anytime the queue attempts to drop a value
The implementation of ControlledDelay: https://github.com/TritonDataCenter/node-cueball/blob/master/lib/codel.js
References this specification: https://queue.acm.org/appendices/codel.html
I believe the implementation diverges from this reference specification in cases where a queue has entries that each take
CODEL_INTERVALduration to complete through the queue.In the reference specification, this would place the queue in the "dropping" state, but the value of
drop_nextwould be re-calculated each time.In the current implementation, the following would happen:
okToDropwould be set to true:node-cueball/lib/codel.js
Line 59 in b66d96e
We'd be in the
dropstate:node-cueball/lib/codel.js
Line 62 in b66d96e
And for requests arriving at
CODEL_INTERVAL, we'd drop them:node-cueball/lib/codel.js
Lines 65 to 68 in b66d96e
This doesn't invoke
getDropNextto calculate the next plausible drop time -- it just leaves the old value, which is already in the past. This is where the behavior diverges from the reference specification -- in the reference spec, the value ofdrop_nextis recalculated anytime the queue attempts to drop a value