Subject: RE: On policy conditions

From: "David Allan" <[email-masked]>
Date: Tue, 20 Apr 1999 09:11:30 -0400

Changpeng:

I don;t quite buy these examples, there is a significant distinction between
a packet arrival associated transition, and some other event that generates
a state transition. When I say packet associated, it is once suficient
information from the packet is available such that a policy decision may be
applied to it (either header or content). In essence, any packet associated
event is any externally generated asyncronous event, and ANY other state
transition was generated internally. Most lower level events would be
insufficiently abstract for high level policy definitions.

Anything that can be associated with network traffic would appear to be able
to be packet event associated (including the logon examples below), begging
wonder why we need to handle state transitions at all as policy inputs. When
a packet arrives, some classification feeds information into a rule engine
which may also check a number of other instrumented state variables and out
pops an action.

So far Hugh's time example (spontaneously create information in the form of
a backup at 5 oclock) is the only non-packet associated event event I've
seen other than possibly interface failure or the ability to do timeouts
(and doing that sort of thing at this level of abstraction seems intuitively
wrong). The time example seems to be more service scripting than policy
although I do accept this has some utility, not sure this is the place to do
this else our set of policy actions becomes unbounded.

If we want to do state transitions, I'd like to see some reasonable set of
internal events that we would want to wrap policy around. As we've already
suggested that doing policy at the interface level is outside the level of
abstraction we wish to define policy at, I suspect that other than some time
of day triggers, we will be hard pressed to find anything but variations of
equipment failure (resource problems, by definition should be packet arrival
associated).

cheers
Dave

> -----Original Message-----
> From:	Changpeng Fan [SMTP:[email-masked]]
> Sent:	Tuesday, April 20, 1999 3:18 AM
> To:	Hugh F. Mahon
> Cc:	[email-masked]
> Subject:	Re: On policy conditions
> 
> Hello: 
> 
> > I would welcome any other examples for transitions (time or otherwise)
> > or stateful conditions (beyond a time range).
> 
> The following two examples show dynamic "high water-mark" transitions.
> 
> /* As soon as a 10th premium service user logs in, the maximum
>    resource allocation for a normal service user should be lowered.
>  */
> if a_10th_premium_user_logs_in
> then lower resource_upper_bound_for_normal_users
> 
> /* As soon as network usage is higher than 70%, no more 
>    new normal service users are allowed to log in. 
>  */
> if network_usage over 70%
> then deny any_new_normal_user
> 
> Similar "low water-mark" transitions are apparent. And, their
> corresponding stateful conditions may look like:
>  
> /* As long as there are more than 9 premium service users log on,
>    a normal service user is not allowed to access "bulk_service".
>  */
> if number_of_premium_users > 9
> then deny normal_user_access_of_bulk_service
> 
> /* As long as network usage is higher than 70%, a normal service 
>    user is not allowed to access more resource. 
>  */
> if network_usage > 70%
> then deny any_new_resource_allocation_for_normal_user
> 
> Regards,
> 
> Changpeng Fan
> NEC CCRLE, Berlin
>

---

From: Mark Roy <[email-masked]>
Date: Wed, 21 Apr 1999 05:42:38 -0400

Seems I've been a lurker 'round here to long.
As I follow this thread, it sounds as if you're trying to boil
the ocean! As stated by Hugh, everything should default to a
Meta-Rule should no explicit rule apply. Better still, there
should be a default rule that applies either:
     no rule thus all traffic by default gets Best Effort
     QoS\CoS, or
     No traffic is allowed except that explicitily defined
     by a rule
The former makes setting up the rules easy for most enterprises. You
only establish rules, in a OO hierarchy,and anything that doesn't
have a rule, gets the same Best Effort service it gets today. The latter
is for the security conscious, but then demands that an explicit rule
be defined for everything. This is called a fire wall.

There should be few cases where you MUST follow a data stream state, but
even then, the reconfigiuration of policy rules should be done at a general
and broad high level basis. Otherwise, trying to track down every other
data stream state, recalculate its policy and effect the changes in a
timely manner would both be difficult to scale and would prob'ly cause
such upheaval in the network during the policy reconfiguration as to cause
more harm than good.

Cheers!

-=> Mark Roy <=-
Product Engineer - 3Com
Network Management Division

-------------Forwarded Message-----------------

From:	Changpeng Fan, INTERNET:[email-masked]
To:	"Hugh F. Mahon", INTERNET:[email-masked]
	"'David Allan'", INTERNET:[email-masked]
	"Black, David", INTERNET:[email-masked]
	
CC:	, INTERNET:[email-masked]
	
Date:	4/21/99  4:17 AM

RE:	Re: On policy conditions

> > Anything that can be associated with network traffic would 
> > appear to be able to be packet event associated (including 
> > the logon examples below), begging wonder why we need to 
> > handle state transitions at all as policy inputs.
>
> I would suggest that defining this in terms of packet arrival is
> too narrow a view.

I also prefer a broader view in considering what can be conveniently
formulated as part of a policy rule.

In the example "if network_usage over 70% then deny
any_new_normal_user" or "if network_usage over 70% then treat
any_new_traffic as best-effort", the event/transition may be 
triggered by a house-keeping daemon which wakes up from time to 
time to check all sorts of resource usages: buffer, VCs/ports, etc. 
Such an event may well be asynchronous to the arrival or processing 
of any single packets.

Another case has something to do with unpredictable "emergency 
control". If, say, a certain backbone router becomes overloaded 
(or might become overloaded) due to a sudden breakdown in other 
parts of the network, it may have to trigger a policy rule which 
degrades some categories of services that are otherwise available 
to the normal traffic.   

Well, all this may belong to the domain of meta-rule control.

-- Changpeng

----------------------- Internet Header --------------------------------
Sender: [email-masked]
Date: Wed, 21 Apr 1999 09:54:11 +0200
From: Changpeng Fan <[email-masked]>
To: "Black, David" <[email-masked]>,
        "'David Allan'" <[email-masked]>,
        "Hugh F. Mahon" <[email-masked]>
Cc: [email-masked]
Subject: Re: On policy conditions
Sender: [email-masked]
Reply-To: Changpeng Fan <[email-masked]>

---

From: "David Allan" <[email-masked]>
Date: Fri, 23 Apr 1999 08:26:23 -0500

Changpeng:

I am not sure the "meta rule" passes Ken's simplicity test. This is the
policy validity period discussion taken to new heights. 

However I do have a concern that we effectively need "brackets" around
individual root events, hence my focus on packet arrival. It would seem to
me that any implementation must:

	- determine the set of relevant data associated with the root event
(e.g. TOS field, 		   addresses etc.)
	- determine the set of state changes associated with the root event
(such as the 		  logon count)
	- gather all policy rules triggered by the root event, 
	- evalutate the rules and collect the set of potential resulting
actions, 
	- PERFORM CONFLICT RESOLUTION on the set, 
	- and then perform the sanitized set of resulting actions. 

At this point, policy rules are purely data, and there is no discernable
boundary between the policy engine and the instrumentation. So anything that
to me suggests there is a boundary and we can consider policy as some form
of autonomous system (and not in the routing sense ;-), confuses me. 

This would also suggest that by definition that the policy conditions and
policy actions must be orthogonal sets (actions can't modify condition
variables) else we can have feedback loops and require recursion in the list
of stuff to be performed outlined above. (recurse until we converge on a
valid set..aaaarrrrgghh!) This sort of thing can be done, but only if you
can ensure a flash cut over from rule set to rule set such that loops by
definition have been eliminated by conflict detection in the population of
the policy set. Any ambiguities brought on by imperfect synchronization of
policy could cause policy "flaps"! ;-)

Dave

> Sent:	Thursday, April 22, 1999 3:00 AM
> To:	Allan, David [CAR:5N10-I:EXCH]
> Cc:	'Black, David'; Hugh F. Mahon; [email-masked]
> > My nomenclature suggests that transitions occur in the support
> > infrastructure and provide reason to examine specific policy rules (the
> > policy triggers are pushed into the stateful side of the system).
> 
> I can agree with this as an alternative conceptual interpretation.
> Actually, what I mean by "meta-rule control" is something similar:
> Some meta-rules are available to control which rules or rule
> sets should currently be active. In the case of a state transition
> triggered by time, water mark or emergency, a meta-rule may
> instruct the decision engine to switch from one rule set into
> another or to activate/deactivate chosen rules. State thrashing
> is surely a concern here. But anyhow it would be convenient
> to be able to use event triggers as part of the input conditions
> to these meta-rules.
> 
> -- Changpeng
>

---

From: "David Allan" <[email-masked]>
Date: Tue, 27 Apr 1999 09:48:10 -0400

Silvano:

I think your question is an implementation issue. Whether:

1) some event causes the PDP to say "examine this rule and give me the
resulting action" to a separate subsystem which then queries all the
relevant instrumentation via an API, OR

2) or the PDP says fetch me the rule and I'll do it myself....

Is all dotted lines on the designers page..... There is an implication when
you say "does the PDP store the fact that the user John is logged on" that
any separate rule subsystem could be stateful about John's status, but that
to me is messy design as I now have to communicate stuff and synchronize
state across sub-systems. I need to feed events into a policy engine "for
future reference" which may not result in a policy decision which kinda
messes up the semantics.

Dave

> Parameters are fine, the "event glue code" may have parameters. The
> question is: does the PDP stores the fact that user John is logged on? or
> does the event glue code provides an API to read the fact that the user
> john, either is, or is not, logged on in the "login system"?
> 
> -- Silvano
> 
> 
> Silvano Gai               
> Cisco Systems                  Empowering the Internet Generation
> 170 West Tasman Drive                         Tel. (408) 527 2690
> San Jose, CA, 95134-1706                      Fax. (408) 527 2690
>                                                    [email-masked]

---

From: "Black, David" <[email-masked]>
Date: Tue, 27 Apr 1999 12:05:42 -0400

> john, either is, or is not, logged on in the "login system"?

I agree with David Allan, this is an implementation
decision.  The policy is written to expect this as
a parameter, and how the "event glue code" gets that
information is up to the implementer.  I even agree
with the rest of his comments, that while it's
simpler not to have the PDP store this information,
there are circumstances in which it might need or
want to.

Since we've wandered back into that area, let me
provide a reminder/back pointer to the invocation
and binding material at the end of my Minneapolis
talk.  Ken's example includes the policy engine
sending a query to determine if a user is
logged on.  Let's suppose that the response to
that query takes some time.  If that query is sent
as part of condition evaluation, and that condition
evaluation occurs after some rules have fired, it
is possible for the policy to do something inconsistent
or unexpected because other things changed
during the query/response interval.  If the policy
is instead written in terms of "logged on" being
a parameter to the event/invocation, then the query/response
occurs in the "event glue code", and while policy
execution is still delayed by the query/response, all
execution occurs after the query/response and hence
is more likely to be consistent (i.e., it's faster
and hence things are less likely to change underneath it).
This is a tool/technique that should be available to policy
designers/authors as opposed to something about which
this working group needs to make a global decision.

--David 

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
[email-masked] (508) 435-1000 x75140
---------------------------------------------------