[j-nsp] Juniper Buffer Bloat

[Colton Conor]

I am sorry I didn't mean to start an argument on the list.

For clarification, the DSLAM uplinks (10G) and backplane doesn't have a
limit that we are hitting. However, the CO DSL ports is the first place
where there is a limit. Example

10G Internet Connect ---> 10 G Port on Juniper MX204 --------> 10G Uplink
on Adtran TA 5K DSLAM -----20Mbps Download / 1Mbps upload DSL
Connection---->Customer DSL Modem in Bridge Mode---->1G Ethernet Wan Router

In this scenario, I bottleneck would be the 20Mbps port on the DSLAM in the
central office. That is where the buffers would start to build up for
downstream traffic right? On the upstream side, traffic would start to
buffer on the Customers DSL modem? In both secenatios, the DSLAM and
Customer's DSL modem have limited knobs to modify, so if I wanted to
implement something like fq-codel it would have to be done before the DSLAM
for downstream traffic, and after the DSL modem for upstream traffic right?
Ideally I would like to rate limit both up and downstream before the DSLAM
as we don't always have control of the CPE equipment.







On Thu, Oct 18, 2018 at 7:02 AM James Bensley <jwbensley at gmail.com> wrote:

> 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.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>