On Sat, May 9, 2015 at 10:20 AM, Bob Briscoe <bob.bris...@bt.com> wrote:
> 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.
I like the harmonic idea a lot, it ties in with some of my packet pair
thinking on wifi aggregation.
> 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)" <f...@cisco.com>
> From: Bob Briscoe <bob.bris...@bt.com>
> Subject: ECN AQM parameters (was: AQM Recommendation: last minute change?)
> Cc: Gorry Fairhurst <go...@erg.abdn.ac.uk>, Richard Scheffenegger
> <r...@netapp.com>, "Eddy Wesley M. [VZ]" <wesley.m.e...@nasa.gov>,
> "aqm-...@ietf.org" <aqm-...@ietf.org>
>
> 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
> 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 <bob.bris...@bt.com> 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
--
Dave Täht
Open Networking needs **Open Source Hardware**
https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
