[Ecn-sane] A brick wall threshold for SCE_threshold

[Dave Taht]

I do not think anything other than a brick wall can be implemented in
high speed hardware.

I really wish you'd try a brick wall, and fiddle on bbr. It is also
heavily influenced by kathies work on codel.

On Tue, Mar 9, 2021 at 10:43 AM Jonathan Morton <chromatix99 at gmail.com> wrote:
>
> > On 9 Mar, 2021, at 8:09 pm, Dave Taht <dave.taht at gmail.com> wrote:
> >
> > while I appreciated the experiments with making the assertion of SCE_threshold spread out, and not a brick wall, to me it seems best to coalesce on a brick wall for it at a fixed period of time the operator considers "queuing".
> >
> > Does the SCE team agree with this approach?
>
> In a word, no.  While it might be an acceptable compromise versus implementation cost in the datacentre, in the general case you're not going to get good performance that way.
>
> Formally, what a brick-wall control law gives you is control of *peak* delay in that queue.  It only takes a small number of packets in each RTT going over the threshold to make the flow back off.  If there's more variation of delay than the threshold is set at, then the trough will be with the queue empty and the link idle - and the link introducing the variation might be remote from the one serving as the bottleneck and doing the marking, so you can't merely set the threshold higher at those particular links.
>
> Kathy Nichols designed Codel specifically to control the *trough* of a delay with variance.  This strategy has worked well and applies nicely to paths including a wifi link, so long as the target sojourn time is greater than the time between txops.  Since the limit on wifi aggregation is 4ms, the default setting of 5ms dovetails nicely with that.  The SCE marking target is 2.5ms is actually a little low, but using this with Codel still works markedly better than with a fixed ramp based at the same level, which would tend to control the peak.
>
> Some of my current effort is going into a new AQM algorithm called DelTiC (Delay Time Control).  You can think of it as taking the best ideas from Codel and PIE and putting them together.  Like Codel, it measures queue sojourn time and manages a marking frequency (not probability), making it a fully time-domain algorithm.  The control law is PID, not merely PI, so it can detect a rapidly rising queue depth (due to slow-start exponential growth, say) and act sooner to control it than Codel does.  I think that was one of the big shortcomings of Codel you were keen to see solved.
>
> Unlike Codel, DelTiC has a true steady-state condition where the marking frequency can remain constant.  This goes well with the SCE response function, which permits a constant cwnd when an appropriate marking frequency is received.  This in turn is completely unlike traditional AIMD congestion control, which exhibits a large sawtooth.
>
> Implementation of the first qdisc incorporating DelTiC is not yet complete, and then we have to see how well it works in practice.  I'll talk about it more when it's ready.
>
>  - Jonathan Morton



-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

dave at taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729