[j-nsp] Juniper Buffer Bloat

[James Bensley]

On Wed, 17 Oct 2018 at 21:48, Colton Conor <colton.conor at gmail.com> wrote:
>
> James,
>
> Thanks for the response. However, if you are just shaping at the CPE, then there could be bottlenecks between the CPE and core router causing the bufferbloat right? Example, if you have a wireless network, DSL network, CMTS network, etc you bottleneck is going to be that wireless accesses point, that DSLAM, or that CMTS, and not the CPE. Packets are going to build up on the access device not the CPE right?
...
On Thu, 18 Oct 2018 at 00:19, Colton Conor <colton.conor at gmail.com> wrote:
>
> 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.

These are two separate issues. I'm confused as to why you are asking
about fq-codel in the core - I think you may have misunderstood
something.

If your DSLAM/access-switch/MSAN has run out of backplane or backhaul
capacity it needs upgrading. fq-codel isn't the solution to that
problem.

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

If your customers have high speed WAN links 100M/1G/10G etc. that is
the same speed or faster than the LAN connectivity AND you're
implemented the policing/shaping on your edge device (or worse -
deeper into your network) then the CPE has no visibility of this. Now
you have the problem that you are transporting traffic which will be
dropped. This is a bigger issue than fq-codel because, customers could
be congesting important shared links (access-switch/DSLAM/MSAN
uplinks) with traffic that will eventual be dropped - so the
congestion shouldn't have occurred in the first place.

Taking this full circle - fq-codel is aimed at addressing bufferbloat,
not congested up-links on the devices in your network, please note
that these are two seperate problems. A port/link/line card upgrade
fixes the congested core/backhaul link problem.

On Thu, 18 Oct 2018 at 06:59, Mark Tinka <mark.tinka at seacom.mu> wrote:
>
> > On 17/Oct/18 22:06, James Bensley wrote:
> > "words about policing on the CPE and not in the core"
>
> This wouldn't be practical if you do not manage the CPE.

Yes it would - the general rule of thumb still applies: police on your
access-switch/DSLAM/MSAN/whatever rather than backhauling traffic that
is later going to be dropped - surely not your not disputing the
concept of saving resources but dropped "doomed" traffic earlier?

There are reasons to do the policing on the BNG/LNS/subscriber
management gateway - e.q. complex QoS but Colton hasn't mention any
QoS so I can only comment on the info provided.

Cheers,
James.