[j-nsp] Juniper Buffer Bloat

[James Bensley]

On Thu, 18 Oct 2018 at 10:36, Benny Lyne Amorsen
<benny+usenet at amorsen.dk> wrote:
>
> 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.

Hi Benny,

This is not correct. Again we are being unclear here (maybe my
fault!). What I was saying above was:

> > If your customers have a WAN link that is slower than their LAN
> > connectivity the congestion

Should have been bufferbloat ^

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

The OP asked about fq-codel in Juniper tin for bufferbloat. When using
fq-codel (in my experience which was my home ADSL line with OpenWRT
router) one has to tell fq-codel the link speed (so as I said above,
you set it to slightly lower than your link speed so that it kicks in
before packets are dropped). It is actually enough to use fq-codel on
the CPE only, to fix bufferbloat, nothing is required on the provider
side, that is the whole point, the CPE buffers are too large, so
fq-codel in the core doesn't make sense as there should be minimal
bufferbloat there. As Saku mentioned buffers should be kept small
inside your provider network, this is a great short video on this
subject: https://www.youtube.com/watch?v=y3mkhUq-cO4

A by-product of using fq-codel on the CPE (because it is both AQM and
packet scheduling combined!) is that when you configure it and
configure it to ~99% of the actual speed UP and DOWN it will actually
have positive effects on both upload and download before either your
PE policer kicks in or the WAN link drops packets due to congestion,
the PE doesn't need to do anything. Unless my understanding is wrong,
fq-codel schedules the outbound packets and will allow you to fill
your link in the downstream with multiple concurrent IP flows without
anyone of them being starved by another. My own tests confirmed this
on my home ADSL, I could smash the link with torrents and still watch
NetFlix without issue. There are some examples you can see here:
https://www.bufferbloat.net/projects/codel/wiki/RRUL_Rogues_Gallery/

Cheers,
James.