Subject: Review comments on QPIM-04

From: "Robert Moore" <[email-masked]>
Date: Wed, 1 Aug 2001 15:15:11 -0400

I've taken a fairly close read through most of
draft-ietf-policy-qos-info-model-0411.txt, and I have
quite a large number of comments.  I'm not going to
try to categorize these comments, other than flagging
a few as "BIG ISSUES".  Many are just editorial, but
if nobody ever points them out, they'll never get
fixed.  I'll leave it up to the QPIM authors to decide
which of these comments merit discussion in London.

1.  Page 5, second paragraph: it sounds odd to call
    DiffServ a "QoS management paradigm" - why
    "management"?

2.  Page 5, last paragraph: I know about edge and
    core devices, but what is a "distribution"
    device in this context?

3.  Page 5, last paragraph: I question the last
    sentence, but maybe I don't understand what
    "QPIM" means in this context.  Part of specifying
    a QoS policy involves using PolicyRoles to tie
    rules to resources (in this case, to specific
    interfaces on specific devices).  And this does
    involve topological information.

4.  Page 6, second paragraph: "QPIM enables a common
    set of conditioning mechanisms to be specified
    in a standard manner."  This sounds like QDDIM to
    me, not QPIM.  The last sentences of the paragraph
    ("Therefore, a means is required to specify
    functionality in a standard way that is independent
    of the capabilities of different vendors' devices.
    This is the role of QPIM.") make a slightly
    different point, which sounds better.  It does
    raise, though, the issue of modeling capabilities,
    which is something the WG may need to face before
    long.

5.  Page 6, last paragraph: I don't know what point
    this paragraph is making, probably because I don't
    know what "This" it's referring to.

6.  Page 7, last two paragraphs: The term
    "application-specific" appears twice.  From the
    context, I was expecting "device-specific".
    Similarly, I was expecting "device" rather than
    "application".  If the point really is about
    applications, then more needs to be said.

7.  Page 8, first paragraph: To limit terminology
    creep, "structured as a condition clause and an
    execution clause" should say "structured as a
    condition clause and an action clause."

8.  Page 8, second paragraph: "Rather, it subclassed
    the SimplePolicyCondition and the
    SimplePolicyAction classes."  Aside from the one
    case of QoSPolicyRSVPSimpleAction, this is not at
    all what QPIM does.  Instead, it *uses* the two
    classes SimplePolicyCondition and
    SimplePolicyAction from PCIMe.

9.  Page 10, section 1.2.6: Just so you don't think
    I found problems with everything in this draft,
    this is a very good example, clearly presented.

10. Page 12, third paragraph: "a network element may
    have configuration options and combinations that
    are not expressible in QPIM."  This is a
    BIG ISSUE, because is goes to the heart of the
    question of how QPIM and QDDIM are related.
    Reading this sentence, I immediately ask myself
    the question: "Then how does the Policy
    Administrator take advantage of the features of
    his network elements whose configuration is not
    expressible in QPIM?"

    Is "He simply can't" an acceptable answer?  Is
    "By stepping outside the Policy Framework
    altogether, and tweaking something via the
    device's CLI" any better?

11. Page 12, last paragraph: This paragraph seems to
    assert that if two vendors have *different* LDAP
    schemas that are both derived from QPIM, then
    because they had QPIM as a common starting point,
    the two vendors' products will interoperate.
    I don't think this is right.  The two vendors
    need to use the same LDAP schema in order to get
    interoperability.  This is why the Policy
    Framework WG produces **LS drafts to go with
    our **IM drafts, so that there's one common
    LDAP mapping for each of our information models.

12. Page 13, second paragraph: There's a BIG ISSUE
    lurking here, but it's at least as much PCIMe's
    as it is QPIM's.  This paragraph is talking
    about interoperability, while the question
    that's been raised for PCIMe is compliance.
    But they're really the same question.  The issue
    is that in a PDP / PEP environment, the PEP
    never sees the QPIM information model, or even
    the specific data model (e.g., an LDAP schema)
    derived from it.  Instead, what it sees is a
    compiled / predigested version of the model,
    in the form of device-specific configuration
    commands created from the model by its PDP.
    Yet a lot of the compliance / interoperability
    we want to talk about concerns the behavior of
    the PEP - for example, the behavior of its
    Rule Engine.  So the question we need to answer
    is "What does it mean to say that a PEP
    has correctly implemented a Policy model?"

13. Page 15, paragraph after the first ordered list:
    This places QPIM between steps 1 and 2, but if
    you read the text for the steps, if looks like
    the main role of QPIM is in step 3.  This isn't
    quite a BIG ISSUE, but the question of where
    QPIM fits into the overall Policy picture is
    one that needs a very crisp answer.

14. Page 16: Typo in the class diagram:
    QoSPolicyShapeActionAction-->QoSPolicyShapeAction.

15. Page 18, elsewhere: You're still split about
    50-50: is the name of the association
    QoSPolicyExceedAction, or QoSPolicyExcessAction?

16. Page 19, bottom: The page footer appears twice.

17. Page 20, second paragraph: "Using the direction
    variable defined in the policy core information
    model ...."  Actually, this variable is specified
    in PCIMe, not PCIM.

18. Page 21, first paragraph: BIG ISSUE.  This whole
    section is important, because it specifies the
    nature of the QPIM extensions to the rule-nesting
    design from PCIMe.  But I don't think the core
    premise of the section is correct.  (I'll admit
    that this could be for either of two reasons:
    either it *isn't* correct, or else there's some
    key element of the example that I don't
    understand.)  The assertion that seems wrong to
    me is this: "Are these two representations
    identical? The minimal bandwidth guarantees
    provided by the flat representation are
    identical to those presented in the hierarchical
    form."

    Suppose you have a stream with a very high flow
    rate, consisting exclusively of UDP packets that
    are neither TFTP nor NFS.  It looks to me like
    the hierarchical version of the rules guarantees
    30% of the available bandwidth to this stream,
    while the flattened version guarantees it only
    15%.  Am I reading something wrong here?  If so,
    the text needs to be clarified to keep me (and
    others!) from making this mistake.  If not, then
    I'm not sure what to make of the whole section.

    Finally, I don't know how to interpret the
    conclusion, in the last paragraph on page 21.
    Is this now saying that the hierarchical version
    and the flat version *do* yield different results?

19. Page 22, last paragraph: Since there's an
    important difference between the case where
    rule hierarchy has contextual implications and
    the case where it does not, there needs to be a
    clear test for when each applies.  The test given
    is "introduction of a minimal bandwidth action
    within a sub-rule."  But for this to be
    meaningful, I need to have a test for what
    counts as "a minimal bandwidth action."  And
    if we have such a test, do you really mean to
    say that the *only* cases in QPIM for which
    rule nesting implies context are those that
    pass that specific test?

20. Page 23, second paragraph from the bottom:
    "Though obviously necessary, QoS conditions
    can be formed by setting appropriate attributes
    of existing policy condition class instances."
    As was the case with item 8, this simply
    doesn't describe what you actually did in
    QPIM.  The properties involved are in the
    policy variables and policy values, not in
    the policy conditions.  For DiffServ, these
    variables and values were defined in PCIMe.
    For RSVP, they are, for the most part,
    defined in QPIM itself.

21. Page 23, last paragraph: in this paragraph
    DiffServ is incorrectly expanded to
    Differential Services, rather than
    Differentiated Services.

22. Page 26, second paragraph: "DSCP and CoS
    marking are modeled as sub-classes of the
    simplePolicyAction class."  No, they're not.
    The only subclass of SimplePolicyAction that
    QPIM defines is QoSPolicyRSVPSimpleAction.

23. Page 26, second paragraph: "Bandwidth
    allocation, scheduling and congestion control
    actions are modeled as sub-classes of the
    QoS PHB action."  I find bandwidth allocation
    and congestion control, but not scheduling.

24. Page 26, section 3.3.1: BIG ISSUE.  Next to
    the indented example near the bottom of
    page 26 that starts "If (HTTP) ...," I wrote
    "What about ExecutionStrategy?"  This was
    going to be a request that QPIM specify for
    cases like this which of the three PCIMe
    ExecutionStrategy values to use: Do Until
    Success, Do All, or Do Until Failure.
    (Presumably the answer in this case would
    be Do All.)  I realized, though, that there's
    a much bigger problem here.  These actions,
    in their QPIM form, aren't performed at all.
    Instead, they're compiled by a PDP, and the
    resulting device-specific configuration
    commands are sent down to the PEP.  As a
    result, if ExecutionStrategy means anything
    at all here, it means something different
    from what it means in a device-level model
    like IPsec, where the individual actions
    really are performed.

    It sounds like this is a case where PCIMe
    needs to sort through the problem and devise
    a solution, and then QPIM needs to reflect
    that solution.  We'll be in touch:-)

25. Page 27, first four paragraphs: since it
    took me a while to understand it, it's
    worth pointing out, both here and back in
    the definitions section, the subtlety with
    the associated traffic profile.  Even
    though policer actions and shaper actions
    are tied to a traffic profile via the same
    inherited association
    QoSPolicyTrfcProfInAdmissionAction, the
    semantics of the association are different
    in the two cases: the policer determines
    whether the profile is being met, while the
    shaper takes action to make sure that the
    profile is met.

26. Page 27, last paragraph: I've mentioned
    this to the QPIM authors before.  The word
    "marker" is already taken, by the DiffServ
    WG, to refer to a datapath component that
    sets one header field to one value,
    unconditionally.  QDDIM follows this usage.
    It's fine if you want to introduce a term
    to refer to the constellation of instances
    consisting of a meter followed by three
    associated marking actions, which mark
    with three different DSCPs.  But you
    shouldn't use the term "marker" for this
    purpose.

27. Page 28, first paragraph: you need to
    explain exactly what the phrase "masked to
    the IPP subfield" means, in terms of the
    classes and associations defined in PCIMe.
    I know how to use the PCIMe elements to
    limit the range of a variable, but I don't
    know how to do the same thing for a value.

28. Page 29, first paragraph: it's OK to say
    that the PolicyVariableInSimpleAction
    aggregations are omitted for readability,
    but you should say verbally where they
    go: to instances (or do they all go to
    the same instance?) of PolicyDSCPVariable.

29. Page 29, last sentence on the page:
    This reinforces item 24.  What could success
    or failure possibly mean for one of these
    PHB actions?

30. Page 31, third paragraph: these are the
    wrong names for the threshold max/min
    properties.

31. Page 31, second paragraph from the bottom.
    Because both types of nesting are allowed,
    I don't know whether "The default rule uses
    a 'match all' decision strategy and
    specifies the Best Effort rules" is correct,
    or a typo for "... and specifies the Best
    Effort actions."

32. Page 34, first paragraph: gpsPolicyTRFCProf
    is the wrong class name.

33. Page 34, last paragraph of section 4.1:
    what's the relationship between a zero
    excess burst size and the three action
    associations?  Must one of these associations
    be omitted?  If so, which one?

34. Page 34, first paragraph of section 4.2:
    "The admission decision can be based on
    matching individual RSVP requests against a
    traffic profile or by matching the aggregated
    sum of all FLOWSPECs (TSPECs) currently
    admitted."  Is this determined by the
    qpAdmissionScope property in an associated
    QoSPolicyRSVPAdmissionAction instance?
    If so, you should say this explicitly.  If not,
    you still need to answer the question.

35. Page 36, third paragraph: "All variable
    classes defined in this document extend the
    PolicyImplicitVariable class, defined in
    [PCIMe]."  I suppose this is true, but
    wouldn't it be more informative to say
    that the variable classes in this document
    derive immediately from QoSPolicyRSVPVariable,
    which is itself a subclass of
    PolicyImplicitVariable?

36. Page 38, last several paragraphs: "The
    property name is used to specify which of
    the properties in the object is being used
    as the condition."  How does the Policy
    Administrator say *which* RSVP object to
    look at?  Also, "A simple condition can be
    constructed...."  You actually need to
    construct it.  You say what the value looks
    like, but what about the variable?

37. Page 38, same paragraph: gpsPolicyAttributeValue
    is the wrong class name.

38. Page 39, section 7.1 and subsections: the
    formal specifications of the cardinalities in
    section 7.1 are correct, but the explanatory
    text in sections 7.1.1 and 7.1.2 is incorrect.
    For example, the correct text for section 7.2
    would say "The [1..1] cardinality means that
    an admission action is associated with exactly
    one traffic profile" (which makes a lot of
    sense:-).

39. Pages 40 & 41: similar to item 38, the
    explanatory text for the three Dependent
    cardinalities is incorrect.  The text for the
    three Antecedent cardinalities is, however,
    correct in this case.

40. Page 42, section 8.2: This looks like an
    editing mistake - the RSVP text doesn't belong
    up here in the abstract superclass.

41. Page 44, section 8.5.1: Something's wrong here.
    Regardless of how this flag is set, requests
    are supposed to be admitted.  So how can a
    request ever be denied?

42. Page 45, section 8.6.1: When it says "... the
    maximum packet size in bytes of this class of
    packet," I find myself asking "*What* class of
    packet?"  A sentence saying exactly which
    packets this property applies to would help.
    (If this were QDDIM, I'd answer "The packets
    that reach this point on the datapath."  But
    since this isn't QDDIM, I really don't know
    how to answer the question.)

43. Page 46, section 8.7.1: It would be good to
    repeat here the information from page 30, that
    larger values represent higher priorities.

44. Page 47, sections 8.7.5 and 8.7.6: It's
    probably relevant for other properties as well,
    but for the delay properties I'm looking for
    some statement about *which* hop the phrase
    "this hop" refers to.  And is there some
    implication about the mapping of this part of
    the QPIM model to QDDIM's ingress and egress
    interfaces - for example, that these properties
    only make sense for an egress interface?

45. Page 61: As it's presented the
    QoSPolicyRSVPSimpleAction doesn't sound to me
    like a subclass of SimplePolicyAction.  PCIMe's
    SimplePolicyAction has the semantics "Set
    <variable> to <value>."  I don't see how to
    reconcile this with the statement in section
    8.32.1 that "This property is multi-valued,
    which means that both action types may be
    executed."  If there's a possibility that
    you'll be doing two things, how can this be
    thought of as setting a variable to a value?

46. Page 61: "Only variables that are subclasses
    of the QoSPolicyRSVPVariable are allowed
    to be associated with this action."  You can
    express this formally, by subclassing the
    PCIMe aggregation
    PolicyVariableInSimplePolicyAction.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
[email-masked]

---

From: "Yoram Snir" <[email-masked]>
Date: Tue, 7 Aug 2001 18:56:35 +0200

Bob,
Thanks for the review, great work.
Please see my comments with in the text.
Yoram Snir

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Robert Moore
Sent: Wed, August 01, 2001 9:15 PM
To: [email-masked]
Subject: Review comments on QPIM-04

OK, we will drop management.

aggregation devices. you could divide the network to edge and core or edge,
aggregation and core both works ;-).

QPIM does not add to PCIMe resources tagging, using roles. It only provides
and example of usage. We will add text to clarify the issue.

Editorial, we would replace "mechanism" with "models"

this refers to the policy constructs, we will explicitly say so or remove
altogether.

Editorial, in the first paragraph it should say device specific and in the
second application specific. Will be fixed.

OK

You are right, it is the remains of the process of moving pieces from QPIM
to PCIM an PCIMe.

Thanks ;-)

It should say same high level policy could be translated to different, non
standard low level device configurations. The next sentence "Further
explanation of this property of QPIM can be found in section 1.2.10 below."
points to the following text, I quote:
"First, different PEPs will have different
capabilities and functions, which necessitate different individual
configurations even if the different PEPs are controlled by the same
policy. Second, different PDPs will also have different capabilities and
functions, and may choose to translate the high-level QPIM policy
differently depending on the functionality of the PDP as well as the
capabilities of the PEPs that are being controlled by the PDP. "

No, see section 1.2.10

We would rewrite to say 'THE' LDAP schema.

Another way of thinking about this is going top to bottom, I.e., The PDP is
the one "knowing" both the policy standard and the specific device it is
responsible of. It translates the PCIMe / QPIM policy to this device
dependent on the device capabilities. 2 PEPs configured by the same PDP with
the same PCIMe/QPIM policy may have different low level configuration. The
PEP rule engine is also device specific. The PDP responsibility is to know
both the PEP configuration capabilities but ALSO it's rule engine
capabilities. Taking ACLs as an example, some PEPs may be limited by the
number of ACLs that could be configured and processed. I don't expect the
policy editor to know this, but the PDP responsible for this device should
know these limitations and over come it.

It should say: "QPIM, PCIM and PCIMe are intended to be the bridging
mechanism between step #1 and step
#3 in the methodology just described, by providing the standard building
blocks .

Thanks

Thanks

Thanks

Thanks

We would add text to this example and describe how each type of traffic is
handled. This example shows that hierarchical version of the rules and flat
version are different policies but is missing a piece that explains other
effects (not just min BW).

    pass that specific test

We would add text and an example.

Editorial: This should read as "Though obviously necessary, QoS conditions
can be formed by associating the appropriate values and variables class
instances, as defined in PCIMe"

Thanks.

You are right and it explained in section 3.3.2  (Controlling Markers). We
will fix this.

We would replace "...actions are modeled as sub-classes..." to "...actions
are modeled using sub-classes..."

you raise here 2 issues:
1. PCIMe execution strategy used in the example should be explicitly
defined. It was not done since this issue was still debated in the last 3
weeks, in the context of PCIMe. We would provide an explicit definition
here.

2. The more important issue is the second point. PCIMe defines the execution
strategy for the device independent (high level) policy and the PDPs are
responsible for maintaining this logic in its low level translation. The
execution strategy means exactly what it said in the high level policy. The
PDPs must maintain the logical structure like it must maintain the condition
and actions details. This is one of the capabilities required from a PDP.

This is true for PCIM PCIMe and QPIM. Fixing #1 would clarify #2.

A general issue that may need additional text, in PCIMe.

True.

We will look into this and find another name for "markers"

meant "compared", usually done by masking, will be fixed.

OK

We will add text to clarify.

OK

we will clarify

OK

Will Clarify or remove the sentence altogether.

We will add clarifying text.

It does, we would elaborate.

The important issue is that this is consistent with PCIMe, We would need to
look into this and think of making the proposed change.

This answers a requirement to specify policy and network behavior dependent
on users attributes or other high level charaaccteristics. For example the
administrator would like to allocate resources to users of specific
divisions in the organization. A user profile includes the division name as
an attribute. It makes more sense to have policy defined once per division
attribute than per each user's name / id.

We would add text and give a usage example.

True, would be fixed.

True, would be fixed.

True, would be fixed.

It should not be an abstract class, typo.

Typo: "Not" was missing.

It should say "the maximum packet size in bytes of packets in the designated
flow."

OK

As defined in "diff-serv".

It was supposed to be single value, i.e., if both  actions are required
(COPS replace action and COPS set action)  then 2 QoSPolicyRSVPSimpleAction
instances would be created.

OK

Regards,
Bob

Bob Moore

---

From: "Yoram Snir" <[email-masked]>
Date: Wed, 8 Aug 2001 16:02:03 +0200

Bob, 

-----Original Message-----

Thanks ;-)

No, see section 1.2.10

Thanks

Thanks

Thanks

Thanks

Thanks.

you raise here 2 issues:

True.

we will clarify

True, would be fixed.

True, would be fixed.

True, would be fixed.

Typo: "Not" was missing.

OK

Regards,
Bob

Bob Moore