My bad, my memory has slipped… What you quote below is accurate…. Rong
On 7/7/15, 3:58 PM, "Francini, Andrea (Andrea)" <andrea.franc...@alcatel-lucent.com> wrote: >Hi Rong, > >In the ns2 version of (then) SFQ-PIE described in the May 2014 CableLabs >document titled "ACTIVE QUEUE MANAGEMENT IN DOCSIS 3.X CABLE MODEMS", a >different formula than the one you gave below was used to compute the >drop probability of Queue i: > >Drop_Queue_i = (Queue_lenth_i / Longest_Queue_length) * drop_prob > >i.e., the length of the longest queue was used at the denominator instead >of the aggregate queue length (Total_Queue_Length). > >I am curious about the reason that required that particular algorithmic >change. > >Thank you, > >Andrea > > >-----Original Message----- >From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of Rong Pan (ropan) >Sent: Tuesday, July 07, 2015 6:33 PM >To: Polina Goltsman; Fred Baker (fred); Toke Høiland-Jørgensen >Cc: draft-ietf-aqm-...@tools.ietf.org; Hironori Okano -X (hokano - AAP3 >INC at Cisco); AQM IETF list >Subject: Re: [aqm] FQ-PIE kernel module implementation > >FQ_PIE still uses rate estimation so the aggregated queue length would >give us more precise estimation of the latency. Actually, on second >thought, if we are going to afford the complexity of FQ, then timestamp >packets become trivial. If we use time stamp in FQ_PIE, all these concerns >would be gone. > >Having said that, drop probability can be easily tuned according to each >queue¹s queue length: >Drop_Queue_i = Queue_lenth_i/Total_Queue_length*drop_prob. This has shown >to work. Hiro¹s previous implementation of FQ_PIE has it and it is >working. Unfortunately, in his new version of FQ_PIE, this somehow gets >lost. > >He will update FQ_PIE accordingly. But I will vote for timestamp this time >as FQ is a lot more complicated than time stamp. If one decides to use FQ, >timestamp comes easy as well. > >Thanks, > >Rong > > > > > >On 7/3/15, 2:45 AM, "Polina Goltsman" <uu...@student.kit.edu> wrote: > >> >> >>On 07/03/2015 01:30 AM, Fred Baker (fred) wrote: >>>> On Jul 2, 2015, at 4:21 PM, Toke Høiland-Jørgensen <t...@toke.dk> >>>>wrote: >>>> >>>> This is, as far as I can tell from your explanation, different than >>>>what >>>> fq_pie does. >>> OK, apologies for the misinformation. >>> >>> In any event, the matter is not fundamental to fair queuing. >>According to the code and Toke in FQ-Codel there are separate state >>variables for each queue, >>whereas in FQ-PIE there is a single instance of state (see line 72-75 in >>sch_fq_pie.c >> <https://github.com/hironoriokano/fq-pie/blob/master/sch_fq_pie.c>). >>This is [should be] equivalent to a PIE queue >>which uses FQ instead of FIFO as a child queue. >> >>As I understand the FQ-Codel draft, it seems to be fundamental to >>FQ-Codel that each queue has separate state variables. >>So my question is: is it indeed fundamental ? >> >>P.S. comment on line sch_fq_pie.c should probably be updated > >_______________________________________________ >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
