Rong,
I've snipped inline...
At 22:15 21/05/2015, Rong Pan (ropan) wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_D183961BF09Cropanciscocom_"
Sorry that I have not fully read Bob's report so
I have been hesitating of speaking up. Let me
just comment on the following thread. I will
spend more time on Bob's detailed comments and
give feedback later. For now, please see inline
>
Thanks,
Rong
From: Greg White <<mailto:[email protected]>[email protected]>
Date: Wednesday, May 13, 2015 10:02 AM
To: Bob Briscoe <<mailto:[email protected]>[email protected]>
Cc: Richard Scheffenegger
<<mailto:[email protected]>[email protected]>, "Eddy
Wesley M. [VZ]"
<<mailto:[email protected]>[email protected]>,
Dave Taht
<<mailto:[email protected]>[email protected]>,
"<mailto:[email protected]>[email protected]"
<<mailto:[email protected]>[email protected]>,
AQM IETF list <<mailto:[email protected]>[email protected]>
Subject: Re: [aqm] draft-ietf-aqm-pie-01: review
On 5/12/15, 7:31 PM, "Bob Briscoe"
<<mailto:[email protected]>[email protected]> wrote:
My comment was in response to discovering an
arbitrary limit had been added to the Linux
implementation: "Limit the change in p per
T_UPDATE to 2%". The whole point of the rest of
the PIE algorithm is to automatically limit how
rapidly p changes, by steering a mid-course far
enough away from two cliffs known to be out there
somewhere (probably not where the theory says
they are, but at least it gives a feel).
So to write in a hard-coded limit that completely
overrides all the autotuning is IMO just plain
ignorant (I'll eat my words if someone like Rong
wrote that code!). It will make PIE unnecessarily
sluggish when conditions are changing fast and
the rest of the code has judged that it will be quite safe to react fast.
[Greg] I don't know the origin of the 2% limit,
but IMO it could very reasonably be that actual
(simulated) traffic pointed out that the control
theory prediction (based on linearized models of
steady-state Reno IIRC) really wasn't the best
guidance in all cases. In fact, I really can't
think of another reason why it would have been
added. To me your reaction precisely points out
the danger of assuming that a bit of theory
should be taken as guidance when the assumptions
underlying the theory are known to only
approximate reality in a constrained set of
scenarios. I did control theory and control
system design for a while (e.g.
<http://www.ri.cmu.edu/pub_files/pub3/white_greg_1992_1/white_greg_1992_1.pdf>âwww.ri.cmu.edu/pub_files/pub3/white_greg_1992_1/white_greg_1992_1.pdf).
I don't claim to be an expert anymore, but I
know from experience that incorrect system
modeling will result in incorrect controller
design, and even in simple systems, reality
needs to be considered strongly over theory. In
my testing of PIE, the algorithm (with the 2% limit) works.
Any AQM 'works'. As you say below, the important
test is whether it 'works' better without the
limit? And if so under what assumptions and what definition of 'works'?
I don't have simulation results with and without
the limit, but I'm going to believe (until shown
otherwise) that it was added for a real reason.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Rong: It is
designed to help in the one single TCP test
during slow start phase. In this case, queue
could quickly goes up during slow start and
demands high drop probability. In Cable Modem
SpeedTest environment, one could not afford
triggering timeout and lose throughput as
throughput is shown to customers who are
testing his/her connection speed. TCP is not a
good test for this, but that is what we do now.
As Bob mentioned in his previous emails, we
need to distinguish what are MUST, SHOULD, and
MAY items of PIE. I consider this as SHOULD, not MUST.
[Bob] AFAICT, limiting the change in beta to no
more than 2% will prevent PIE reacting fast to
slow-start. Are you saying you intended to make
PIE delay its response to a slow start? If so, ... eh? what? why?
Once a slow start has reached capacity, and is
heading towards twice capacity in the next RTT
(remembering the AQM doesn't know what a RTT is),
an AQM could take a bet on whether the flow will
finish before it gets to twice capacity, or not.
* If yes, then in hindsight the AQM wouldn't have needed to drop a packet.
* If no, then in hindsight the AQM should have
dropped a packet (in hindsight ideally when the queue first started to grow).
By arbitrarily clamping the increase at 2%, it's
making a judgement on the risk of each of these,
and on the harm that would ensue if it makes the wrong call either way.
Delaying a drop improves performance of the flow
in question if its going to end anyway (as you
say), but it certainly means the slow-start will
spike other flows harder (if the flow doesn't end of its own accord).
Good practice is for a host to use HSS (hybrid
slow-start) or a similar technique to detect the
end of slow start so it can stop SS just as it
reaches capacity, not one RTT later. By putting
off the drop that would end SS, you are rewarding
flows that do not use HSS, which is the wrong incentive.
You are also potentially confusing HSS. From
packet spacings, it thinks it's detected the
approach of the end of SS. If the drop it expects
doesn't actually appear, there's a strong danger
that the sender will reverse its guess that SS is
about to end, and move back into full SS. Then
slam into the buffers, which are actually right where it thought they were.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> Rong: I believe in the control theoretical
analysis to study the basis of the design. The
analysis does help give the guidelines of how
to choose the parameters: it may not need to be
accurate to the hundredth decimal point, but we
can not be order of magnitude off. If one does
change alpha and beta parameters (and their
relative weight) in PIE by an order of
magnitude, I am sure the system will be off.
This is the value that control theory brings
us. Of course, there are real system challenges
that we have to deal with like the above comment.
Yup.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>Rong: Bob has a question of why choosing
PI. I like the PI controller because AQM
naturally has proportional (rate) and integral
(queue length) components to it. It is the best
fit for our setup. I see it as AQM providing
two knobs for us to control it :-), what a waste not to take advantage of it!
I think I must have phrased one of my comments
badly (altho perhaps you're solely responding to a heading).
I didn't mean that you need to justify better why
you chose a PI controller. I said you need to
"Articulate the Rationale for a PI Controller". I
meant (and said) that you do not actually even
say what the aim of a PI controller is - i.e. to
keep queuing delay at the same level under a wide range of loads.
It wasn't a criticism of the choice of a PI
controller, it was intended to be a helpful hint
that you haven't explained your rationale well,
for someone reading this who doesn't know the background.
Bob
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
