[j-nsp] Juniper Buffer Bloat

Colton Conor colton.conor at gmail.com
Wed Oct 17 19:18:50 EDT 2018


Benny,

Great information! So what would you do to avoid congest on access
networks? Example DSLAM's fed by 10G links. The 10G link is no where near
capacity, but customers are individually maxing out their 20Mbps by 1Mbps
DSL connection. Would you use DPI, fq-codel, or something else? Yes, we
know about DSL bonding, GPON, and other access technologies that provide
more speed, but that is not always economically viable.



On Wed, Oct 17, 2018 at 5:57 PM Benny Lyne Amorsen <benny+usenet at amorsen.dk>
wrote:

> 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
>
>


More information about the juniper-nsp mailing list