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

[Spencer Dawkins at IETF <[e-mail]>]

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

On Mon, Aug 7, 2017 at 9:31 AM, Sowmini Varadhan <
[e-mail]> wrote:

> 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.
>

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


> 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
>
>