On Wed, 17 Oct 2018 at 21:48, Colton Conor <[email protected]> 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 <[email protected]> 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 <[email protected]> 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. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
