Re: [aqm] draft-ietf-aqm-pie-01: review

[Bob Briscoe <[e-mail]>]

Rong,

On 22/05/15 21:49, Rong Pan (ropan) wrote:
> Content-Language: en-US Content-Type: multipart/alternative; 
> boundary="_000_D184CA8CF0F2ropanciscocom_"
> >>[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?

I am concerned that this arbitrary limit on changes to beta might have 
been introduced for the specific traffic used in the CableModem 
SpeedTests. That might be a good representation of tomorrow's traffic, 
but it might not. For instance, did the TCP implementations use hybrid 
slow-start (HSS), which is now the default in Linux?

My main concern is that slow-start is probably going to become a major 
focus of improvement over the next few years. Hybrid slow-start is an 
improvement, but a lot more can and will be done. If PIE assumes that 
slow-start is like Van Jacobson designed it, and guesses when to 
introduce losses on that assumption, In future, it could make it much 
more difficult to improve slow start 'properly' (in the end-systems).

So, yes, in summary, MAY would be appropriate. Perhaps with a sentence 
saying more research is needed on the interaction between AQMs and 
improvements to the slow-start algorithm (e.g. HSS).


Bob

PS. Pls note my new interim email @.

Sorry for extended delay replying - your mail arrived after I left my 
office for the last time (I've left BT).
I'm still "between jobs", but I'm trying to catch up on unfinished threads.


>
> Thanks,
>
> Rong
>
>
> From: Bob Briscoe <[e-mail] <mailto:[e-mail]>>
> Date: Friday, May 22, 2015 9:38 AM
> To: rong <[e-mail] <mailto:[e-mail]>>
> Cc: Richard Scheffenegger <[e-mail] <mailto:[e-mail]>>, 
> "[e-mail] 
> <mailto:[e-mail]>" 
> <[e-mail] 
> <mailto:[e-mail]>>, Dave Taht 
> <[e-mail] <mailto:[e-mail]>>, Greg White 
> <[e-mail] <mailto:[e-mail]>>, AQM IETF list 
> <[e-mail] <mailto:[e-mail]>>, "Eddy Wesley M. [VZ]" 
> <[e-mail] <mailto:[e-mail]>>
> 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 <[e-mail] <mailto:[e-mail]> >
>> Date: Wednesday, May 13, 2015 10:02 AM
>> To: Bob Briscoe <[e-mail] <mailto:[e-mail]>>
>> Cc: Richard Scheffenegger <[e-mail] <mailto:[e-mail]>>, 
>> "Eddy Wesley M. [VZ]" <[e-mail] 
>> <mailto:[e-mail]> >, Dave Taht <[e-mail] 
>> <mailto:[e-mail]>>, "[e-mail] 
>> <mailto:[e-mail]>" 
>> <[e-mail] 
>> <mailto:[e-mail]>>, AQM IETF list 
>> <[e-mail] <mailto:[e-mail]>>
>> Subject: Re: [aqm] draft-ietf-aqm-pie-01: review
>>
>>
>>
>> On 5/12/15, 7:31 PM, "Bob Briscoe" <[e-mail] 
>> <mailto:[e-mail]>> 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_fifiles/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 
> [e-mail] https://www.ietf.org/mailman/listinfo/aqm 


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/