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
