[j-nsp] Juniper Buffer Bloat

[James Bensley]

On Thu, 18 Oct 2018 at 16:00, Benny Lyne Amorsen
<benny+usenet at amorsen.dk> wrote:
>
> The CPE can't do anything if a large flow fills up the pipe.

You have fully missed my point.

> 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
<benny+usenet at amorsen.dk> wrote:
>
> Colton Conor <colton.conor at gmail.com> writes:
>
> > 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).

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