Subject: Semantics in the policy schema

From: John Schnizlein <[email-masked]>
Date: Tue, 25 May 1999 13:15:08 -0400

Thread was 
RE: New Schema I-D Requested to be Posted to IETF Repository

At 11:36 AM 5/25/99 -0400, Stevens, Mark wrote:
>David:
>I don't know that all of the planets are aligned. 

Who would have guessed the age of Aquarius would come now?  :-)

>While I understand the
>transactional and logical problems you outline, I do not see how an
>architectural model will facilitate a solution. Knowing that we have an
>entry console talking to directory, and a policy server talking to directory
>and a network device doesn't bring us any closer to understanding how to
>solve LDAP's lack of atomic transaction support, or how to eliminate cycles
>in the DIT, nor does it bring us closer to solving what I think is the real
>problem, which is expressing network policy in a common, standard format. An
>architectural model would merely speak to an method of implementation and
>implemetations can vary if the policy itself is expressed universally. A
>policy, to be of any value, should represent a business goal, the expression
>of which should not be too rigidly tied to a particular architecture or
>implementation. Architecture should be changeable like the underlying
>technology without severely impacting the expression of policy. Initially,
>the effectiveness of policy statements may be limited by underlying
>technology and architecture, but the current technology should not freeze
>the expression of policy itself.

The similarity you see between architecture and implementation technology is a symptom of the lack of a coherent architecture. A useful architecture constrains the representation in ways that relate to the application, not just to the implementation. David's point that the structure of the policy representation should represent semantic constraints makes sense to me.

Silvano had earlier suggested a structural/architectural distinction between packet-condition and state-condition, which might be extended to a distinction between packet-action (e.g. color for service-class X) and configuration-action (e.g. associate user John with IP address (proto, port) A.) as in your following example. These distinctions reflect different loci of implementation as well as different degrees of dynamism. These distinctions are essential for both the architecture and for a schema that reflects semantic constraints.

One of the conclusions I found most compelling at the Minnesota meeting was that we should develop the policy model for a particular (QoS) content area before advancing the schema. This approach should help identify the semantic constraints needed in the schema, and possibly also needed in the architecture. 

>I think that we need to focus defining the contents of conditional
>expressions and begin to pay attention to defining actions as well. When we
>begin to define the terms of policy statements like "if ((bandwith consumed
>by HTTP traffic) < 15%) then admit a new HTTP flow at medium priority" we
>will be making progress. Terms that represent measurement like "HTTP
>bandwidth" and terms that represent packet treatment like "medium priority"
>need to be defined before we worry about the architecture in which to
>execute such policies and perhaps even the structures in which we store
>them.

The above provokes the kind of discussion that needs attention. In order to constrain the semantics, we should be discussing whether this kind of policy statement fits our architectural limits. I think not. Conditions like "bandwidth consumed by HTTP" are ambiguous and location-specific. Over how long an epoc is the measurement? On which interface, along what path? Keeping state information with as many parameters as this apparently simple condition requires is not scalable, even if we could anticipate the path of every potential new flow. An architectural decision we could make as a WG is to concentrate on policy for Differentiated Services QoS without implied admission control for individual flows. 

For admission control, some request signal is needed, and I doubt that even the most elaborate RSVP admission policy would check a variable as difficult to specify as proportion of bandwidth (where?) used by a protocol. This example makes a good point: discussing what kinds of policy statement are meaningful within an architectural framework might be better than specifying arbitrarily general policy statements, with the (layers of) conflict detection/resolution it implies. How do the chairs feel about developing consensus around questions like this instead of around system design?

>> From:	Durham, David [SMTP:[email-masked]]
>> ...
>> 
>> My point with the LDAPized core schema is that there needs to be
>> more thought as to the structure. Groups can contain groups, and
>> the draft states that cycles are not allowed, but the schema does
>> nothing to prevent them...
>>
>> As yet another gripe, I believe that the associations between 
>> actions and conditions is too weak. Some actions may only
>> correspond to specific conditions. I don't see this fact
>> coming out of the core schema. Conditions should be grouped
>> together with respect to only the actions that apply. 
>>
>>  ... Allowing arbitrary
>> associations between actions and condition groups will lead to
>> strange statement possibilities as these. I believe it is the
>> task of the schema to be structured so that such ridiculous
>> things simply cannot be stated. This can be enforced structurally
>> or simply loosely as additional attributes that specify things
>> such as "actions of type A relate to conditions of type B & C".
>> 
>> Furthermore, multiple kinds of actions that are grouped together
>> and associated with multiple kinds conditions further exasperates 
>> this problem!

Not the only exasperation I have noticed!

If we need to specify aspects of an LDAP policy directory beyond the schema, we should be prepared to do so in order to avoid compounding the semantic problems we have already.

John Schnizlein, Consulting Engineer
Cisco Systems, Office of the CTO

---

From: "Stevens, Mark" <[email-masked]>
Date: Tue, 25 May 1999 17:39:22 -0400

Comments inline.

-----Original Message-----
From:	John Schnizlein [SMTP:[email-masked]]
Sent:	Tuesday, May 25, 1999 1:15 PM
To:	Stevens, Mark; 'Durham, David'; 'R. Rajan'; [email-masked]
Subject:	Semantics in the policy schema

>The similarity you see between architecture and implementation technology
>is a symptom of the lack of a coherent architecture. A useful architecture
>constrains the representation in ways that relate to the application, not
>just to the implementation. David's point that the structure of the policy
>representation should represent semantic constraints makes sense to me.

[Mark Stevens >]  We have to be careful not to let an architectural model 
drive our conception of policy. Policies should drive the development of
the architecture. We must determine what business goals customers what to
accomplish with their networks and then figure out how to express them as
policies that can be carried out by the gear that makes up the network.
I fear that a premature focus on the and gear as exists today may hamper our

creativity and we will end up delivering policies that are easily
implemented but no one wants.  
 
>Silvano had earlier suggested a structural/architectural distinction
>between packet-condition and state-condition, which might be extended
>to a distinction between packet-action (e.g. color for service-class X)
>and configuration-action (e.g. associate user John with IP address
>(proto, port) A.) as in your following example. These distinctions
>reflect different loci of implementation as well as different degrees
>of dynamism. These distinctions are essential for both the architecture
>and for a schema that reflects semantic constraints.

>One of the conclusions I found most compelling at the Minnesota meeting
>was that we should develop the policy model for a particular (QoS)
>content area before advancing the schema. This approach should help
>identify the semantic constraints needed in the schema, and possibly
>also needed in the architecture. 

>The above provokes the kind of discussion that needs attention. In order to
>constrain the semantics, we should be discussing whether this kind of
policy
>statement fits our architectural limits. I think not. Conditions like 
>"bandwidth consumed by HTTP" are ambiguous and location-specific. Over how
>long an epoc is the measurement? On which interface, along what path? 

[Mark Stevens >]  Decomposing business goals into their components is
precisely the activity that is most valuable in the area of developing
policy
solutions. We have to take vague statements of policy like that which I put
forth in a previous message and break them down into their components. 
With the components understood, we can assess the feasibility of delivering
the component. With the resulting subset of components we can begin to
develop a list of policies that can be implemented and are interesting to
customers.
 
>Keeping state information with as many parameters as this apparently simple
>condition requires is not scalable, even if we could anticipate the path
>of every potential new flow. An architectural decision we could make as a
WG
>is to concentrate on policy for Differentiated Services QoS without implied
>admission control for individual flows. 

[Mark Stevens >]  We must keep in mind that DiffServ policies in the core
may
differ radically from DiffServ policies at the edges. Core DiffServ policies
may well want to include aggregated measurements of the state of the
network.
Edge DiffServ policies may well include user and group information. I don't
mean to say that DiffServ QoS policy is not a good starting point, I just
want to note that even DiffServ QoS policies can become complicated quickly.

>For admission control, some request signal is needed, and I doubt that even
>the most elaborate RSVP admission policy would check a variable as
difficult
>to specify as proportion of bandwidth (where?) used by a protocol. 

[Mark Stevens >] I am not sure that policy won't specify parishable,
volatile 
information like assessments of network state (e.g. bandwidth comsumption
at one or more points). Executing operational policies in networks will 
eventually rely on feedback from the network itself. 

>This example makes a good point: discussing what kinds of policy statement
>are meaningful within an architectural framework might be better than
specifying
>arbitrarily general policy statements, with the (layers of) conflict
>detection/resolution it implies. How do the chairs feel about developing
>consensus around questions like this instead of around system design?

[Mark Stevens >]  I sense a certain level of agreement in your last comment
and I would certainly like to hear the chairs' responses to your last
question.

>If we need to specify aspects of an LDAP policy directory beyond the
>schema, we should be prepared to do so in order to avoid compounding
>the semantic problems we have already.

---

From: John Schnizlein <[email-masked]>
Date: Tue, 25 May 1999 18:24:45 -0400

Mark,

We seem to agree on more things than disagree. I might help to mark them.

>I fear that a premature focus on the and gear as exists today may hamper 
>our creativity and we will end up delivering policies that are easily

We agree that the task is expression of business goals that can be implemented by network equipment, not limited to current products.

We agree that network and policy system design should follow rather than dictate the representation of business goals.

It is worth noting that unless the policy system provides the administrator with terms in which to represent the business goals, we will not likely escape the (impossible) task of interpreting unconstrained rules. Even the most complex (artificial intelligence) rule-based systems need a bounded domain of "knowledge".

>>>expressions and begin to pay attention to defining actions as well. 
>>>When we begin to define the terms of policy statements like 
>>>"if ((bandwith consumed by HTTP traffic) < 15%) 
>>>   then admit a new HTTP flow at medium priority" 
>>>we will be making progress. Terms that represent measurement like 
>>>"HTTP bandwidth" and terms that represent packet treatment like 
>>>"medium priority" need to be defined before we worry about the 
>>>architecture in which to execute such policies and perhaps even 
>>>the structures in which we store them.
>
>>The above provokes the kind of discussion that needs attention. In 
>>order to constrain the semantics, we should be discussing whether 
>>this kind of policy statement fits our architectural limits. I think not. >>Conditions like "bandwidth consumed by HTTP" are ambiguous and 
>>location-specific. Over how long an epoc is the measurement? 
>On which interface, along what path? 
>
>policy solutions. We have to take vague statements of policy like that 
>which I put forth in a previous message and break them down into their 
>components. With the components understood, we can assess the feasibility 
>of delivering the component. With the resulting subset of components we 
>can begin to develop a list of policies that can be implemented and are 
>interesting to customers.

We agree that deconstructing statements like this is a good beginning.
I agree so much that I am getting into this analysis now (waited too long.)

>>Keeping state information with as many parameters as this apparently 
>>simple condition requires is not scalable, even if we could anticipate 
>>the path of every potential new flow. An architectural decision we could 
>>make as a WG is to concentrate on policy for Differentiated Services QoS 
>>without implied admission control for individual flows. 
>
>may differ radically from DiffServ policies at the edges. Core DiffServ 
>policies may well want to include aggregated measurements of the state 
>of the network.

The experience of the IETF is that progress is made on simple things first.
DiffServ does not include any global feedback about the state of the network.
Instead, it recogizes that this state is distributed and varied so much that
the best approach is to specify the per-hop behavior for classes of traffic.

>>For admission control, some request signal is needed, and I doubt that 
>>even the most elaborate RSVP admission policy would check a variable as
>>difficult to specify as proportion of bandwidth (where?) used by a protocol. 
>
>volatile information like assessments of network state (e.g. bandwidth 
>comsumption at one or more points). Executing operational policies in 
>networks will eventually rely on feedback from the network itself. 

It may eventually, but if we depend on this at the start, by including
it in the representation of policy, we make the problem much harder.
We also separate this effort from that of DiffServ immediately.
DiffServ strives to avoid even the degree of state that IntServ embraces.
And even IntServ avoids anything more complex than hop-by-hop capacity
allocation.

>>This example makes a good point: discussing what kinds of policy 
>>statement are meaningful within an architectural framework might 
>>be better than specifying arbitrarily general policy statements, 
>>with the (layers of) conflict detection/resolution it implies. 
>>How do the chairs feel about developing consensus around 
>>questions like this instead of around system design?
>
>[Mark Stevens >]  I sense a certain level of agreement in your last 
>comment and I would certainly like to hear the chairs' responses to 
>your last question.

Your sense of agreement is accurate. We must be careful to concentrate on what realistic (if not actually available) network devices can do, and on the technological limits of agreed-upon components like directories, and not specify business goals. This is the IETF, and business policy is strictly out of bounds. (It is impolite to even force the chairs to remind us.)

Let's start the analysis on the list, based on DiffServ semantics now.
Leaders tend to notice progress and get out in front of the effort.
And let's include the essential security issues mentioned in Minnesota.

John