Subject: RE: Optimizing the policyRule class -- problems and proposals

From: Debasish Biswas <[email-masked]>
Date: Thu, 25 Feb 1999 11:43:10 -0800

Raju,

I strongly feel the availability of simpler base classes will be perceived
as a strength of the schema and will allow more efficient implementation
conforming to the schema. Besides it would give a chance to vendors to
implement policy support directly in their devices (read  directly from the
DS/store) because they don't have to make at least four trips to the
repository to evaluate one policy. Till now the whole exercise has been done
with a policy server in mind and that is why any objection about complexity
has been ignored. There should not be any such bias when designing the base
classes for the schema.

I vote for the second option with some suggestiosn. I would still like to
ask why can't we derive the classes as :

                 SimplePolicy (minimal pointer/reference requirement)
                        |
                        |
                        V
                 ComplexPolicy(maximun pointer/reference requirement)

Even in the wide world of Object Oriented programming your base classes are
simpler and derive d classes are more convoluted. Same holds true for
standard objectclasses - refer to the following classes :

                     person,                  |     (increasing complexity)
                     organizationalPerson,    |
                     inetorgPerson            V

Comments are welcome.

Debasish Biswas
FORE Systems

-----Original Message-----
From: Raju Rajan [mailto:[email-masked]]
Sent: Tuesday, February 23, 1999 9:40 AM
To: [email-masked]
Subject: Optimizing the policyRule class -- problems and proposals

Hi,

I was supposed to make a formal proposal regarding the "cardinality of
policyConditionReference" issue. 

ISSUE:
Currently about 4 different objects are used to define a policy --
PolicyRule,
PolicyCondition, PolicyAction, TimeOfDay. For a certain class of PDPs, a
design favoring
the retrieval of fewer objects is preferable, at the cost that the full
flexibility of
policy is not available to them. This has specifically come up in the
context of DHCP
policy.

CURRENT SOLUTION:
The current solution is to argue that we need the ability to create one
composite "Policy
Rule" object that would contain condition, validity period and action
attributes within
it. This composite class is sought to be created as a subclass of policyRule
(let's call
it optPolicyRule for now). To quote from the core draft
(draft-ietf-policy-core-schema-02.txt, Section 6):

"All preceding mechanisms for extending the core schema will work in all
cases, but they
come at a price: in order to fully understand a policy rule, a client must
retrieve at
least three objects: a policy rule, at least one policy condition, and at
least one policy
action.  A future version of this specification may define how to optimize
the evaluation
of a policy rule so as to reduce the number of classes that must be
instantiated to define
a policy."

PROBLEMS WITH THIS APPROACH:

1) It requires that policyRuleConditionList be an optional attribute but has
no default
value for it!
2) This requires a new definition and handling of CNF and DNF conditions at
a later date
to take into account future condition attributes that may be defined within
the policyRule
class
3) It requires that action ordering be elaborated to handle new actions that
may be
defined inline.

PROPOSALS:
1) We allow query optimization through other means, without expressly
designing the schema
around it. Basically the design point is that rules are expected to be
static, and PDPs
will retrieve all rules at configuration time from the directory. The amount
of
information retrieved from the directory will be roughly the same (i.e., the
total volume
of policy data in MB), whether there is one object or many. The problem of
having to query
multiple times for different objects can be optimized by putting all objects
targeted at a
particular device or role in one branch of the directory tree. 

If we adopt this solution, we'd remove the offending para quoted above and
put in a
default value for policyRuleConditionList; (proposed default is Universal
Set, ie.
condition is always true).

2) If we decide to allow explicitly for an optimized class, then rather than
subclass the
optimized policyRule class from the unoptimized one (ugh!) we could subclass
both from a
parent class. Thus we'd have

           policyRule
             |
         -------------------------
        |                        |
 simplePolicyRule              complexPolicyRule

policyRule will be the same as now, except it wont have the condition and
action list
pointers. The simplePolicyRule class will have all conditions inline.
complexPolicyRule
will have the condition and action list pointers. The present difficulties
will dissapear.
(I can write out a list of explicit document changes if we decide to adopt
the approach.)

---

From: Raju Rajan <[email-masked]>
Date: Thu, 25 Feb 1999 15:11:51 +0000

Debasish Biswas wrote:
> repository to evaluate one policy. 
...
Till now the whole exercise has been done
> has been ignored. There should not be any such bias when designing the base

That's not true, Debasish, because a number of us who agree with the current core schema,
are planning a solution with the PDP in the device. The reason I would see "complexity"
a.k.a. number of objects/queries as a secondary optimization (with
functionality/reusability of objects) as the prime critereon, is that as you scale to more
policies, you'll end up re-combining information to make up different policy rules. The
complex policies avoid resending reusable data. So, in large scale scenarios, the
"complex" object structures are the more manageable AND data optimized (tho' not query
optimized). 

   So, what do you think about query optimization through directory scoping in my first
proposal, and in Lee's more extended suggestion?

>                  ComplexPolicy(maximun pointer/reference requirement)

Because you'd get the same messy resolution requirements as before. For example, in what
order do I perform an "inlined" action which the SimplePolicy allows, with reference to
the explicit ordering of actions that the complexPolicy allows? Or how do I combine inline
conditions with seperate policyCondition objects in DNF that the complexPolicy allows?

The above derivation is much more elegant than the complex->simple derivation that is
suggested in the document. I still like the "fork".

Regards,

Raju Rajan