Re: [aqm] I-D Action: draft-ietf-aqm-pie-02.txt

["Rong Pan (ropan)" <[e-mail]>]

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 alpha, beta and
Tupdate. QUEUE_SMALL: This is normal RED default queue minimum. IMHO,
occasional queue above that value could be allowed. accu_prob is
empirical. As you mentioned this would only work in one flow per queue
scenario. This is  now MAY feature of PIE. Max 20%: agreed. Maybe 10%.
EWMA ­constant: I would agree. Mentioned in the draft.

7. Implementation suggestions: similar to 5 ii).

8. Fixed accordingly except the comment:

"if dq_count > dq_threshold then depart_rate = dq_count/(now-start);
dq_count -= dq_threshold; start = now;²

dq_count has already being used in the rate calculation and it is
reflected in the (now-start) time. There is no reminder here.












On 8/10/15, 12:20 PM, "aqm on behalf of [e-mail]"
<[e-mail] on behalf of [e-mail]> wrote:

>
>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/aqm