Subject: RE: PQIM draft issues

From: "Weiss, Walter" <[email-masked]>
Date: Wed, 18 Oct 2000 18:06:14 -0400

Hi Ron,

> From: Ron Cohen [mailto:[email-masked]]
> Sent: Saturday, October 14, 2000 6:05 PM
> 
> >>4.3 "The QPIM defines a single operator, "match", that 
> models the most 
> >>generic relation: that of being equal or belonging to."
> >>
> >>(7*) Equal to and belonging to are two very different 
> semantics. One is a 
> >>comparative relation while the other is a set relation. I 
> don't think you 
> >>should overload these two distinct concepts with a single operator.
> >
> >Hmmmm... You're disagreeing with a judgement call made here. 
> I'm not too 
> >sentimental about this. Some like it and some don't, but what's your 
> >specific objection to the overloading? Do you think this may become 
> >ambiguous under some circumstances? Can you think of an example?
> 
> The wording should be fixed, but the intention is that the 
> semantics of the 
> match is determined by the form of the matched value. An IP 
> address value 
> can represent both a single IP address as well as a range of 
> IP addresses. 
> When an IP value is matched against a variable, the match is 
> therefore 
> either equal to a single IP address or reside within the IP 
> address range.
> 
See comments to Yoram on this point.

> [snip]
> 
> 
> >>(16) It is important to keep in mind that there will be 
> more forwarding 
> >>actions beyond the QoS ones specified here. For example, 
> NAT, Tunneling, 
> >>and stateful firewalling services are all functions that are in the 
> >>packet processing engine and that occur in the path between 
> the ingress 
> >>and egress ports of a router. Therefore, it is important to 
> be able to 
> >>define a sequence of actions with various decision points 
> along the path. 
> >>It may well be that this model supports these more complex 
> scenarios, but 
> >>there was not enough detail in the section for me to 
> determine with any 
> >>level of confidence that this model could be sufficiently extended.
> >
> >We've been looking into these issues. I'm deferring this to 
> Ron as the 
> >primary action modeler, but I think your point is to be seriously 
> >considered here.
> >
> 
> I think it is not a good idea to try to model everything at 
> once within 
> QPIM. People are looking at adding actions that cover other 
> areas as MPLS, 
> tunneling, etc.
> 
My point was a little different. I was not suggesting that you should expand
your model to consider these possible scenarios. Rather that it should be
compartmentalized using class hierarchies, such that actions can reference
class instances. I would strongly argue against a flat action space
containing all possible attributes that can be assigned. While this may be
tenable for QoS, it will not scale once other forwarding bahaviors are
introduced into the policy infrastructure.

> 
> >>4.7.2 "The basic decision modeled by this class is whether 
> to admit or 
> >>reject the RSVP request. The decision can be based on 
> comparison of the 
> >>request TSPEC or FLOWSPEC to a traffic profile and a meter. 
> A meter can 
> >>be used to track the temporal resources allocation of RSVP requests 
> >>matching the network condition."
> >>
> >>(17) I could not gather from this text whether the 
> semantics allowed me 
> >>to specify a policy that limited admission based on the 
> current volume of 
> >>RSVP session traffic or the sum of the reservations. However, it is 
> >>probably reasonable to support both capabilities.
> >
> >Again, deferred to the expert. I tend to agree that one 
> should be able to 
> >express both types of admission policies.
> I'm not sure what "current volume of RSVP session traffic" 
> means. "sum of 
> reservations" as well as control on any single reservation request is 
> supported. QPIM does not provide a way to make different 
> decisions based on 
> whether the actual rate of flows is smaller that the rate 
> reserved for 
> these flows. I don't see why it should.
> 
I have heard from customers that want to use policies based on network
consumption rather than reservations as a criteria for accepting or
rejecting a reservation. While I would personally challenge this notion as
counter to basic principles around reservations and IntServ in general,
there seems to be a desire to have this feature non the less. However, as
you can see, I did not flag this as a critical issue.
> 
> >>"Setting preemption priority [RSVP_PREEMP] allows the RSVP 
> node to decide 
> >>which of its reservations should be admitted, and when to 
> make room for a 
> >>new reservation by preempting an already installed one."
> >>
> >>(18*) It would seem to me that preemption is a good example 
> of something 
> >>I might want to construct a policy for. Note that this type 
> of policy has 
> >>nothing to do with packet arrival (see issue 5 above). For 
> example, I 
> >>might want to create a policy that preempts the reservation 
> (flow) that 
> >>is consuming (or reserving) the most bandwidth.
> >
> >I think you're requesting a clarification here. Will be addressed.
> 
> An RSVP PDP (LPDP) needs to arrive at decisions once an RSVP 
> state changes, 
> in most cases once a new/update RSVP message arrives. This 
> policy allows 
> you to specify the preemption priority that an RSVP state 
> deserves. The 
> standard RSVP preemption algorithm is assumed. See RFC 2751.
> 
We are not not suggesting that the semantics of RSVP or COPS should change.
Rather, I am pointing out that COPS has provisions for local policy
enforcement and consequently using policies to determine preemption criteria
rather than static priorities would certainly be useful.
> 
> >>"Rule S:
> >>   If <condition> THEN, for all WF and SE style Resv 
> messages, accept 
> >> RSVP request requesting less then <64kp/sec> AND make sure 
> that the 
> >> total number of admitted active reservations is restricted to <5>."
> >>
> >>(19*) This is another case where I consider the conditions 
> and actions to 
> >>be arbitrarily mangled to fit it into the model. The way I 
> would have 
> >>expressed this is:
> >>
> >>   IF (style = WF OR style = SE) AND qpRSVPTrfcProf < 64Kb AND 
> >> SessionCount < 6 THEN accept reservation
> >>
> >>This is far more intuitive than what you have.
> >
> >I believe this has been addressed above. It ends up being a 
> matter of 
> >taste but it is also a modeling decision to accommodate 
> certain profiling 
> >and metering mechanisms in a uniform way. However, I think that this 
> >deserves some studying. Will do.
> 
> RSVP specific parameters were not included in the filter but 
> rather as 
> attributes within the action that limit its scope. This is 
> similar to the 
> direction (in/out) indication included in the action as well. 
> The reason 
> was to allow specifying all actions relevant to a traffic 
> class in a single 
> rule. For example, to be able to specify:
> 
> If (My ERP application) than
>        Accept RSVP reservations requesting CL
>        Deny RSVP reservations requesting GS
> 
> As well as being able to use share the same filters across 
> provisioning and 
> signaling actions.
> 
Hmm. Frankly, I don't understand this arguement. Making these expressions
conditions instead of actions still keeps them in the same rule. Further, I
don't think it prevents the sharing of filters across provisioning and
signaling either.
> 
> 
> >>4.8.1 "qosPolicyPRTrfcProf class includes the follow properties:
> >>   1. Rate measured in bits/sec.
> >>   2. Normal burst measured in bytes.
> >>   3. Excess burst measured in bytes."
> >>
> >>(20*) This is not the only set of parameters for defining a 
> metering 
> >>profile. Certainly this is not the one described in the 
> DiffServ specs.
> >>
> >>"Rate determines the long-term average transmission rate."
> >>
> >>(21) If you can specify the rate and the burst, why don't you have 
> >>parameters quantifying "long-term", either as a weight or 
> an interval or both.
> >
> >Again, (20) and (21) are deferred to Ron.
> 
> One can add other traffic-profile as extensions. We chose to 
> include the 
> basic traffic profile chosen by the diffserv-MIB (rate and 
> burst), plus 
> adding the excess burst that is commonly used in the industry (CIR 
> specification for example).
> 
> No need to define both time-interval as well as burst and rate, as 
> time-interval=burst/rate (up to a unit factor). This is explained in 
> diffserv-MIB. We chose not to allow two different ways to 
> represent the 
> same traffic profile.
> 
I went back to the MIB and found the text.  It does not look quite right to
me.I am going to have to get back to you on this one after I discuss it with
the MIB co-authors.

Thanks,

-Walter

---

From: Yoram Ramberg <[email-masked]>
Date: Thu, 19 Oct 2000 13:08:55 -0500

Just a tiny little note...
Snipped the rest to save BW.
*Yoram

At 06:06 PM 10/18/00 -0400, Weiss, Walter wrote:

>Hi Ron,
>
> > From: Ron Cohen [<mailto:[email-masked]>mailto:[email-masked]]
>[...snip...]

>My point was a little different. I was not suggesting that you should 
>expand your model to consider these possible scenarios. Rather that it 
>should be compartmentalized using class hierarchies, such that actions can 
>reference class instances. I would strongly argue against a flat action 
>space containing all possible attributes that can be assigned. While this 
>may be tenable for QoS, it will not scale once other forwarding bahaviors 
>are introduced into the policy infrastructure.

IMO, we should provide abstract classes that can be further refined to 
model various specific actions (which can be further refined). Why abstract 
actions? To allow interoperability so that people don't go defining their 
own actions that are outside the scope of [QPIM] and [PCIM]. So, for 
example, traffic profile can be a property-less abstract class from which 
one can derive PR profile, RSVP profile and also things like CR-LDP traffic 
profile. Alternately, an implementer may use RSVP traffic profile (or PR) 
already defined and derived from the abstract class to specify CR-LDP 
traffic profile. Comments to this effect were made in Pittsburgh and since 
by Marcus. We need to consider this seriously.

[...snip...]

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 23 Oct 2000 14:21:32 +0200

Yoram Ramberg wrote:
> > My point was a little different. I was not suggesting that you
> > should expand your model to consider these possible scenarios.
> > Rather that it should be compartmentalized using class hierarchies,
> > such that actions can reference class instances. I would strongly
> > argue against a flat action space containing all possible attributes
> > that can be assigned. While this may be tenable for QoS, it will not
> > scale once other forwarding bahaviors are introduced into the policy
> > infrastructure.
> >
> 
> model various specific actions (which can be further refined). Why
> abstract actions? To allow interoperability so that people don't go
> defining their own actions that are outside the scope of [QPIM] and
> [PCIM]. So, for example, traffic profile can be a property-less
> abstract class from which one can derive PR profile, RSVP profile and
> also things like CR-LDP traffic profile. Alternately, an implementer
> may use RSVP traffic profile (or PR) already defined and derived from
> the abstract class to specify CR-LDP traffic profile. Comments to this
> effect were made in Pittsburgh and since by Marcus. We need to
> consider this seriously.
> 
> [...snip...]

Yoram,

Yes, I am in favour of using inheritence for the purpose of extending
the model. Some abstract actions and traffic profiles are what we would
like to use and extend in the MPLS case. And I am sure, it will help
defining other models by extending existing once instead of defining
from scratch.

Marcus
-- 

Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155