On Thu, 18 Oct 2018 at 16:00, Benny Lyne Amorsen <[email protected]> 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 <[email protected]> wrote: > > Colton Conor <[email protected]> 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. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
