[j-nsp] Network-control queue counter increases on ccc-configured interface

[Saku Ytti]

On (2012-01-27 11:02 +0800), Mark Tinka wrote:
 
> Anything more than 4 is just a variation of the main 3 (be, 
> ef, af), and only serves to create more complicated products 
> that your sales folk can sell and make a little bit more 
> money (sales guys don't care how complicated the network 
> becomes, as long as they close the sale and guarantee their 
> commissions - those 3AM calls in the morning are for you, 
> not them). 

This is generally true, if all your customers are created equal, and in
case of say Internet sourced DoS they all need to suffer equally.
But if some your customers are more important than others 4 can be quite
short amount.

Consider you're getting DoS from INET, and it's very rarely towards your
business INET users. But it will still sometimes be towards your business
INET, so you cannot put VPN customes in same 'better INET' queue, as you
must make sure L3 MPSL VPN continues to work for all INET sourced DoS. 
Now you already have three classes

1. normal inet (low margin, high dos risk customers)
2. priority inet (high margin, low dos risk customers)
3. vpn (to protect l3mpls vpn<->l3mpls vpn, even when priority inet
customer is dossed)

Now you'd only have 1 left, which you'd probably want for NC. Then you'd
need to put IPTV, VoIP and internal critical services such as PSTN in same
class as VPN or NC. And you'd risk that if VPN customers network is
compromised and is sourcing DoS that your priority services are down.

If we exclude DoS as normal part of life or we treat all INET customers as
equal 4 is easily enough.


When it comes to customer QoS, 4 should be plenty. As typically single
customer would only have need for 3 classes

1. normal traffic (web surfing, email, etc)
2. worse than normal (off-site backups, periodic mass transfers ec).
3. priority traffic (voip, telepresence, interactive applications)

If you must congest even priority traffic, then the customer link is likely
just too slow.
Customer QoS need not (and probably should not) map 1:1 to core QoS.
-- 
  ++ytti