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:[email protected]] 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: [email protected]; 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" <[email protected]> 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 <[email protected]> >>>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 [email protected] https://www.ietf.org/mailman/listinfo/aqm _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
