Subject: [aqm] Joel Jaeggli's No Objection on draft-ietf-aqm-docsis-pie-02: (with COMMENT)

From: "Joel Jaeggli" <[email-masked]>
Date: Tue, 15 Mar 2016 00:52:07 -0700

Joel Jaeggli has entered the following ballot position for
draft-ietf-aqm-docsis-pie-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-aqm-docsis-pie/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

For my own edification I assume that the latency target is expected to
fall within

   o  LATENCY_LOW = 5 ms

   o  LATENCY_HIGH = 200 ms.

but presumably it's most usable at the bottom end of that range?

why is the lower bound at 5ms? is it simply unreasonable to target below
that or is it bounded by the resource contention of the subscribers.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 15 Mar 2016 07:59:27 +0000

> On Mar 15, 2016, at 12:52 AM, Joel Jaeggli <[email-masked]> wrote:
> 

I suspect you could set the lower bound as finely as you liked. The issue becomes the probability of an overshoot (or maybe it's an undershoot): you want to keep the queue relatively shallow in general, but you don't really want it to run dry, and you're approximating the behavior of a phase-locked loop (which is the origin of the equations).

Note that Codel has similar parameters.

---

From: Greg White <[email-masked]>
Date: Mon, 28 Mar 2016 17:43:44 +0000

Sorry for the long delay in adding to Fred’s response to this question.

We actually don’t bound the range on latency target other than what can be expressed in a uint8, however the DOCSIS specification recommends that the operator choose a value between 10ms and 100ms (and I personally recommend just using the default of 10ms unless there is a really good reason otherwise).

Resource contention is a factor though.  DOCSIS-PIE estimates queuing latency based on bytes in queue and forecasted forwarding rate.  The queue is sampled every 16ms, and when a sample is taken, a number of packets may simply be waiting in queue for a transmission opportunity (due to the MAC access procedure) rather than being symptomatic of buffering that would be usefully controlled via packet drops.  The typical wait time for a transmission opportunity is on the order of 5ms.

Another point to consider is that PIE uses a “Proportional + Integral” control algorithm.  The input to the controller is “latency error” (measured latency minus target latency), and the output of the controller is packet drop rate.  A digital PI controller calculates its output as  OUTPUT = K1 * INPUT + K2 * cumulative_sum(INPUT).  In order for the OUTPUT (packet drop rate) to return to a steady state value of zero after an active period, the second term needs to equal zero.  This can only happen if the INPUT (latency error) is negative (measured latency is less than target latency) for a time.  This description is based on a pure PI controller; PIE is, of course, “Enhanced”, and includes some features to prevent packet drops in situations where the pure PI controller might not, but you get the idea.  If you examine the pseudocode, LATENCY_LOW and LATENCY_HIGH are in fact examples of this as they are only used as triggers to ramp down or ramp up the packet drop rate more quickly than the PI algorithm would normally dictate.  

-Greg

---

From: joel jaeggli <[email-masked]>
Date: Mon, 28 Mar 2016 10:48:21 -0700

Thanks,

all of this makes sense.

joel