Re: [aqm] FQ-PIE kernel module implementation

["Rong Pan (ropan)" <[e-mail]>]

My bad, my memory has slipped… What you quote below is accurate….

Rong

On 7/7/15, 3:58 PM, "Francini, Andrea (Andrea)"
<[e-mail]> 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:[e-mail]] 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: [e-mail]; 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" <[e-mail]> 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 <[e-mail]>
>>>>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/aqm