Subject: [Diffserv] Policer failure

From: Shahram Davari <[email-masked]>
Date: Thu, 12 Oct 2000 09:30:55 -0700

Hi,

Has anybody thought how to limit/prevent the damage that could be caused by
failure of  Diffserv policers at the edge?

Regards,

Shahram Davari
Systems Engineer
Product Research Group
PMC-Sierra, Inc. (Ottawa)
Phone: (613) 271-4018
Fax:     (613) 271-7007

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Shahram Davari <[email-masked]>
Date: Thu, 12 Oct 2000 12:17:36 -0700

Hi Nabil,

> -----Original Message-----
> From: Nabil Seddigh [mailto:[email-masked]]
> Sent: Thursday, October 12, 2000 2:35 PM
> To: Shahram Davari
> Cc: [email-masked]'
> Subject: re:[Diffserv] Policer failure
> 
> 
> Hi Shahram,
> 
> Could you be a bit more specific?
> Are you referring to failures due to bad/wrong implementation?
> Or is it simply "failure" due to bad configuration and associated
> traffic 
> management? 

Mostly I was thinking of mis-configuration (human error) of policer
parameters (such as setting the rate to 100 Mb/s instead of 10Mb/s), but you
could include other failures too.

i.e where you end up with links that are 
> under-provisioned or over-subscribed due to excess traffic
> allowed in at the network edge.
> 
> There's not much that one can do about the former ;)
> I would think that the latter should be addressed by proper 
> deployment of various defined PDBs or services.

I don't think any PDB deployement can address this issue.

> 
> It seems to me that in the context of Diffserv, if the edge 
> doesn't do 
> its job, there's not too much that the core can do other than the
> obvious. 

One advantage of ATM/FR/Intserv is that you have per-flow queuing, and even
if a policer fails, it would not have any adverse effect on other flows.
since Diffserv relies on the aggregate scheduling in the core, we won't have
this advantage. But we could probably use per-flow queuing at the edge
routers to stop excess traffic from flowing in to the core. My question is:

Is per-flow queuing at the edge routers compliant with Diffserv, and if so
does it cause any scaling problem? 

I personally think it is acceptable and won't cause any scaling problem,
because after all, Diffserv keeps other per-flow states at the edge routers,
it might as well keep per-flow queuing state too.
 
Network management tools that detect such problems
> quickly, accurately and scalably would appear to be the best bet.

Could you please describe how network management tools can detect the failed
policer?

regards,
-Shahram

> 
> Best,
> Nabil Seddigh
> [email-masked]
> 
> >Hi,
> >

---

From: "Nabil Seddigh" <[email-masked]>
Date: Thu, 12 Oct 2000 14:35:04 -0400 (EDT)

Hi Shahram,

management? i.e where you end up with links that are 

It seems to me that in the context of Diffserv, if the edge doesn't do 
its job, there's not too much that the core can do other than the
obvious. Network management tools that detect such problems
quickly, accurately and scalably would appear to be the best bet.

Best,
Nabil Seddigh

---

From: "Nabil Seddigh" <[email-masked]>
Date: Thu, 12 Oct 2000 17:54:11 -0400 (EDT)

Shahram,

I doubt per-flow queueing at the edge will solve the problem that 
you describe. If I understand correctly, the per-flow queue 
parameters will be setup based on the  traffic profile for the 
traffic stream -which is wrongly configured to begin with.

>Could you please describe how network management tools can 
>detect the failed policer?
>

I was just speaking generally with some loose ideas floating in
my head ;) The various approaches I have heard tossed around
involve topology knowledge, traffic pattern monitoring and
knowledge of the TCAs for the DS domain. 

In any case, this is probably not the right forum for such discussion.

Best,
Nabil Seddigh