[j-nsp] Juniper Buffer Bloat

[Colton Conor]

I was wondering if Juniper supports anything like fq-codel to prevent
buffer bloat? Specifically we would like to do rate shaping and subscriber
management on core Juniper MX's. However, most network devices do simple
buffers and queuing that does not work well compared to fq-codel and newer
algorithms. Does anyone have advice when it comes to Juniper?
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[James Bensley]

Post by Colton Conor
I was wondering if Juniper supports anything like fq-codel to prevent
buffer bloat? Specifically we would like to do rate shaping and
subscriber
management on core Juniper MX's. However, most network devices do simple
buffers and queuing that does not work well compared to fq-codel and newer
algorithms. Does anyone have advice when it comes to Juniper?

Hi Colton,

I'm pretty sure Juniper don't have anything like fq-codel in any of their products however, the place to do that would be on the CPE or edge access switch/router not your core.

Normally one would rate limit the customer on CPE LAN ingress and egress if you're doing multi-colour policing, or CPE WAN ingress and egress if just hard policing, or CPE WAN egress and PE egress if doing shaping. You don't want your customer to blast traffic into your network and this have to carry those packets across your core only to them drop them on your expensive subscriber management box.

One normally wants to drop excess packets as close to the source as possiblr. So for that reason you want fq-codel on your CPE.

Cheers,
James.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Colton Conor]

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?

Post by James Bensley

Post by Colton Conor
I was wondering if Juniper supports anything like fq-codel to prevent
buffer bloat? Specifically we would like to do rate shaping and subscriber
management on core Juniper MX's. However, most network devices do simple
buffers and queuing that does not work well compared to fq-codel and newer
algorithms. Does anyone have advice when it comes to Juniper?

Hi Colton,
I'm pretty sure Juniper don't have anything like fq-codel in any of their
products however, the place to do that would be on the CPE or edge access
switch/router not your core.
Normally one would rate limit the customer on CPE LAN ingress and egress
if you're doing multi-colour policing, or CPE WAN ingress and egress if
just hard policing, or CPE WAN egress and PE egress if doing shaping. You
don't want your customer to blast traffic into your network and this have
to carry those packets across your core only to them drop them on your
expensive subscriber management box.
One normally wants to drop excess packets as close to the source as
possiblr. So for that reason you want fq-codel on your CPE.
Cheers,
James.

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Saku Ytti]

Hey Colton,

The RFC mentions that it's not good fit for high flow locations or
locations where flows shouldn't be treated fairly. Both are largely
true in SP.

a) you have lot of flows, much more than you have hardware queues
b) you don't actually want to be flow-fair you want to be
customer-fair Otherwise greedy customer just starts multiple TCP
session to transfer single file.

Backbone=>access seems solvable, if nothing else, you could use VLAN
to communicate to backbone which packet is for which customer, to give
customer-fair queueing. But Backbone=>Backbone and Backbone<=>Peering
would be rather challenging to be customer-fair, however as flow count
is massive, statistical per-packet based queueing tends to work
reasonably. Buffer bloat in backbone is configuration mistake, the
interfaces can have second of buffering, if it's also intended to
support network edges, and allowing all of that to be used in backbone
interface is just incorrect configuration, all vendors do allow you to
set buffer sizes and you should limit your backbone queueing to low
milliseconds 5-10ms is lot.

Post by Colton Conor
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?

Post by James Bensley

Post by Colton Conor
I was wondering if Juniper supports anything like fq-codel to prevent
buffer bloat? Specifically we would like to do rate shaping and subscriber
management on core Juniper MX's. However, most network devices do simple
buffers and queuing that does not work well compared to fq-codel and newer
algorithms. Does anyone have advice when it comes to Juniper?

Hi Colton,
I'm pretty sure Juniper don't have anything like fq-codel in any of their
products however, the place to do that would be on the CPE or edge access
switch/router not your core.
Normally one would rate limit the customer on CPE LAN ingress and egress
if you're doing multi-colour policing, or CPE WAN ingress and egress if
just hard policing, or CPE WAN egress and PE egress if doing shaping. You
don't want your customer to blast traffic into your network and this have
to carry those packets across your core only to them drop them on your
expensive subscriber management box.
One normally wants to drop excess packets as close to the source as
possiblr. So for that reason you want fq-codel on your CPE.
Cheers,
James.

_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Benny Lyne Amorsen]

Post by James Bensley
I'm pretty sure Juniper don't have anything like fq-codel in any of
their products however, the place to do that would be on the CPE or
edge access switch/router not your core.

The CPE is a great place to put fq-codel for upstream traffic. For
downstream traffic you need the PE device to do the queueing. Having
fq-codel available with hierarchical queueing on the MX would be
amazing.

Apart from that, Juniper does make CPE devices...


/Benny

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Colton Conor]

Benny,

That is what I was thinking. Throttle the customer upstream traffic at the
CPE so they can't upload anymore traffic into the network, and throttle
their downstream traffic at the provider edge (PE) or access switch so they
can't congest any more links than required.

For fq-codel on the CPE, fq-codel runs on linux / openwrt, so there are
many options there.

I am more wondering how to do this properly on the provider edge side. I
mentioned backbone/core before, and I really meant to say provider edge. On
the provider edge, that is mostly Juniper, so we can't just implement
fq-codel. So the question lines does Juniper have anything like fq-codel? I
know Juniper has the ability to shape downstream traffic, but can it do it
in a manner that doesn't increase latency like fq-codel?

Post by Benny Lyne Amorsen

Post by James Bensley
I'm pretty sure Juniper don't have anything like fq-codel in any of
their products however, the place to do that would be on the CPE or
edge access switch/router not your core.

The CPE is a great place to put fq-codel for upstream traffic. For
downstream traffic you need the PE device to do the queueing. Having
fq-codel available with hierarchical queueing on the MX would be
amazing.
Apart from that, Juniper does make CPE devices...
/Benny

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Benny Lyne Amorsen]

Post by Colton Conor
I am more wondering how to do this properly on the provider edge
side. I mentioned backbone/core before, and I really meant to say
provider edge. On the provider edge, that is mostly Juniper, so we
can't just implement fq-codel. So the question lines does Juniper have
anything like fq-codel? I know Juniper has the ability to shape
downstream traffic, but can it do it in a manner that doesn't increase
latency like fq-codel?

You can avoid increasing latency by making the per-queue size
sufficiently small. The MX can do Random Early Drop, so it is right at
where the state of the art was before the bufferbloat project. If you
tune it perfectly, you can probably get close to the "codel" part of
fq-codel. The advantage of codel over RED is primarily that codel
can do the same job without tuning.

However, the MX does not have anything resembling the flow queue part of
fq-codel -- the part where it is determined which flows are causing the
queue to fill. This is the part where header information for each packet
is hashed and the packet is placed in one of (by default) 1024
queues. The MX does currently do that kind of thing, but the hashing
part could certainly be done with a software upgrade -- aggregated
ethernet and similar does it already. However, it would soon run out of
hardware queues. It is typical to use 4 or 8 queues per subinterface on
an MX, a long way from the 1024 that fq-codel likes.


/Benny

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Colton Conor]

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. Would you use DPI, fq-codel, or something else? Yes, we
know about DSL bonding, GPON, and other access technologies that provide
more speed, but that is not always economically viable.

Post by Benny Lyne Amorsen

Post by Colton Conor
I am more wondering how to do this properly on the provider edge
side. I mentioned backbone/core before, and I really meant to say
provider edge. On the provider edge, that is mostly Juniper, so we
can't just implement fq-codel. So the question lines does Juniper have
anything like fq-codel? I know Juniper has the ability to shape
downstream traffic, but can it do it in a manner that doesn't increase
latency like fq-codel?

You can avoid increasing latency by making the per-queue size
sufficiently small. The MX can do Random Early Drop, so it is right at
where the state of the art was before the bufferbloat project. If you
tune it perfectly, you can probably get close to the "codel" part of
fq-codel. The advantage of codel over RED is primarily that codel
can do the same job without tuning.
However, the MX does not have anything resembling the flow queue part of
fq-codel -- the part where it is determined which flows are causing the
queue to fill. This is the part where header information for each packet
is hashed and the packet is placed in one of (by default) 1024
queues. The MX does currently do that kind of thing, but the hashing
part could certainly be done with a software upgrade -- aggregated
ethernet and similar does it already. However, it would soon run out of
hardware queues. It is typical to use 4 or 8 queues per subinterface on
an MX, a long way from the 1024 that fq-codel likes.
/Benny

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Benny Lyne Amorsen]

This post might be inappropriate. Click to display it.

[Colton Conor]

So what kind of classification queues do you use for the customer traffic
assuming its all just best effort internet traffic?


So what do you think about an inline X86 sever running linux with fq-codel
installed before the Multi-service access node? That is basically what
preseem.com is doing for the wireless isp market.

Post by Benny Lyne Amorsen

Post by Colton Conor
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. Would you use DPI, fq-codel, or something else?

The approach $dayjob went with is to classify customer traffic into 3
queues plus one for network control, and then do RED with a size-limited
queue per subif. It works well when traffic gets classified
correctly. Tuning RED is challenging and it is tempting to increase
buffer size to give RED a bit more of a chance to react smoothly.
Even so, one aggressive flow can be quite detrimental to everything else
in the samme traffic class.
fq-codel would achieve better results with much less work.
/Benny

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[James Bensley]

Post by Colton Conor
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?

...

Post by Colton Conor
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.

Post by Colton Conor

"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 juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Benny Lyne Amorsen]

Post by James Bensley
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
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.

The MX is really good at shaping, even taking into account ATM overhead
for the remaining ADSL deployments. You can get very close to the raw
linerate while keeping the DSLAM buffers practically empty. It is about
five years behind the state of the art for automatic queue management.

It is interesting that none of the vendors care. Delivering a
consistently low latency MPLS network would be a key differentiator.


/Benny

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[James Bensley]

On Thu, 18 Oct 2018 at 10:36, Benny Lyne Amorsen

Post by Benny Lyne Amorsen

Post by James Bensley
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
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

Post by Benny Lyne Amorsen

Post by James Bensley
If your customers have a WAN link that is slower than their LAN
connectivity the congestion

Should have been bufferbloat ^

Post by Benny Lyne Amorsen

Post by James Bensley
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:

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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Colton Conor]

This post might be inappropriate. Click to display it.

[Benny Lyne Amorsen]

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
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Colton Conor]

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?

Post by Benny Lyne Amorsen

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

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Benny Lyne Amorsen]

Post by Colton Conor
So does putting an in-line X86 box that supports FQ-Codel before the DSLAM
solve the problem in your point of view?

Yes that would solve the problem.

Post by Colton Conor
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?

Yes, you would have the opposite problem from the CPE-only solution --
limiting upstream traffic only works as long as the flows are being
nice.

If there is a CPE anyway, and you don't care about one direction having
lower quality shaping, it seems more obvious to put the shaping on the
CPE. Maintaining a Linux server with a whole lot of bridge interfaces is
certainly possible. I would be very interested in knowing how that
solution performs.


/Benny

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[James Bensley]

On Thu, 18 Oct 2018 at 16:00, Benny Lyne Amorsen

Post by Benny Lyne Amorsen
The CPE can't do anything if a large flow fills up the pipe.

You have fully missed my point.

Post by Benny Lyne Amorsen
It cannot work reliably if there is WAN-side congestion, which makes it
less useful for cable or (non-point-to-point) wireless networks.

With fq-codel on the CPE it is active queue management and packet
scheduling. Each flow hashes into a separate queue, whereas a typical
CPE has a simple FIFO queue that contains all flows. To prevent
bufferbloat and improve inter-flow scheduling fq-codel will prioritise
ACKs and SYNs; if you have an existing flow filling your pipe a new
flow is given a change to grow it's window and ramp up it's
throughput. fq-codel uses a form of DRR, this stops an existing flow
from prevent any new flows (that includes ICMP and UDP) from being
starved compared to a simple FIFO pipe.

Access networks (cable and xDSL) have seen excellent results with just
fq-codel on the CPE. If you receive a flow you didn't ask for and is
too big for your to handle, that is essentially a DoS, so all normal
flows are requested by the CPE side, which means fq-codel is aware of
all flows and can scheduling them appropriately such that no one flow
is starved. It's much more than just basic ingress/egress
shaping/policing which is what you seem to be comparing.


On Fri, 19 Oct 2018 at 14:38, Benny Lyne Amorsen

Post by Benny Lyne Amorsen

Post by Colton Conor
So does putting an in-line X86 box that supports FQ-Codel before the DSLAM
solve the problem in your point of view?

Yes that would solve the problem.

I still think you're mixing your requirements (policing/shaping vs
buffer management).

Post by Benny Lyne Amorsen

Post by Colton Conor
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?

If your DSLAMs support policing/shaping they will have the line
sync-speed. If you use DHCP you can use Option 82 to insert the sync
speed into the DHCP request. If you use PPPoA/E you can insert the
sync speed into the RADIUS request.

I don't think you want fq-codel on the DSLAMs, if too much complexity,
DSLAMs are usually not that smart (for good reason!). Also if users
regularly congest their links and have problems, they need a bandwidth
upgrade.

I mentioned previously that with full-rate access circuits e.g. a
100Mbps Ethernet fibre link, if you want to police that to 10Mbps,
that should happen at the edge. If you have adaptive rate customers
e.g. 20Mbps ADSL that are all allowed to use their links at 100%, you
can terminate them on a BNG/LNS and the BNG can apply a policer/shaper
based on the sync speed, and you can implement basic QoS (just a 2
class BE and priority/LLQ) on that device which is specialised for the
job (a BNG will support per-subscriber/session queuing and support
thousands of queues, a DSLAM might not).

Cheers,
James.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Mark Tinka]

Post by James Bensley
Normally one would rate limit the customer on CPE LAN ingress and egress if you're doing multi-colour policing, or CPE WAN ingress and egress if just hard policing, or CPE WAN egress and PE egress if doing shaping. You don't want your customer to blast traffic into your network and this have to carry those packets across your core only to them drop them on your expensive subscriber management box.

This wouldn't be practical if you do not manage the CPE.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp