Subject: RE: On policy conditions

From: "Black, David" <[email-masked]>
Date: Tue, 20 Apr 1999 18:32:50 -0400

> 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.  For the "10th premium user" example, what
is of interest is not the arrival of the next "logon" packet
after 9 premium users have logged on -- there's no way to
determine whether the logon will be successful or whether
the resulting logged in user is a premium user without actually
processing the logon.  Hence the event of interest is not easily
defined as a "packet arrival" event -- it's actually a "logon"
event generated by the logon processing (and whether the logged
on user is a premium user is probably an event parameter).

There are lots of other examples that could be used to
make this point.  Some notion of why policy was invoked is
clearly necessary (I called this an "invocation" in my
Minneapolis presentation), and while it's probably possible to
trace most invocations back to something like a packet
arriving or a timer going off, defining invocations
only in those terms requires taking the processing that
happens as a result of the packet arriving or the timer
going off and duplicating part of all of it in the policy.
IMHO, it's better to do the processing once,
and provide a way to declare more abstract events for
policy to handle.

My preference on this subject is to treat events as events
rather than hiding them in state transitions.  For Hugh's
5pm example, I'd have the timer declare some sort of "It's
time" event with a few parameters, one of which is what
time it is (e.g., "5pm").  These parameters clearly need to be
testable in conditions.

A nice feature of recognizing events/invocations is that
Silvano's restriction on not combining packet conditions
with transitions (e.g., time based) is an immediate
consequence.  Either an event is a packet event and has
packet parameters, or it's a time event and has time
parameters, and hence trying to combine packet content
with a time transition is nonsense.  Note that time ranges
(e.g., it's before 5pm) are different from time events
(e.g., it's exactly 5pm).

A sticky area is recursive policy invocation.  If we allow
general state transitions as events that invoke policy,
we run the risk of a policy engine changing some state variable
that implicitly reinvokes the policy engine -- not pretty.
Having the policy engine declare an event is a bit cleaner,
but there's still no free lunch here, as if the event is
immediate, we still have the possibility of policy executing
in parallel with itself (and may need to provide some
support/guidance to prevent this).

--David

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

---

From: Changpeng Fan <[email-masked]>
Date: Wed, 21 Apr 1999 09:54:11 +0200

> > 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.
>
> 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