[j-nsp] Juniper Buffer Bloat

[Benny Lyne Amorsen]

Colton Conor <colton.conor at gmail.com> 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