>>[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). [RONG]: because the queue is filling up very fast during TCP's slow start, dropping too quickly would cause a timeout. As you mentioned, hopefully they will finish. In CableModem SpeedTest scenarios, however, we need to show the speed in the fast 10sec or so. The test flow is very long and we can not afford to incur a time out. In generic access link scenarios when flow multiplexing is low, this twist should help. Clapping it makes the convergences time slower. However, the drop probability should eventually catch up. Maybe changing this to "MAY" is more appropriate? Thanks, Rong From: Bob Briscoe <[email protected]<mailto:[email protected]>> Date: Friday, May 22, 2015 9:38 AM To: rong <[email protected]<mailto:[email protected]>> Cc: Richard Scheffenegger <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Dave Taht <[email protected]<mailto:[email protected]>>, Greg White <[email protected]<mailto:[email protected]>>, AQM IETF list <[email protected]<mailto:[email protected]>>, "Eddy Wesley M. [VZ]" <[email protected]<mailto:[email protected]>> Subject: Re: [aqm] draft-ietf-aqm-pie-01: review 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 <[email protected]<mailto:[email protected]> > Date: Wednesday, May 13, 2015 10:02 AM To: Bob Briscoe <[email protected]<mailto:[email protected]>> Cc: Richard Scheffenegger <[email protected]<mailto:[email protected]>>, "Eddy Wesley M. [VZ]" <[email protected]<mailto:[email protected]> >, Dave Taht <[email protected]<mailto:[email protected]>>, " [email protected]<mailto:[email protected]>" < [email protected]<mailto:[email protected]>>, AQM IETF list <[email protected]<mailto:[email protected]>> Subject: Re: [aqm] draft-ietf-aqm-pie-01: review On 5/12/15, 7:31 PM, "Bob Briscoe" <[email protected]<mailto:[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. ‎www.ri.cmu.edu/pub_files/pub3/white_greg_1992_1/white_greg_1992_1.pdf<http://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
