Dave,
As promised, here's my thoughts on what PIE (and CoDel) should do
when ECN is enabled.
There's also new info in here that I think is important: CoDel uses
an RTT estimate in two different places. One has to be the max
expected RTT, the other should be the (harmonic) mean of expected RTTs.
The former might be 100ms, but the latter is more likely to be
15-20ms, given most traffic in the developed world these days comes
from CDNs. This could make significant difference to performance.
Bob
Date: Tue, 14 Apr 2015 19:59:47 +0100
To: "Fred Baker (fred)" <[email protected]>
From: Bob Briscoe <[email protected]>
Subject: ECN AQM parameters (was: AQM Recommendation: last minute change?)
Cc: Gorry Fairhurst <[email protected]>, Richard Scheffenegger
<[email protected]>, "Eddy Wesley M. [VZ]" <[email protected]>,
"[email protected]" <[email protected]>
Fred,
At 22:27 13/04/2015, Fred Baker (fred) wrote:
I think w have a pregnant statement in this case. What parameters
do you have in mind?
The point was simply to ensure that implementers provide sufficient
flexibility so that /any or all/ of the AQM parameters for ECN
traffic could be separate instances from those for drop. But they
would still apply to the same queue, much like the different RED
curves for different traffic classes in the WRED algo.
With RED, the parameters available to change are min-threshold,
max-threshold, the limit mark/drop rate, and (IIRC) the minimum
inter-mark/drop interval.
...and, importantly, the EMWA constant, which is the main parameter
I would change for ECN (for ECN set ewma-const = 0, assuming the
Cisco definition of ewma-const as
EWMA weight = 2^{ema-const}
So for ECN, EWMA weight = 2^0 = 1).
See also {Note 1} about inter-mark/drop interval.
With PIE, the equation is
p = p + alpha*(est_del-target_del) + beta*(est_del-est_del_old).
meaning that we can meaningfully tune alpha, beta, and target_del,
and there is an additional 'max_burst' parameter.
Yes.
Strictly, the min data in the queue before PIE measures the rate
('dq_threshold') is a parameter as well.
With Codel, if I understand section 4, the only parameters are the
"a round-trip time metric" (100 ms by default) and the Setpoint,
which they set to 5 ms based on it being 5-10% of the RTT.
If it's not the target delay, which is essentially what Codel's
setpoint is, I'm not sure what parameter you want to change.
There are actually two more hidden parameters in CoDel's control
law, which is written in the pseudocode as :
t + interval / sqrt(count)
but ought to have been written as:
t + rtt_ave / (count)^b
These parameters have been hard-coded as
rtt_ave = interval
and
b=1/2.
'rtt_ave' in the control law is better set to a likely /average/
RTT, whereas the interval used to determine whether to enter
dropping mode is better set to a likely /maximum/ RTT.
To implement an ECN variant of CoDel I would set
interval = 0 (or very close to zero)
and I would leave 'rtt_ave' (in the control law) as an average RTT,
decoupled from 'interval'.
However, the CoDel control law was designed assuming it will remove
packets from the queue, so I'm not convinced that any naive approach
for implementing ECN will work. I suspect a CoDel-ECN doesn't just
need different parameters, it needs a different algo.
I have no interest in solving this problem, because I wouldn't start
from CoDel in the first place - I would never design an AQM that
switches between discrete modes, and CoDel's control law assumes
that the e2e congestion control is NewReno which contravenes our AQM
recommendations anyway.
In saying 'in this case you might want to mess with the
parameters', I'm not sure what parameters are under discussion, and
in any event we're talking about the document that says 'we should
have an algorithm', not the discussion of any of them in particular.
To my mind, this begs for a new draft on your part.
Certainly. We're still doing the research and evaluation tho (see
<http://www.ietf.org/proceedings/92/slides/slides-92-iccrg-5.pdf>www.ietf.org/proceedings/92/slides/slides-92-iccrg-5.pdf
- I don't remember whether you were in the room for that). But, yes,
we will write it up.
So far it's not based on RED, PIE or CoDel, but a new drop-based AQM
that is most similar to RED but with only 2 parameters (not 4). This
is because we needed the drop probability to be the square of the
marking probability. So it made the implementation really simple to
use a square curve through the origin for drop. It doesn't need
min_thresh, because the square curve near-enough runs along the axis
when it is close to the origin. For the square curve we used a
probability trick - we merely had to compare the queue delay with
the max of two random numbers. RED (especially gentle RED) can be
thought of as a piecewise linear approximation of a square curve.
We're evaluating this as a drop AQM in its own right. The neat thing
about a square curve (or any convex curve) is that the increase in
delay wrt load reduces as load increases.
I've worked out how to do a similar squaring trick with PIE, but
it's not a straightforward forklift of the same idea, so it needs to be tested.
It would be really hard/impossible to fork-lift the idea into CoDel,
because it switches modes. As above, I have no interest in building
on CoDel anyway.
Cheers
Bob
{Note 1}: The whole min inter-mark/drop interval aspect of RED is
just a waste of cycles. Any attempt to alter the distribution of
inter-mark/drop spacing in an aggregate just collapses into a
geometric distribution again for each flow. For proof see "Are RED
Markings Uniformly Distributed?" in my PhD dissertation
<http://www.bobbriscoe.net/pubs.html#refb-dis>.
> On Apr 13, 2015, at 11:23 PM, Bob Briscoe <[email protected]> wrote:
>
> Gorry, Fred, Richard, Wes,
>
> [Off list, because I don't want to distract people's attention
if you don't want to make this change]
>
> While replying to David Lang just now, I checked with the AQM
recommendation says, and the para below raised a concern:
>
>
<https://tools.ietf.org/html/draft-ietf-aqm-recommendation-04#section-4.2.1>
> " An AQM algorithm that supports ECN needs to define the threshold and
> algorithm for ECN-marking. This threshold MAY differ from that used
> for dropping packets that are not marked as ECN-capable, and SHOULD
> be configurable.
> "
> The work Koen has done since this was written has satisfied me
that the threshold has to be the same (to prevent starvation), but
other parameters can be different, and ought to be. So in the
second sentence I think we should say:
>
> CURRENT: "This threshold MAY differ from that used for dropping..."
> PROPOSED: "The parameters MAY differ from those used for dropping..."
>
> Parameters widens it to burst size, slope, etc.
>
> If it is too late for any changes, fair enough.
> If this minor change can still be accommodated, then pls do
whatever process is necessary to make the change.
>
> Cheers
>
>
> Bob
>
>
> ________________________________________________________________
> Bob Briscoe, BT
________________________________________________________________
Bob Briscoe, BT
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
