Subject: [aqm] A question regarding the latest FQ-CoDel Internet-Draft

From: Rasool Al-Saadi <[email-masked]>
Date: Wed, 20 Jan 2016 13:29:32 +0000

Dear all,

I have a question regarding the latest FlowQueue-Codel Internet-Draft [*] and hope someone answer my question.

In page 8, subsection 4.2. Dequeue, the text says:
   "If, instead, the scheduler _did_ get a packet back from the CoDel
   algorithm, it updates the byte deficit for the selected queue and
   moves it to the end of the list of old queues, before returning the
   packet as the result of the dequeue operation."

My question is: Why if we get a packet back, we should _always_ move the queue to the end of the old queues list? I wonder whether this is intended or there is an editing error as the previous versions of fq-codel Internet Drafts do not include this movement.

If this text is correctly, this behaviour provides an even share of _packet_ transmission opportunities over time but not an even share of _byte_ transmission opportunities over time. Another effect of this movement is that each queue in new queues will get one packet dequeue opportunity (instead of at least a quantum of bytes) before move to old queues. 

[*] https://tools.ietf.org/html/draft-ietf-aqm-fq-codel-03

Regards,
Rasool Al-Saadi

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 21 Jan 2016 09:25:26 +0100

Rasool Al-Saadi <[email-masked]> writes:

> My question is: Why if we get a packet back, we should _always_ move
> the queue to the end of the old queues list? I wonder whether this is
> intended or there is an editing error as the previous versions of
> fq-codel Internet Drafts do not include this movement.

You're right, of course. That snippet of text is assuming that the
packet we get back exhausts the quantum. If there's still some quantum
left, the queue stays in place.

Will update the text to make this clearer. Well spotted! :)

-Toke

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 22 Jan 2016 16:34:08 +0100

> Will update the text to make this clearer. Well spotted! :)

Updated version is here:
https://kau.toke.dk/ietf/draft-ietf-aqm-fq-codel-04.html

Also substituted 'credit' for 'deficit' in the text, to make it clearer
what is going on conceptually.

Will see if anything else turns up before submitting to the tracker.

-Toke

---

From: "Agarwal, Anil" <[email-masked]>
Date: Mon, 25 Jan 2016 01:14:10 +0000

Toke,

Might be beneficial to fix the following line in section 5.4 -

   int               deficit; /* this is the queue credit */

Anil

-----Original Message-----
From: aqm [mailto:[email-masked]] On Behalf Of Toke Høiland-Jørgensen
Sent: Friday, January 22, 2016 10:34 AM
To: Rasool Al-Saadi
Cc: [email-masked]; Grenville Armitage
Subject: Re: [aqm] A question regarding the latest FQ-CoDel Internet-Draft

> Will update the text to make this clearer. Well spotted! :)

Updated version is here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__kau.toke.dk_ietf_draft-2Dietf-2Daqm-2Dfq-2Dcodel-2D04.html&d=BQIGaQ&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=V6tPHBayP3j5ss-cr0HACteN01SOtMrM4aU-dqgx9fA&s=TnGSwVt-BZ4K58XOBUIXoi1eFDr1qgWHtIJLFTT8pok&e= 

Also substituted 'credit' for 'deficit' in the text, to make it clearer what is going on conceptually.

-Toke

_______________________________________________
aqm mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_aqm&d=BQIGaQ&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=V6tPHBayP3j5ss-cr0HACteN01SOtMrM4aU-dqgx9fA&s=kFHKV4dfecIezkdeThVFOb_C3DivfHyeepoBkmN53dY&e=

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 25 Jan 2016 09:52:06 +0100

>    int               deficit; /* this is the queue credit */

Yeah, I'm aware of that. Couldn't decide what to do about the fact that
the Linux code calls it 'deficit' instead of 'credit', so just punted on
it and added that comment. Guess it's less confusing to just call the
variable 'credit'. Thanks for confirming that it was definitely
confusing ;)

Fixed in the -04.

-Toke

---

From: Björn Grönvall <[email-masked]>
Date: Mon, 25 Jan 2016 10:13:33 +0100

This is definitely confusing and even Varghese (one of the DRR authors) uses this analogy:

    A banking analogy motivates the solution. Each flow is given a quantum,
    which is like a periodic salary that gets credited to the flow’s bank
    account on every round-robin cycle. As with most bank accounts, a flow
    cannot spend (i.e., send packets of the corresponding size) more than is
    contained in its account; the algorithm does not allow bank accounts to
    be overdrawn. However, perfectly naturally, the balance remains in the
    account for possible spending in the next period. Thus any possible
    unfairness in a round is compensated for in subsequent rounds, leading
    to long-term fairness.

Quote is from the book Network Algorithmics (p. 351) by George Varghese.

Perhaps the banking analogy would be less confusing?

Cheers,
/b

On 25 Jan 2016, at 9:52, Toke Høiland-Jørgensen <[email-masked]> wrote:

> https://www.ietf.org/mailman/listinfo/aqm

--

Björn Grönvall, [email-masked], Cell +46 70 768 06 35, Jabber/XMPP: [email-masked]

“The ultimate tragedy is not the oppression and cruelty by the bad people but the silence over that by the good people.”

― Martin Luther King Jr.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 25 Jan 2016 10:20:00 +0100

> Perhaps the banking analogy would be less confusing?

Yeah, that's why I switched to using 'credit' as the term for what is
being kept track of in the next revision:
https://kau.toke.dk/ietf/draft-ietf-aqm-fq-codel-04.html

Can't really change the fact that the algorithm is called 'deficit
round-robin', though, so can't get rid of the 'deficit' term entirely.

-Toke