> On Jun 10, 2015, at 1:56 AM, Polina Goltsman <[email protected]> wrote: > > Hello all, > > If I understood the code correctly, in fq_pie there is a single PIE instance > that controls all "fq" queues. In contrast in fq_codel there is a separate > instance of codel for each queue. Is this the case? If it is, doesn't it > contradict with original idea of fq_something where each queue is supposed to > be managed by "its own" AQM? > > Thanks in advance, > Best Regards, > Polina
Sorry for the delay in getting back to you. I'm not sure it makes sense to discuss fq_codel having a separate instance for each queue. It could, I suppose (by having a separate target delay value for each queue), but... the codel algorithm timestamps packets on enqueue and compares the difference between that timestamp and the current time against a common target delay value on dequeue. If that comparison shows that the induced latency is greater than some value, the packet is discarded with some probability. In the linux fq algorithm, or its counterpart in fq_codel, there is one queue for mice and zero or more separate queues for elephant flows. It is technically possible for a packet to be delayed inordinately long in the "mice" queue, if the interface is undergoing a long term overload, but that would be pretty unusual (can you say "DDOS"?). More probably, discards happen to the "elephant" data flows and their corresponding queues, as they are more likely to build a backlog. The fq_pie algorithm operates similarly, with the exception that (like pie without fq) the entire pie algorithm happens at enqueue or in a background process. The background process determines the rate at which drops occur, and the algorithm at enqueue drops at that rate. This has the down side that it can happen to "mice" data flows with a little greater probability than fq_codel (it's not something one would tie to DDOS, it's simply the probability that any given arriving packet is selected). However, something that is true of codel without fq and true of any other AQM algorithm, if packets are selected for mark/drop with some probability, packets from elephant flows are more likely to be selected simply because there are more of them. > On 06/05/2015 12:06 AM, Hironori Okano -X (hokano - AAP3 INC at Cisco) wrote: >> Hi all, >> >> I’m Hironori Okano and Fred’s intern. >> I’d like to let you know that I have implemented FQ-PIE as a linux kernel >> module “fq-pie" and iproute2 for fq-pie. >> This was done in collaboration with others at Cisco including Fred Baker, >> Rong Pan, Bill Ver Steeg, and Preethi Natarajan. >> >> The source codes are in my github repository. I attached patch file >> “fq-pie_patch.tar.gz” to this email also. >> I’m using the latest linux kernel >> (git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git) >> >> fq-pie kernel module >> https://github.com/hironoriokano/fq-pie.git >> <https://github.com/hironoriokano/fq-pie.git> >> >> iproute2 for fq-pie >> https://github.com/hironoriokano/iproute2_fq-pie.git >> <https://github.com/hironoriokano/iproute2_fq-pie.git> >> >> If you have any comments, please reach out to me. >> >> Best regards, >> >> Hironori Okano >> [email protected] <mailto:[email protected]> > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
