RE: Modeling of Policing component.

"sqreeek" (that's the sound of the opening of a can of worms): Would
you consider evolving the informal model of RFC 3290 into a more
formal calculus, where such issues as Meter -> AbsoluteDropper and
AlgorithmicDropper -> Scheduler might be derived from first
principles? FSMs are already used in RFCs, so maybe it wouldn't be
such a jump to ASMs? You've already established four categories of
basic functions and indicated a rule for constructing arbitrarily
complex TCBs from the elements. Why drop the analysis at that point?

-- TT

-------- Original Message --------
Subject: RE: [Diffserv] Modeling of Policing component.
Date: Mon, 1 Jul 2002 09:28:29 -0700
From: "Andrew Smith" <[email protected]>
To: "'ravikumarb'" <[email protected]>
CC: <[email protected]>

I disagree: if you follow an Algorithmic Dropper by a Scheduler (there's
an implied Queue in there somewhere), when the Queue starts to get full
due to "excess" traffic (arrival - departure > 0 over appropriate time
intervals), the Dropper will kick in. That is "policing" (it's doing
shaping at the same time of course).

Meter->AbsoluteDropper is the more conventional way to think about
policing, I agree, but AlgorithmicDropper->Scheduler is also valid.

Andrew Smith


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of ravikumarb
Sent: Monday, July 01, 2002 6:49 AM
To: Brian E Carpenter
Cc: [email protected]
Subject: RE: [Diffserv] Modeling of Policing component.
...
We can have an Algorithmic Dropper as part of Policer, but not a
Scheduler. The moment we have a Scheduler, what we are doing is Shaping
not policing.



_______________________________________________
diffserv mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: 
http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html





_______________________________________________
diffserv mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html