Subject: [tsvwg] Review of Curvy RED Appendix in draft-ietf-tsvwg-aqm-dualq-coupled-08

From: Bob Briscoe <[email-masked]>
Date: Mon, 18 Mar 2019 16:16:52 +0000

tsvwg,

This email channels Gabi Bracha at Broadcom who has sent me a review of 
the Curvy RED implementation example in Appendix B of 
draft-ietf-tsvwg-aqm-dualq-coupled-08, based on his implementation 
experience.

See offlist conversation below, pasted with Gabi's permission.
I shall update appendix B to address the points, as mentioned in the thread.

Bob

------------------------------------------------------------------------
*From:* Gabi Bracha <[email-masked]>
*Sent:* 18 March 2019 12:31
*To:* Bob Briscoe
*Subject:* Re: Curvy RED

On Mon, Mar 18, 2019 at 2:05 PM Bob Briscoe 
<[email-masked] 
<mailto:[email-masked]>> wrote:

    Gabi,

    Thx for these. See[BB] inline

    ------------------------------------------------------------------------
    *From:* Gabi Bracha <[email-masked]
    <mailto:[email-masked]>>
    *Sent:* 13 March 2019 15:02:53
    *To:* Bob Briscoe
    *Subject:* Re: Updated invitation: ECN marking @ Wed Mar 13, 2019
    11am - 12pm (IST) ([email-masked]
    <mailto:[email-masked]>)

    Hi Bob

    I reread the appendix:

    Bear in mind that my frame of mind is that of high bandwidth
    switches. High bandwidth means 1 clock per enqueue +  dequeue.
    So some formulations or optimization do not look relevant to me.

    1.  The issue that I object the most in Curvy RED that it produces
    not 0 mark/drop probability for shallow queues. I think ( and
    definitely in our systems) that very well behaved flows on
    non-congested ports,
      do develop some size. Dropping these even at low probabilities is
    unacceptable. I think you need a configuration threshold to apply
    the probabilistic drop mark.

    [BB]: Yes, you're right that Appendix B doesn't say that (even tho
    we implemented it ourselves - before we moved on from Curvy RED to
    DualPI2). I'll definitely add that.

    2. EMWA  - usually with size decreasing VOQs, if current size is
    smaller than the average you reset the average to the current size.
    Otherwise, recovery from high marking probabilities to low ones can
    take quite a while,
    and will result in too aggressive rate reduction at of the senders.

    [BB]: OK I can put that in.

    Wouldn't it be better to use min(current_delay, EWMA_delay), but not
    alter the EWMA?
    Otherwise, if traffic is coming and going in bursts, and you kick
    down the EWMA whenever there's a quiet period, it will be far too
    low to deal with the next burst quickly.

[GB] Who knows. I do not like the idea of high EWMA_delay and low 
current_delay.

    [BB]: I assume you are aware that there is no EWMA at all on the L
    queue.

[GB] But of course.

    3. The delete loop at the dequeue. Why at the dequeue. What
    the point of enqueueing "drop" packet. I understand that you want to
    mark at dequeue, and you want to unify treatment of drop and mark,
    but it looks od, and I doubt
    whether anyone would implement WRED on dequeue. Once you drop and
    enqueue you do not need that loop construct.
    I understand.

    [BB]: It's not just so drop and marking are similar. An AQM does not
    drop packets to reduce the queue. It drops packets to fool TCP into
    reducing the load. The drop is a signal to TCP, just like an ECN
    signal, and therefore timeliness is just as important.

    A long-running classic TCP flow needs a queue of the same order as
    the base RTT, otherwise it underutilizes the link. So, AQM drop at
    enqueue will typically depend on information that is 1 base RTT late
    by the time the 'hole' gets to the head for dequeue.

    So AQM at enqueue takes 2RTT before the source responds. That's OK
    but, if you can do it at dequeue, you get much better responsiveness
    (ie. less spiky delay).

    Having said that, in Low Latency DOCSIS, we decided to compromise
    and continue to do AQM at enqueue. But that was because we had
    managed to confine all the other changes to firmware/software
    whereas AQM at dequeue would have required a hardware change.

[GB] I get it. So you say Tail-Drop and Classis WRED should be done ( 
also on dequeue)

    I have no problem in sharing these with the rest of your team.

    [BB] Thanks.However, there may be a misunderstanding. My request was
    to share with the
    IETF mailing list ([email-masked] <mailto:[email-masked]>), which is
    visible to the world, not just 'my team'. See next email.

[GB] I have no problem with that.

Cheers

Bob

Gabi

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/