Rong,
Can you please elaborate on how packet timestamps would be used with FQ-PIE?
It is not obvious.
Is there a written description of FQ-PIE? Does it describe use of timestamps
as well?
For equation -
Drop_Queue_i = (Queue_lenth_i / Longest_Queue_length) * drop_prob
is there a fast algorithm for computing Longest_Queue_length for large number
of queues?
Thanks,
Anil
-----Original Message-----
From: aqm [mailto:[email protected]] On Behalf Of Rong Pan (ropan)
Sent: Tuesday, July 07, 2015 7:00 PM
To: Francini, Andrea (Andrea); 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
My bad, my memory has slipped. What you quote below is accurate..
Rong
On 7/7/15, 3:58 PM, "Francini, Andrea (Andrea)"
<[email protected]> 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:[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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_hironoriokano_fq-2Dpie_blob_master_sch-5Ffq-5Fpie.c&d=AwIGog&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=ZhwYVG7trmH21ngvxzmFV1-mkreFJJEBMToS4eye5KU&s=90jYjRUO0hcRiGb1Kd3owxwftY2Pd3WrK2Hs-sq619E&e=
>> >).
>>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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_aqm&d=AwIGog&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=ZhwYVG7trmH21ngvxzmFV1-mkreFJJEBMToS4eye5KU&s=hAK-RY-wfp0zIHzoazmmKJ03TrFqQ2TM9SqbDo_ku3Q&e=
>
_______________________________________________
aqm mailing list
[email protected]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_aqm&d=AwIGog&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=ZhwYVG7trmH21ngvxzmFV1-mkreFJJEBMToS4eye5KU&s=hAK-RY-wfp0zIHzoazmmKJ03TrFqQ2TM9SqbDo_ku3Q&e=
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm