Re: [Cake] Recomended HW to run cake and fq_codel?

[Sebastian Moeller <moeller0@gmx.de>]

> On May 3, 2017, at 07:36, <erik.taraldsen@telenor.com> <erik.taraldsen@telenor.com> wrote:
> 
>> Fra: Nils Andreas Svee <me@lochnair.net>
>> 
>> just fine, but I'd probably pick the ER-X-SFP for the beefier CPU, if
>> only to get some extra headroom. 
> 
> Then ER-X-SFP it is. 
> 
> 
>> DSL tends to suck pretty (read: very) bad without proper shaping, I
>> know. On that note, are you planning to run an AQM on both ends of the
>> bottleneck, or shape ingress traffic via a IFB device? CAKE helps a lot
>> when running on ingress, but it can't come close to running on both
>> ends.
> 
> I intended to only shape on egress for this experiement.  

	Okay...

> Let downstream be handled by the BRAS's policies (Juniper ERX in our case).  

	So my ISP, (DTAG) does ingress shaping at the BRAS/BNG level and it is not terrible (see https://www.dslreports.com/speedtest/6796065 ) it still is a far cry from performance with proper ingress shaping (see: https://www.dslreports.com/speedtest/9507819 ). My interpretation of that is that the BRAS/BNG ingress shaper is too relaxed and the link behaves noticeably better if that shaper is exercised only rarely. If seen as a last line of defense against extreme latency under load increases it still has some merits though.
	Question: as an ISP what is your rationale to implement a shaper at the BRAS? Simply the fact that DSLAMs/MSANs are not capable to do it, or do you also need this to make sure there is always room for your own VoIP packets?


> Most of the customer "speed" complaints come from not throughput but latency.  And that latency is mostly ADSL/VDSL customers with large uploads to cloud services.  So I think that we will by handling the upstream better make a large improvement.  

	Well any shaping is going to help and egress shaping can be implemented at literally no bandwidth sacrifice so more power to you! I would humbly like to recommend a few issues regarding ADSL links:
0) get rid of all non-essential encapsulations, use DHCP option 82 instead of PPPoE, rethink the need for VLAN tags,
1) make sure to properly account for all the quirks of ATM’s AAL5 encapsulation (see cake’s atm keyword or “man tc-stab”)
2) preferably hoist your ADSL customers into the present and get your device manufacturers to implement PTM for adsl modems making 1) above much less involved ;)

3) as proposed by others, if you can get your CPE manufacturers to implement BQL for the xDSL interface than you might not even need to run a shaper on egress. Even though cake offers so much goodness with its different isolation modes that allow to configure per-internal-host fairness that even if the modem has BQL it still might be a customer friendly idea to run cake on the modem. I note that many lede/openwrt users seem to be quite happy with per-internal host fairness (but typically also want this on ingress, and for that I believe you need to have an ingress shaper on the CPE where it can peek into the NAT tables to figure out the internal IPs)

> But, hey, I call it an experiemnt because it is an experiemnt.  If we see significant improvements by using IFB for downstream as well.  

My prediction is that per-internal-host fairness probably makes it desirable to have an ingress shaper as well… (If you include a dedicated bit-torrent host into your test matrix this might become obvious ;) )

Best Regards
	Sebastian


> Then we will try to see what we can do to implement this.
> 
> 
> -Erik
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake