Greg,
At 06:54 09/11/2013, Greg White wrote:
This is very interesting work. There are a lot of unanswered questions
about ecn / no-ecn coexistence and differential treatment in an AQM, and
this could provide some answers.
To those who groaned that ECN was not included in DOCSIS 3.1, read these
slides (and Naeem Khademi's).
Indeed. However, I think it would be safe to recommend that ECN
support should at least be implemented and separately configurable,
then it can be turned on or off by operators later.
I'm aware that this doubles the amount of configuration, but we've
had some success already (with RED) in relating all the ECN
parameters to the drop parameters by a formula, so hopefully the
vendor could configure the ECN parameters automatically based on the
drop parameters.
Bob, CoDel uses "interval" both as a hold-off for the first packet drop
and as the numerator in the invsqrt drop scheduling. Setting interval = 0
would result in ECN being signaled on *every* ECN capable packet when the
sojourn time is above threshold. This jibes with some of your charts
for RED, but others show a ramp up in mark probability rather than a step
function. Could you clarify?
We've only looked at WRED in detail, because it was much more
interesting (to us) to reconfigure existing implementations than have
to wait for new code to be implemented and tested.
The suggestions for PIE and CoDel are just conceptual at this stage -
we've done no implementation of this idea with either. (I said this
verbally when presenting the slides, but I should have put it in
writing too). Please read my suggestions for PIE and CoDel in this light.
I'm not surprised that CoDel derives other parameters from 'interval'
that should have been declared and set separately. Andrew McGregor
also pointed out to me that CoDel sets threshold = 0.2*interval, so
threshold would have to be declared separately as well. This starts
to reveal just how many magic numbers there really are in the CoDel algorithm.
Setting max_burst = 0 in PIE would not result in the step function
behavior.
It's not meant to result in a step-function.
In the WRED example, it solely avoids the delay of queue averaging,
so that once the /instantaneous/ queue exceeds min_thresh it marks
with increasing probability (not intended to be a step).
Similarly with PIE, the formula:
p = p + alpha*(est_del-target_del) + beta*(est_del-est_del_old);
would still gradually increase the probability of drop (not a step
function), but it would start to do so as soon as the queue exceeded
target_del, rather than waiting for max_burst.
Is that what you meant?
Bob
-Greg
On 11/7/13, 1:03 PM, "Bob Briscoe" <[email protected]> wrote:
>Folks,
>
>"Immediate ECN" slides:
><http://bobbriscoe.net/presents/1311ietf/1311tsvarea-iecn.pptx>
><http://bobbriscoe.net/presents/1311ietf/1311tsvarea-iecn.pdf>
>
>PS. This talk fell off the end of the TSVAREA agenda. It's mostly
>relevant to AQM, but I didn't originally bring it to AQM, because it
>affects 3 wgs: tsvwg, aqm & tcpm.
>
>In the AQM wg, there was dismay about CableLabs not including
>anything about ECN in DOCSIS3.1. This talk is about AQM dynamics; and
>how ECN can take out the 100ms of delay that CoDel and PIE introduce
>- it's essentially about auto-tuning for RTT.
>
>It gives an interim recommendation for hardware designers that there
>should be a second instance of the AQM algo for ECN packets so that
>it can be configured with different parameters (think of WRED instead of
>RED).
>
>Specifically, for ECN packets:
>interval = 0 (for CoDel)
>max_burst = 0 (for PIE)
>
>
>Bob
>
>PS. We have a paper under submission, which we can supply on request.
>We plan to document this in the IETF too.
>
>
>
>
>________________________________________________________________
>Bob Briscoe, BT
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
