Subject: [tsvwg] comments about draft-ietf-tsvwg-aqm-dualq-coupled-01.txt

From: Sowmini Varadhan <[email-masked]>
Date: Mon, 7 Aug 2017 10:31:20 -0400

I had some questions as I was going over this document and
Bob Briscoe suggested that this might be a useful discussion to
share with a list, so here's a current summary, including
clarifications that Bob provided for me offline

In general, I liked the fact that the Appendix starts off by first
discussing core concepts and then gets into the more complex overload
case- this makes it easy to understand how the various blocks build on
each other.

In keeping with that same core -> complex flow, it might be easier to
refactor Appendix A.1 a bit, so that it first goes over the enque/dequeue
logic and then gets into the more complex PI-update Pseudo-code. 

I realize the document *is* trying to do that, but it took
me some time to figure out the semantics of alpha/beta/alpha_U/beta_U
(these get defined in Figure 1, but a detailed description
is only available at the bottom Page 17..)

What eventally helped me put things in place was the brief background
that Bob offered (in the offline thread)

Bob> A Proportional Integral (PI) algorithm changes the controlled variable (the
Bob> loss probability p) dependent on how fast the queue is increasing (which is
Bob> Proportional to excess load) and how far any standing queue is
Bob> from its target (which represents the Integral of load). Two "gain
Bob> factors", beta and alpha, respectively weight how strongly each of
Bob> these elements alters p.

Bob> The stability analysis in [PI216] recommends the values of alpha
Bob> and beta (in the header file in Fig 1) on the basis that these
Bob> cause the AQM to change p (loss prob) as fast as poss in response
Bob> to changes in load without over-compensating and therefore causing
Bob> oscillations in the queue.

Bob> The recommended values of alpha and beta determine how much p ought
Bob> to change if it was updated every second. It is best to update p
Bob> as frequently as possible, but the actual update interval (Tupdate)
Bob> is constrained by hardware performance. For link rates from 4 -
Bob> 200 Mb/s, we found Tupdate=16ms is sufficient. Whatever value of
Bob> Tupdate is chosen, p should change by the same amount per second,
Bob> but in more smaller steps. So the gain factors used need to
Bob> be scaled by (Tupdate/1s). This is why alpha_U and beta_U are
Bob> used for updating p in Fig 4, where alpha_U= alpha*Tupdate and
Bob> beta_U=beta*Tupdate.

Some/all of this information would be useful to have in the doc, since
it provides the needed brief background for dualpi2_update, within
the draft itself. 

One follow-up question (I've not read all of [PI216] yet, it's on my
reading list) - what is the general trend of Tupdate for faster
link-rates? E.g., what is the expected Tupdate at 1Gb/s?

It would also be helpful to define the high-level semantics
of cq.time(), cq.len(), lq.len() etc. E.g. the description that Bob
offered in the offline mail (below) could be added in the preamble
to enque/dequeue, to improve readability (and also help an implementor
quickly see what the function indirections are supposed to do).

Bob> cq.time() is a function that returns the time that the head packet
Bob> has been in the classic queue (cq), which is called the "service
Bob> time" of the queue, or sometimes the "sojourn time".

Bob> Similarly for lq.time(), cq.len() and lq.len(), where lq is the
Bob> L4S queue and len() is the length in bytes.

I'm still working through the doc, will get back here with additional
questions/comments.

Thanks
--Sowmini

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 8 Aug 2017 14:34:02 -0500

Speaking as an individual, but as an individual who needs to understand
what's going on at PubReq time :-) ...

> it provides the needed brief background for dualpi2_update, within

I found Bob's note to be very helpful to me. It might be helpful to include
something like that text in the document itself.

Do the right thing, of course.

Spencer