[j-nsp] Juniper Buffer Bloat

[Benny Lyne Amorsen]

James Bensley <jwbensley at gmail.com> writes:

> If customers have WAN links that are slower than their LAN links -
> that is where fq-codel was designed to be implemented and that is why
> it should be implemented on the CPE. Let's be clear because to me
> there is no place for it in the core:
>
> If your customers have a WAN link that is slower than their LAN
> connectivity the congestion occurs on the WAN link and this is why
> fq-codel works best on the CPE WAN interface (you would normally shape
> the CPE WAN interface to just below the WAN link speed and use
> fq-codel for queuing so that it kicks in before you hit the WAN link
> speed and start dropping packets, the CPE has visibility of the WAN
> interface usage and buffer usage).

This is great for upstream traffic, as seen from the customer. It is the
wrong solution for the downstream. Downstream you need the PE or the
DSLAM to do the right thing, or you will be shaping traffic AFTER the
bottleneck, with all the usual problems of that approach.

The MX is really good at shaping, even taking into account ATM overhead
for the remaining ADSL deployments. You can get very close to the raw
linerate while keeping the DSLAM buffers practically empty. It is about
five years behind the state of the art for automatic queue management.

It is interesting that none of the vendors care. Delivering a
consistently low latency MPLS network would be a key differentiator.


/Benny