[c-nsp] asr1001-x : dynamic qos on virtual-template

[tim at pelican.org]

Hi Cédric,

On Monday, 15 February, 2021 15:51, "BASSAGET Cédric" <cedric.bassaget.ml at gmail.com> said:

> The problem here is that I don't know the speed on the access side. I know
> it will go up to 1Gb/s down - 250Mb/s up. But it can be lower than that, as
> it's GPON architecture.
> We don't sell a fixed (guaranteed) bandwidth to customers. We sell it as
> "up to 1Gb/s down - 250Mb/s up" as we are not able to guaranty bandwidth.

That's contention in the network, though, not speed to the CPE, unless I'm missing something.  Nothing's going to report in a PPP connection how much traffic is making it through the access layer to the LNS.  Not the same thing as DSL/FTTC, where you've got a physical negotiation going on between the CPE and the DSLAM to agree the upstream / downstream speeds of a particular copper pair, before you even get to any further contention 

So you can treat it as:

- You have 1G from the LNS to the CPE.  You can choose which 1G of packets to put into that sessions.  Sometimes the access layer will discard some of those packets, you don't have any control over that.  Make a 1G shaper, with your voice priority class in it.  Voice won't get discarded in favour of data in the parts you control.

- You have some amount of bandwidth from the LNS to the CPE that's (almost) always achievable - what that is will depend on your exact access layer set-up, split ratio, etc.  Maybe that's 250M downstream.  You build your shaper around that value, with your voice priority class in it.  You've got control of exactly which 250M stream leaves your LNS, with a high expectation that all of those packets reach the CPE - BUT the customer will never get more throughput than that, even if all the other links on the GPON node are idle.

It's really down to whether you're after higher-bandwidth with "intelligent discard" QoS, or something closer to a guaranteed but lower bandwidth.

I'm not aware of anything in the FTTH space that would let you detect congestion in the access layer and back off the parent shaper accordingly.  Neither end has that info, without you building some kind of active probes of your own.

What's the problem you're trying to solve?  Customers with >1G of traffic trying to go downstream, and you need to make sure data packets are discarded rather than voice?

Cheers,
Tim.