[c-nsp] qos for broadband aggregation

[Mike]

On 05/13/2014 05:54 PM, Tony wrote:
> Hi Mike,
>
> In a nutshell:
>
> * create qos policies on your aggregation router (7200/ASR). These 
> should be a standard parent/child policy with the parent to shape the 
> traffic and then whatever queueing you want in the child.
> * add entries in radius to apply qos policy to subscriber 
> virtual-interface when they connect
>
> An example of the radius attribute returned:
>
> Cisco-AVPair = "ip:sub-qos-policy-out=qos-dsl-8m"
>
> which would reference the QoS policy defined on the router of 
> "policy-map qos-dsl-8m".
>
> The big problem you will have is knowing what speed to shape each 
> individual DSL session to (ie. the downstream sync speed). There are 
> some ways that this can be presented to you from the DSL carrier, but 
> it's probably best to assume that you won't get this information 
> (although lucky for you if it is presented to you). For QoS to be of 
> ANY benefit you need to shape the traffic to LESS than the sync speed. 
> This leaves you with a couple of options to achieve this outcome:
>
> 1. shape all to a uniform speed that you know will be achieved by all 
> connections
> 2. shape to some speed you determine to be reasonable (but likely 
> less) that the sync based on distance calculations
> 3. wait until service is up and check sync speed and apply the nearest 
> speed shaper
>
> We only do QoS for DSL services in limited numbers and so we use the 
> third option. It would be manually intensive for any large number of 
> services but is manageable for us. We also provide managed CPE (Cisco 
> 800's) and so are able to determine the sync speed easily (and monitor 
> it via SNMP should we choose to).
>
> The problem is always shaping to something that is BELOW the sync 
> speed so that your QoS functions, but not TOO much below so that you 
> are robbing the users of performance. An extreme example would be that 
> you could shape all sessions to 1mbps, but then if someone achieved a 
> sync speed of 20mbps, you'd be wasting the extra 19mbps that might be 
> available to that user.
>
> Without looking I think we have QoS policies for DSL of something like 
> 512k, 1500k, 2m, 4m, 6m, 8m, 10m, 16m, 20m. There might be a couple 
> more between 10 & 20m, but you get the idea. Make sure you allow for 
> your overhead as well, sync speed != QoS shaper (PPPoE/PPPoA, etc).
>
> There is also the issue that sync speeds do change over time (usually 
> downwards, rarely increasing), so we often choose to be conservative 
> in case the speed of the service drops.
>
> Good luck :)


Thank you for your response, this is very helpful.

In my environment I do have line sync information since it's my own 
dslams. Its provided via PPPoE Intermediate Agent, or DHCP Option 82 
depending on type of subscriber (currently Im 100% pppoe but thats going 
to change).

Some ideas I had then would be to dynamically determine which class to 
put any given customer into. We have freeradius and a script that can 
execute for each authentication request and looks at the intermediate 
agent info and could decide which QoS policy to apply based on the 
customer actual data rates (which is an administratively configured 
value, not to be confused with 'attainable rate', which is based on loop 
length and quality). This would make things dynamic and likely 
worthwhile. The only fly in the ointment would be the case where, 
without retraining, the attainable rate drops by some significant margin 
below the previously-established actual rate, which would make the QoS 
ineffective. In that case however, it would be no worse than not having 
qos and I would argue that there likely would need to be some sort of 
service call anyways to restore service to normal anyways.

Mike-