> On May 3, 2017, at 07:36, <[email protected]>
> <[email protected]> wrote:
>
>> Fra: Nils Andreas Svee <[email protected]>
>>
>> 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
> [email protected]
> https://lists.bufferbloat.net/listinfo/cake
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
