Thanks, all of this makes sense.
joel On 3/28/16 10:43 AM, Greg White wrote: > 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)" <[email protected]> wrote: > >> >>> On Mar 15, 2016, at 12:52 AM, Joel Jaeggli <[email protected]> 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. >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
