Colton Conor <[email protected]> writes: > I am more wondering how to do this properly on the provider edge > side. I mentioned backbone/core before, and I really meant to say > provider edge. On the provider edge, that is mostly Juniper, so we > can't just implement fq-codel. So the question lines does Juniper have > anything like fq-codel? I know Juniper has the ability to shape > downstream traffic, but can it do it in a manner that doesn't increase > latency like fq-codel?
You can avoid increasing latency by making the per-queue size sufficiently small. The MX can do Random Early Drop, so it is right at where the state of the art was before the bufferbloat project. If you tune it perfectly, you can probably get close to the "codel" part of fq-codel. The advantage of codel over RED is primarily that codel can do the same job without tuning. However, the MX does not have anything resembling the flow queue part of fq-codel -- the part where it is determined which flows are causing the queue to fill. This is the part where header information for each packet is hashed and the packet is placed in one of (by default) 1024 queues. The MX does currently do that kind of thing, but the hashing part could certainly be done with a software upgrade -- aggregated ethernet and similar does it already. However, it would soon run out of hardware queues. It is typical to use 4 or 8 queues per subinterface on an MX, a long way from the 1024 that fq-codel likes. /Benny _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
