[j-nsp] Juniper Buffer Bloat

Colton Conor colton.conor at gmail.com
Fri Oct 19 09:29:51 EDT 2018


Benny,

So does putting an in-line X86 box that supports FQ-Codel before the DSLAM
solve the problem in your point of view? It would have to know for each
subscriber what their speed was of course to do the proper rate limiting.
If this device did rate limiting both on downstream and upstream would
there be any reason to also have a fq-codel enabled CPE?

Are there any commercial vendors that use FQ-codel in their products since
Juniper clearly does not?

On Thu, Oct 18, 2018 at 10:01 AM Benny Lyne Amorsen <benny+usenet at amorsen.dk>
wrote:

> James Bensley <jwbensley at gmail.com> writes:
>
> > 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.
>
> The CPE can't do anything if a large flow fills up the pipe. If the
> packets are dropped before the CPE sees them, it does not get to pick
> which ones are nice and which ones aren't. It can hope that the "bad"
> flow happens to be TCP so the packet loss induced by fq-codel causes it
> to back off, but it might not be.
>
> > 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.
>
> Again, that is great if your flows are well-behaved TCP or rate-adapting
> UDP.
>
> > 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.
>
> As long as the flows react well to packet loss.
>
> > 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/
>
> I do not doubt that you can get very far by shaping at the wrong end of
> the link. You absolutely can. But it means you depend on a) knowing the
> constant speed of the link and b) your flows being nice.
>
> It cannot work reliably if there is WAN-side congestion, which makes it
> less useful for cable or (non-point-to-point) wireless networks. In
> those cases, fq-codel on the CPE side will believe that the downstream
> pipe still has room, so it will not throttle the flows.
>
>
> /Benny
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


More information about the juniper-nsp mailing list