Subject: Optimizing the policyRule class -- problems and proposals

From: Raju Rajan <[email-masked]>
Date: Tue, 23 Feb 1999 17:40:18 +0000

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: Debasish Biswas <[email-masked]>
Date: Thu, 25 Feb 1999 15:43:46 -0800

See inline...

-----Original Message-----
From: Raju Rajan [mailto:[email-masked]]
Sent: Thursday, February 25, 1999 10:19 AM
To: [email-masked]
Subject: Re: Optimizing the policyRule class -- problems and proposals

> Debasish>>
>   What do you mean by recombining information ? It would be better if you
> can give examples.                There is no point in warranting complex
> schema by using abstract scenarios to justify it.
>  The need for examples was amply stressed at the last IETF meeting in
> December.

I thought you'd never ask :)  
Simple examples are proposals, protocols, algorithms, userIDs, groupIDs, QoS
classes, etc.
which are reused across multiple policy rules. You may use the same set of
parameters to
establish multiple security associations, or use the same QoS
characteristics in multiple
tunnels. In these cases, "inlining" the objects, i.e., having one per policy
rule is
obviously redundant. You'll end up specifying the same set of IPSec or QoS
parameters over
and over again. It's also a management mess, as you'd have to delete every
instance of a
particular QoS type, if you decide not to offer a particular service
anymore. So, if you
can create special condition and action "objects", as the number of rules
increases, the
payoff on the reuse will too. Hence the current design point of about
multiple objects per
rule (but potentially shared across rules) vs. 1 object per rule but no
sharing.
 Please let me know if you still think me too vague ...

Perhaps we need to use a white board....

> 
> 
>    So, what do you think about query optimization through directory
scoping
> in my first
> proposal, and in Lee's more extended suggestion?
> 
> Debasish>>
>   Actually, I think query scoping is absolutely essential.In fact, the
present implementation of FORE Systems Poilcy
> Management implementation (which is shipping today) happens to use scoping
> extensivley (uses inheritance and overriding logic) and customers love it.
> [Please don't flame me for usng my employer's name]

In that case, why are you still concerned about the query explosion problem?
Is that not a
solution that we could enable (without mandating)? So why would we still
need the
simplePolicyRule? (I'm asking because I am aware of your implementation
experience.)

No it is not just the query scoping that solves it - what happens when one
of the referenced conditions is outside the scope (may be in another DS) - I
blow away all the benefit of scoping. The way a PDP would read is (as I
expect) as follows :

-- xxxSearch in scope (may be from root or from O=company, L=site,O=company)
   - read condition reference (because the condition DN is supplied)
   - read all such conditions in 
-- read schedule (which is also a separate object)
--evaluate schedule ^ condition list
--take necessary action

So if you continue with all the references, query scoping becomes irrelevant
as an optimiser.

> Debasish>>
>  I care more for  a simpler policy class than whether a direct derivation
is
> used.  So if most people feel a 'fork' is cleaner I am ok with that.

I understand your position. I too could go either way. So we agree on that.

Regards,

raju