Subject: Re: On policy conditions

From: "Hugh F. Mahon" <[email-masked]>
Date: Mon, 19 Apr 1999 12:00:58 MDT

Hello Wei Wang,

Thank you for your e-mail.  I apologize for not responding sooner; I 
was out of the office last week.

> I think I can understnad the concept of Transition, State, and Packet
> (Although I like Quality much better.) But I have a possibly very
> uneducated question: Why would a transition be related to condition at
> all? How do you use a transition in a condition?

This is a very good question.  One way of thinking about transitions 
is that it is moving from one state to another.  During a given state 
it may be interesting to impose other conditions, such as where is the 
traffic coming from or going to.  These conditions are only 
interesting during this state, and if another state is being 
considered other conditions may apply.

For this discussion I will focus on the state of a time interval, 
e.g., 8 AM to 5PM (0800-1700 hours).  At the time starting the state, 
8 AM, it may be interesting to cause certain events to occur, for 
example cause a change of configuration of a device.  That 
configuration will be maintained until the end of the state, which in 
this example would be 5 PM.  

> In my mind, a transition is the hapenning of an event. It may be a
> trigger of an event. It's dynamic, while a condition for a policy rule
> is a measurement of some state or quality of matter, which is more
> static. When a transition happens, it may trigger an event so some
> measurement may be done, to the state of a network, for example. And a
> policy action may subsequently be applied to the state of the network.
> 

You point out a very important aspect of policy conditions, and I 
think Silvano was trying to make a similar point: different conditions 
within a rule express different kinds of information.  Some conditions 
designate a given state, while other conditions are used to test other 
aspects and may be independent of state.  But the fact that we can use 
boolean operators to use these state conditions together with these 
other conditions allows a sort of short-hand, so that we can simplify 
the logic trees within policy rules.  Without this ability to combine 
stateful conditions and non-stateful conditions we would be required 
to write policies as nested files, such as:

        if (state1)
        begin
                if (sourceIPaddr == w.x.y.z)
                begin
                        assign high priority
                end
        end

This could lead to a great deal of complexity, not only for 
implementors, but network administrators as well. 
                
> Take the example above, "at 5 PM do something", one may compare the
> current time to see if it is ">=" 5 PM. But the happening of "5 PM",
> or the transition of time, is not the condition. The condition is
> something like "currentTime() >= 5 PM". When a transition is used to
> trigger some action, there is no "if" in that process. So that is not
> a policy as defined as "if condition then action".

I agree that a transition could be modeled as an event.  There are 
situations that we may want to have an events taken care of within 
policies.  If events are not modeled as conditions, then what would be 
the appropriate way of expressing 'do something on this 
event/transition'? 

Policy is something that is not solely intended for Quality of Service 
aspects, although it is the first focus for the Policy Framework WG.  
Policy definition needs to allow for other uses of policy.  I say this 
because all of the examples I can think of for QoS can be solved using 
time (expressed as a time range) as a stateful condition rather than 
as a transition.  (I am sure other examples exist, I am just not aware 
of them right now.)

I can think of time as a transition for other uses of policy.  For 
example, it is possible that policy could be used for scheduling of 
backups.  The use of time as a transition to begin the backup 
operation may be an important capability.  While a time range may 
suffice, would you want to force a backup to terminate at the end of 
the period if it has not finished?  In some environments it would be 
required to stop the backup, in others it would be a requirement to 
finish the backup even if it crept into business hours.  In the latter 
case the use of a time range (a time period as a 'state') would be 
improper.

I would welcome any other examples for transitions (time or otherwise) 
or stateful conditions (beyond a time range).

> > What would you think of the term 'quality' to describe what you call
> > 'packet', since I think the same concept can be applied to things
> > beyond a packet?
> 
> I like that.

Thank you.

> Regards,
> --
> Wei Wang               [email-masked]
> Merit Network, Inc.
> [Tel] 734-764-2874     [Fax] 734-647-3745

Regards,

        Hugh Mahon                              
        Hewlett-Packard Company                 
        Network Management Division  
        e-mail: [email-masked]

---

From: Changpeng Fan <[email-masked]>
Date: Tue, 20 Apr 1999 09:18:29 +0200

> 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