[aqm] avoiding the sqrt
The CoDel control_law is defined as 't + interval/sqrt(count)' The sample implementation (http://queue.acm.org/appendices/codel.html) suggests that sqrt(count) can be calculated using only integer multiplication, but I'm wondering if it even needs to be calculated. Would it not be more efficient to pre-calculate a set of 1/sqrt(count) for some range -- probably (1..interval), and for any count interval, the next interval can just be set to t+1. Is there any reason to not use this approach (assuming sufficient memory exists, of course)? --Jeff /dev/jeff_weeks.x2936 Sandvine Incorporated ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] avoiding the sqrt
The version of codel that cake uses does indeed use such a lookup table for 1..15. This was for accuracy rather than performance reasons. - Jonathan Morton ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] I-D Action: draft-ietf-aqm-pie-02.txt
Hello, A new draft of PIE has been posted. Below are our responses to Bob¹s questions. Thanks, Rong ‹ Response to Bob¹s comments 1) Proposed Standard, but normative language: Done 2) Has PIE been separately tested with and without each enhancement? Yes. During the DOCSIS-PIE evaluation process, the new features are added proven to improve the performance, especially for a single TCP flow¹s performance. 3) Needs to enumerate whether it satisfies each AQM Design Guideline: i) no ECN behavior: added ii) no autotuning of two main parameters: we have made autotuning alpha and beta parameters a MUST for PIE. iii) Transport independence: alpha and beta. Since any TCP variance would need to be TCP friendly, we think TCP-Reno is still a reasonable baseline assumption. Our parameters chosen have been tested in various situations and they work well. For the UDP traffic, since there is no feedback at end hosts, so there is no RTT associated with the rate control. The feedback loop is directly at the queue which would make the loop very stable. Our simulation results of UDP traffic clearly demonstrate that it is the case. These parameters are not hard-coded for ever and they are configurable. We can certainly retune them if we know majority of the transport layer protocols have been changed to something else. None the less, I believe we can make parameter adjustments if needed. Regarding the parameter difference between the paper and the recommendation. The paper shows the parameters chosen with the phase margins that we use. Note that with 1/8, we have a phase margin of around 25 degree at 0.2%. During the DOCSIS-PIE evaluation, we realized that we need to cover more drop probability regions towards lower end of the spectrum, we modified these results to give us more margins. Yes, you are right in that we had a typo in kappa in the paper. It should be 2alphaRo/(poT). Thanks for pointing it out. I checked with my matlab program, I put the loop components in individually and correctly so the results in the figure are still valid. 4) Rationale for PI controller: Added the following: This is the classic Proportional Integral (PI) controller design which is known for eliminating steady state errors. We adopt it here to control queueing latency so that, at the steady state, the difference between the queueing latency and the target value is zero even under heavy load. 5) Technical flaws/concerns i) Turning PIE off: the drop probability will exponentially decay to 0 if there is no packet arriving. For energy saving sleep mode, we would need a timestamp. When a packet arrives, if it knows the last update is long time ago, the drop probability will be reset to 0. But we prefer not having this energy saving mode in the draft. Vendors are free to choose their own way. ii) Auto-tuning alpha and beta parameters: very interesting!!! we would need to perform some more careful study and simulation work across a range of scenarios in order to be confident that it provides a good scaling function. Perhaps this could be a future enhancement. iii) Averaging: a) queue sampling rate: the infrequency is relative to RTT. We assume Internet scale for this draft. So if the propagation delay is in the orders of tens of ms (fixed) and when the link speeds go up, the amount of buffering we need for single TCP (to get full bandwidth) goes up. So given time constance remain Internet scale: tens of ms, the interval becomes less and less from number of packets point of view. b) we agree that the way we averaging is not exact EWMA. To ensure the rate that we obtain is accurate, we find this method is more practical. iv) Burst allowance unnecessary: BURST_ALLOWANCE to 150ms is very helpful to make sure a single TCP flow can have decent throughput (not getting into timeout) in the first 10 sec or so. v) Need a large delay to make the delay small: This would be the case if the link is very low. In order to make sure that the rate estimation is accurate, we need more bytes to estimate traffic. However, due to burst allowance, we should have enough data for a rate sample for free without causing extra problems. vi) De-randomization: I agree with your argument about multiple flows that does not help. We do see it helps in single TCP flow¹s case. I have made it MAY option for PIE. vii) Bound drop probability below 100%: This makes sense. Shall we make this a parameter or fixed? viii) Lock-out Bias against large packets: I would agree with you. However, I think it would be good to include that in the queue_.is_full(), taildrop function, not AQM function. 6. Numerous magic numbers: the look-up table of factors: look into details. DQ_THRESHOLD, scenario-adjustable. T_UPDATE would be same for all AQM schemes. would be happy to change when WG has a consensus. ALPHA and BETA: added a rule of thumb for the relationship between
[aqm] I-D Action: draft-ietf-aqm-pie-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Active Queue Management and Packet Scheduling Working Group of the IETF. Title : PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem Authors : Rong Pan Preethi Natarajan Fred Baker Filename: draft-ietf-aqm-pie-02.txt Pages : 24 Date: 2015-08-10 Abstract: Bufferbloat is a phenomenon where excess buffers in the network cause high latency and jitter. As more and more interactive applications (e.g. voice over IP, real time video streaming and financial transactions) run in the Internet, high latency and jitter degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and jitter; and hence provide desirable quality of service to users. This document presents a lightweight active queue management design, called PIE (Proportional Integral controller Enhanced), that can effectively control the average queueing latency to a target value. Simulation results, theoretical analysis and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamp, so it incurs very small overhead and is simple enough to implement in both hardware and software. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-aqm-pie/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-aqm-pie-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-pie-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] New I-D: draft-briscoe-aqm-dualq-coupled-00.txt
Hi Yuchung, Bob, (w/o chair hat) Wouldn't be a sensible reaction, in the scenario sketched by Yuchung, to have at least one MSS memory available at all times for L4S queues, and drop from the classic queue if that cann't be guaranteed earlier? Best regards, Richard -Original Message- From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of John Leslie Sent: Samstag, 08. August 2015 13:41 To: Yuchung Cheng Cc: Bob Briscoe; AQM IETF list Subject: Re: [aqm] New I-D: draft-briscoe-aqm-dualq-coupled-00.txt Yuchung Cheng ych...@google.com wrote: Interesting work. Do the queues share the same memory pool? I don't believe the draft says one way or the other; but the concept would seem to call for separate memory. I hypothesize that with current ECN deployment, the bad (reno) guy will take up C_Q. What happens when the nice guy (dctcp) knocks the door when the house is full? the strict priority policy in the doc isn't clear about which butt to boot ... The pseudocode in Appendix A isn't the easiest to read; but it does show that the L4S queue goes out first (with CE marking) before the Classic queue. The draft is also clear that the example applies AQM on exit from the queues. Thus the Classic queue (in this example) could easily fill available memory; so your question is appropriate. The draft is a bit hand-wavy about what happens when there's too much L4S traffic. IMHO, _one_ necessary feature would be to limit the size of the L4S queue and drop L4S traffic that won't fit. -- John Leslie j...@jlc.net ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
[aqm] WGLC on draft-ietf-aqm-eval-guidelines
As chairs, Richard and I would like to start a 2-week working group last call on the AQM characterization guidelines: https://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/ Please make a review of this, and send comments to the list or chairs. Any comments that you might have will be useful to us, even if it's just to say that you've read it and have no other comments. Thanks! -- Wes Eddy MTI Systems ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
