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 On 3/15/16, 1:59 AM, "Fred Baker (fred)" <f...@cisco.com> wrote: > >> On Mar 15, 2016, at 12:52 AM, Joel Jaeggli <joe...@bogus.com> wrote: >> >> 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. > >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. _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
