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

From: Debasish Biswas <[email-masked]>
Date: Thu, 25 Feb 1999 14:08:47 -0800

See inline...

-----Original Message-----
From: Raju Rajan [mailto:[email-masked]]
Sent: Thursday, February 25, 1999 7:12 AM
To: Debasish Biswas
Cc: [email-masked]; Jay Kistler
Subject: Re: Optimizing the policyRule class -- problems and proposals

Debasish Biswas wrote:
> 
> 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.

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

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.

   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. This is to save
the clients from   having to search from root always and then look into the
object to determine whether it  applies to the device in question. You don't
need to do that if there is a concept of where in the tree the device
belongs.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]

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

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?

Debasish >>
 Again an example would help to explain your requirement. In any case, if I
understand 
 your requirement right, there is nothing special about the 'fork' that
makes combining inline  actions with reference actions any easier. You can
do the same if you follow the direct  derivation approach if both object
classes(simple and complex policy) are instantiable. How will you order the
actions now for two complex policies ? It will be dependent on the PDP
implementors processing sequence of the policies over which the information
model cannot have any control.

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

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.

Debasish>>
 I was suggesting (Simple)Policy->ComplexPolicy derivation. 
Regards,

Raju Rajan

> 
> 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 18:18:40 +0000

>  The need for examples was amply stressed at the last IETF meeting in

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

>   Actually, I think query scoping is absolutely essential.In fact, the present implementation of FORE Systems Poilcy

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

> 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