Subject: [Diffserv] MIB - technical comments (part 1)

From: Andrew Smith <[email-masked]>
Date: Mon, 11 Dec 2000 01:24:34 -0800

Here are some technical comments on the MIB document: these start at the 
beginning and go as far as the start of the MIB section. At the end there are 
also a few comments on the MIB module too although these are not complete - more 
to come on that. Feel free to act on or ignore as the WG sees fit.

Andrew

======================================

1. 2.1 (This comment is somewhat related to the ongoing discussion with Bob 
Moore on the mailing list). A term is introduced here, "Data Path", which is 
somewhat different to the "Datapath" idea used in the Model draft. From [MODEL]:
   "Datapath      A conceptual path taken by packets with particular
                  characteristics through a Diffserv router. Decisions
                  as to the path taken by a packet are made by functional
                  datapath elements such as Classifiers and Meters."

The usage in the MIB document is different to this i.e. it is single interface, 
single direction. The last paragraph of 2.1 could also use some clarification: e.g.
"The notion of a Datapath introduced in [MODEL] is used in this MIB to indicate 
the DiffServ processing that a packet experiences as it travels in a given 
direction ("in" or "out") of a given interface of a Diffserv device. A 
diffServDataPathTable contains entries that indicate the first of possibly 
multiple functional datapath elements that will apply DiffServ treatment to the 
packet."

That's closer to consistency. But then there's a comment down in the MIB:
"Each entry of the diffServQTable belongs to one and only one datapath."

This is a more specific usage of "datapath" than up in 2.1: Is this supposed to 
be saying that a datapath is the complete collection of functional datapath 
elements that exist for a given {interface,direction} combination? That would 
conflict with the usage in [MODEL] where it means just a single potential path 
(and thus would allow multiple such paths to merge into the same queue).

2. 2.2  "These elements are designed with their
parameterization tables separated from their data path linkage tables,
allowing reuse of each table as much as possible.  The data path linkage
in this MIB is coupled with interface thru the use of diffServDataPathTable. 
The concept of "interface" is as for the InterfaceIndex/ifIndex of the IETF 
Interfaces MIB [IFMIB]."

Not sure what most of this has to do with "Relationship to other MIBs and Policy 
Management" (keep the Interfaces MIB reference though). There are too many 
forward references here for legibility. Suggest this belongs later on after 
ideas such as "parameterization table" and "data path linkage table" have been 
defined.

3. 2.3 para 1:
"the sequential DiffServ treatments being applied to a packet, and the 
parameterization of these treatments"
Suggest use existing terms, rather than "treatments" e.g.
"the sequence of DiffServ functional datapath elements that act on a packet, as 
well as the parameterization of these elements".

4. 2.3 para 1: Not sure what a "data definition" is.

5. 2.3 para 2: "router" has been replaced with "Diffserv network device" here 
but there are several other places that still talk about "router". Seems like 
this change is decreasing consistency with other Diffserv documents - suggest 
that we need WG consensus to make this change (else this would be just an 
editorial comment).

6. 2.3  "Data Path Table
      A general extensible framework for describing the starting point of
      DiffServ datapaths within a single DiffServ device."
Not sure why this is described as a "general extensible framework" - it's just a 
table, not intended to be extended, and it is complete, not just a framework.

7. 2.3 "Classifier and Filter Tables
      A general extensible framework and one example of a
      parameterization table - filter table (an IP Six-Tuple Multi-Field
      Classification Table)."
What is a "parameterization table - filter table"? Suggest we nuke the 
"parameterization table - ".

8. 2.3 "Meter Tables
      A general extensible framework and one example of a
      parameterization table - TBMeter table, applicable for Simple Token
      Bucket Meter, Average Rate Meter, Single Rate Three Color Meter,
      Two Rate Three Color Meter, and Sliding Window Three Color Meter."

Suggest that, if this meter table is really suitable for all those different 
types of meter then it shouldn't be called "TBMeter table" any more.

9. 3 "DiffServ treatment parameterization" is used in several places: see 
comment 3 above, but suggest we use some other existing terms e.g. 
"paramterisation of DiffServ functional datapath elements".

10. 3 "... allowing the flexibility to
maintain a common data construct for DiffServ device configuration and
provisioning, independent of the configuration/provisioning method used."
A distinction is introduced between configuration and provisioning without 
really defining what is meant by each. Either need to provide definitions or 
references and explain why we distinguish between them here.

11. 3 "The definitions in this MIB are intented to be reused by the DiffServ
PIB and SNMPCONF working group's DiffServ Policy MIB.". This may be too specific 
a forward-reference for this document. Suggest
"The definitions in this MIB are intended to be reusable verbatim by other 
future standards."

12. 3.1 "Given some basic information, e.g.
ifIndex and interface direction, the first DiffServ Functional Element
is determined."
Define "first".

13. 3.1 "The data path can be redefined to allow a different level of control
other than interface level control currently defined in this MIB.  There
is on-going work in this area, most notably the development of Policy
Information Base in DiffServ and RAP working groups, and DiffServ Policy
MIB in SNMPCONF working group."
Again, this forward-reference probably doesn't belong here. I don't understand 
what is meant by "the data path can be redefined ..."

14. 3.1.1 "As
indicated in section 2.2, with some modification/extension of the Data
Path Table, most of the tables and their entries are reusable by other
Policy Management mechanisms."
Suggest we nuke this sentence (not relevant to this MIB).

15. 3.1.1. "For indication of none existence of
DiffServ Treatments, entries can be created with zeroDotZero in the
diffServDataPathStart attribute to indicate this explicitly.  The none
existence of DiffServ Treatment can also be indicated implicitly by not
having the entry at all. The explicit/implicit selection is up to the
implementation.  This means allow normal IP device processing when
zeroDotZero is used in the diffServDataPathStart attribute, or when the
entry does not exist.  Normal IP device processing will depend on the
device, for example, this can be forwarding the packet."

Why do we offer such an implementation choice? Choices are bad. Pick one - 
suggest "implicit". I'd propose:

"The non-existence of any Diffserv functional datapath elements on an 
interface/direction is indicated implicitly by having no corresponding
entry in this table."
Much simpler.

16. 3.2. "Order is
present only to resolve ambiguity, by use of "order" here and
"precedence" in [MODEL]"
Why the change to use different terminology to [MODEL]? Previous MIB drafts used 
"precedence" here quite happily.

17. 3.2. I'm confused by the introduction of the terms "classifier element"  and 
"filter specification" (previously we had just "classifier" and "filter"). Need 
to explain these new terms and how it relates to the others (particularly since 
"filter specification" means something different in Intserv documents).

18. 3.2. "The classifiers specified here are at the interface level, they may be
derived from some more general policies ..."
I'm not sure what this sentence means any more (it made slightly more sense in 
previous versions, but not a lot) and it applies to many of the other element 
types as well. Suggest we nuke the paragraph.

19. 3.2.1. "entries .... get linked from ..." We don't have a concept of back 
pointers here so it would be best to phrase this as "entries .... are pointed at 
by ..." instead.

20. 3.2.1. But more problemmatical is: "It is the entries in the
Classifier Table that get linked from the upstream diffserv functional
datapath element, i.e. an entry in diffServDataPathTable."
The entries in diffServDataPathTable do *not* represent functional datapath 
elements! I think what is meant is something like:
"It is the entries in the Classifier Table that are pointed at by
the entries in diffServDataPathTable."

21. 3.4.2
"Notice counter support is implementation specific.  Where within a data
path and for what purpose a counter exists can be different between
implementations.  It is advisable to have at least one counter within a
data path and have different counts derived from DiffServ counters and
counters defined in other MIBs."
I have a problem with this text - it seems to say nothing useful for a standard. 
Is the advice meant for an implementor or a manager? Suggest we nuke this 
paragraph. See also similar sentence in 4.2.2 - the "should" there is similarly 
ambiguous.

22. 3.5.2. The figure 1 no longer matches the definitions in the MIB.

23. 3.5.2. This section ought to mention the usage that random-drop makes of the 
diffServAlgDropQThreshold value (it's described down in the MIB under 
diffServAlgDropType and diffServRandomDropMaxThreshBytes).

24. 3.5.2
"The availability of
diffServRandomDropSamplingRate as readable is important, the information
provided by Sampling Rate is essential to the configuration of
diffServRandomDropInvWeight.  Having Sampling Rate be configurable is
also helpful, as line speed increases, the ability to have queue
sampling be less frequent than packet arrival is needed."
I can't fully parse the last sentence of this discussion but I think I 
understand what it means and disagree with the reasoning (as I have done all 
along over the last year or so): what is presented is an argument for having the 
implementation change its sampling rate according to changing line speed. It is 
*not* an argument for having the net manager change it. I'm still not convinced 
that this variable is that useful (to a net manager) and it certainly must be 
made optional in the conformance section, if included at all. And if 
diffServRandomDropInvWeight is optionally read-only then the argument presented 
means that there is no need to have diffServRandomDropSamplingRate mandatory (we 
could make it mandatory iff you implement a configurable 
diffServRandomDropInvWeight).
But did I miss the discussion where the WG decided to include this variable at all?

25. 3.5.3
"The [MODEL] section 7.1.2 describes a
a scheduler with multiple inputs: this is represented in the MIB by
having the scheduling parameters be associated with each input.  In this
way, sets of Queues can be
be grouped together as inputs to the same same
Scheduler."
This is somewhat confusing: input to what? Suggest:
"The [MODEL] section 7.1.2 describes a
a scheduler with multiple inputs: this is represented in the MIB by
having the scheduling parameters for servicing the queue at each input to the 
scheduler be referenced by the queue table entry itself. In this
way, sets of Queues can be
be grouped together as inputs to the same same
Scheduler."

26. 3.5.3
The changes that were made since -04 draft on the following paragraph make it no 
longer make sense:
"For representing a Strict Priority scheduler, each scheduler input is
assigned a priority with respect to all the other inputs feeding the
same scheduler, with default values for the other parameters.  A
higher-priority input will be serviced first over a lower-priority
priority input, assuming that all guarantees have already been met."
Since this is now describing a Strict Priority scheduler, where does the concept 
of a "guarantee" come from? I prefer the -04 draft version (yes, I wrote that 
paragraph :-)) which explains how the parameter works, in general, not just in 
the specific case of a Strict Priority scheduler (which is just an example). The 
original paragraph was:
"Each scheduler input, as represented by a Queue Table entry, is assigned a 
priority with respect to all the other inputs feeding the same
scheduler. A higher-priority input will be serviced first over a lower-priority
priority input, assuming that all guarantees have already been met.
This priority parameter, used on its own with default values for the
other parameters, serves to allow representation of a Strict Priority
scheduler."
Suggest we go back to the original.

27. 3.5.3. The changes here seem now to imply that a scheduler can no longer 
offer guaranteed minimum bandwidths as well as sometimes limiting to a maximum 
(the OID pointers in the MIB make these exclusive and there is only a single 
leaky-bucket Burst Size parameter). I think that is too limiting - there are, 
literally, several millions of deployed examples of schedulers that quite 
happily do both. The example in 4.2.3 also seems to indicate that, if you want 
to do shaping, it is likely done *after* all other scheduling whereas, in my 
experience, it is much more likely that shaping will be done separately on each 
class, rather than on the complete output to a link - so I think Figure 6 is 
somewhat of a strange example.

DiffServSchdParamEntry: does diffServSchdParamBurstSize apply to the Max or to 
the Min? But what is needed are separate burst sizes for the Min and Max 
leaky-buckets - this was described in 3.4.3 of the -04 MIB as follows:

"For Weighted Queueing algorithms e.g. WFQ, WRR, the "weight" of a given
scheduler input is represented with a Minimum Service Rate leaky-bucket
profile which provides guaranteed bandwidth to that input, if required.
This is represented, as were token-bucket meters, by a rate
diffServQueueMinRateAbs and a burst size diffServQueueMinBurstSize. The
rate may, alternatively, be represented by a relative value, as a
fraction of the interface's current line rate, diffServQueueMinRateRel
to assist in cases where line rates are variable or where a higher-level
policy might be expressed in terms of fractions of network resources.
The two rate parameters are inter-related and changes in one may be
reflected in the other.

An input may also be capable of acting as a non-work-conserving [MODEL]
traffic shaper: this is done by defining a Maximum Service Rate leaky-
bucket profile in order to limit the scheduler bandwidth available to
that input. This is represented, similarly to the minimum rate, by a
rate diffServQueueMaxRateAbs and a burst size diffServQueueMaxBurstSize.
The rate may, alternatively, be represented by a relative value, as a
fraction of the interface's current line rate, diffServQueueMaxRateRel."

Except that we forgot back then to put the two burst size parameters into the 
MIB module - duh! This is also consistent with [MODEL].

28. 4.1 Figures 2,3,4: I find the use of text names for the "xxxId" values to be 
confusing: in the MIB (and the example in [MODEL] too) these are integers and to 
use text strings here in the figures seems confusing: for one thing the text 
strings imply semantics e.g. "AF", "EF" that may or may not be appropriate; for 
another, the same text string is used in multiple places for Ids that may or may 
not be identical (e.g. AF11 in at least 3 places in figure 2). Also,, the 
spaghetti could be a bit straighter - e.g. place the AbsDrop box below the 
Counter one in figure 2, avoid the crossing arrows in Figure 3.

29. 4.2.1
"Another level of classification can be defined that follows the Action
functional datapath elements in Figure 5.  This second level of
classifiers and their subsequent functional datapath elements would be
considered as in another TCB."
Why refer to TCB at this point? It's the first time since saying up top that we 
wouldn't be considering them here.

30. 4.2.1 The last example here could use some more introduction in the way of 
"this example is here because .... if conveys the following benefits ..." etc.

31. 4.2.2. "for trTCM": what is this? need a reference or else spell it out 
"two-rate three-colour marker". BTW, I thought trTCM was a Marker, not a Meter 
.... are you here describing a Meter that can be used to measure the output of a 
trTC *Marker*? If so, needs some re-wording.

32. 5.2.
"StaticRowPointer also clearly indicate the identified conceptual row's
content does not change, hence they can be simultaneously used, pointed
to, by more than one data path linkage table entries."
Not sure that that really means what it says: surely the contents of a 
conceptual row are allowed to be changed. Is it just the existence of the row 
that is supposed to be constant?

33. StaticRowPointer definition: do you want comments on this here on on the 
other separate ID? Is the text pasted in unchanged?

34. diffServClfrElementEntry:
     INDEX { diffServClfrElementClfrId, diffServClfrElementId }
These should be reversed to match the order of the objects in 
DiffServClfrElementEntry (or vice versa).

35. diffServRandomDropInvProbMax:
Again, did I miss some discussion where the WG decided to use an "inverse 
probability" rather than a percent*100 for Pmax (as it was in -04)? It's 
possible I'm not interpreting the DESCRIPTION correctly:
        "The worst case random drop probability, expressed as
        the  inverse  of  the drop probability.  With special
        case of the value zero meaning  zero  probability  of
        drop.

        For example, if every packet may be  dropped  in  the
        worst   case   (100%),   this   has   the   value  of
        4,294,967,295."

As it is now I think I can represent Pmax of 1, 0.5, 0.25, 0.125 etc. with MIB 
values of 1, 2, 3, 4 respectively, but no intermediate values (but then why does 
4294967295 represent 100% - why not 1? SO I am obivously confused). But we've 
been through this many times before and I thought we had consensus on using 
percent*100. I guess I must have blinked.

36. diffServSchdParamPriority: is described as:
"The priority of this queue, to be used as a  parame-
        ter  to  the  next  scheduler element downstream from
        this one."
I'm confused about which "this" is intended and what "downstream" means: I don't 
think these descriptions in diffServSchdParamEntry should be talking about 
queues since they are used for both Queue Table and Scheduler Table entries - 
they should talk about being parameters of scheduler inputs instead, which is 
what they really are. So how about just:
"The priority of this input to the associated scheduler, relative to others."
If "associated" is not clear enough then describe what the association is in the 
definition of diffServSchdParamEntry.

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Simon Leinen <[email-masked]>
Date: 11 Dec 2000 18:43:17 +0100

Andrew,

I don't think you are confused... somehow the old (inverse
propability) representation snuck back in in the -05 revision.

In mib-04 we had:

    diffServRandomDropProbMax OBJECT-TYPE
        SYNTAX       Unsigned32
        MAX-ACCESS   read-create
        STATUS       current
        DESCRIPTION
           "The worst case random drop probability, expressed in drops per
           thousand packets.
           For example, if every packet may be dropped in the worst case
           (100%), this has the value 1000. Alternatively, if in the worst
           case one percent (1%) of traffic may be dropped, it has the value
           10."
       ::= { diffServRandomDropEntry 6 }

This was shorter, less confusing, and reflected what I interpret as WG
consensus.  So I suggest reverting to that version.
-- 
Simon.

>>>>> "as" == Andrew Smith <[email-masked]> writes:
> Again, did I miss some discussion where the WG decided to use an
> "inverse probability" rather than a percent*100 for Pmax (as it was in
> -04)? It's possible I'm not interpreting the DESCRIPTION correctly:

> As it is now I think I can represent Pmax of 1, 0.5, 0.25, 0.125
> etc. with MIB values of 1, 2, 3, 4 respectively, but no intermediate
> values (but then why does 4294967295 represent 100% - why not 1? SO I
> am obivously confused). But we've been through this many times before
> and I thought we had consensus on using percent*100. I guess I must
> have blinked.

---

From: Fred Baker <[email-masked]>
Date: Thu, 14 Dec 2000 16:12:04 -0800

Andrew:

Kwok and I applied many to most of your comments; I'll let you see that 
when the diffs and new draft are posted over the weekend. We have a few 
more substantive comments, which I will call out, leaving out the "OK... 
OK..." stuff.

At 01:24 AM 12/11/00 -0800, Andrew Smith wrote:
>1. 2.1 (This comment is somewhat related to the ongoing discussion with 
>Bob Moore on the mailing list). A term is introduced here, "Data Path", 
>which is somewhat different to the "Datapath" idea used in the Model 
>draft. From [MODEL]:
>The usage in the MIB document is different to this i.e. it is single 
>interface, single direction. The last paragraph of 2.1 could also use some 
>clarification: e.g.
>"The notion of a Datapath introduced in [MODEL] is used in this MIB to 
>indicate the DiffServ processing that a packet experiences as it travels 
>in a given direction ("in" or "out") of a given interface of a Diffserv 
>device. A diffServDataPathTable contains entries that indicate the first 
>of possibly multiple functional datapath elements that will apply DiffServ 
>treatment to the packet."
>
>This is a more specific usage of "datapath" than up in 2.1: Is this 
>supposed to be saying that a datapath is the complete collection of 
>functional datapath elements that exist for a given {interface,direction} 
>combination? That would conflict with the usage in [MODEL] where it means 
>just a single potential path (and thus would allow multiple such paths to 
>merge into the same queue).

As I understand your comment, I think it brings up a shortcoming in the 
model more than it does in the MIB.

Example:

         ---> classifier  --->  meter  --> succeed actions --> queue
                                   |                           A
                                   |                           |
                                   +----> failure actions -----+

I believe that you just told me that the sequence including the "succeed 
actions" is one datapath, and the sequence including the "failure actions" 
is another data path, and that it is inappropriate to ever refer to the 
treatment of the entire class of traffic, including both succeed and 
failure actions and winding up in the same queue, as a single data path. I 
will argue that while the first two are obviously atomic data paths, the 
two together is an example of applying a PHB to a class of traffic, and 
constitutes an aggregate datapath. Personally, I'd rather widen the 
definition in the model than try to hobble the MIB.

That said, I would be willing to remove the controversial sentence from the 
document. We did not, but if the working group wants to do that, fine.

>"paramterisation of DiffServ functional datapath elements".

The word "treatment" has been used quite a bit to describe what we do to 
packets. I think this mostly adds to wordiness and therefore obfuscation 
without really clarifying anything. In a number of places, we swapped the 
word for "functional datapath", but by no means all.

>ifIndex and interface direction, the first DiffServ Functional Element

Done, I think. "first" usually refers to the one that happens "before all 
the rest", and is fairly common in English... However, we stuck in "the 
first Diffserv Functional Datapath Element applied to a given packet on a 
given interface is determined."

In another note, if you like, I could define "is"...

---

From: Andrew Smith <[email-masked]>
Date: Fri, 15 Dec 2000 18:31:32 -0800

Fred,

Fred Baker wrote:

>> 1. 2.1 (This comment is somewhat related to the ongoing discussion 
>> with Bob Moore on the mailing list). A term is introduced here, "Data 
>> Path", which is somewhat different to the "Datapath" idea used in the 
>> Model draft. From [MODEL]:
>> interface, single direction. The last paragraph of 2.1 could also use 
>> some clarification: e.g.
>> indicate the DiffServ processing that a packet experiences as it 
>> travels in a given direction ("in" or "out") of a given interface of a 
>> Diffserv device. A diffServDataPathTable contains entries that 
>> indicate the first of possibly multiple functional datapath elements 
>> that will apply DiffServ treatment to the packet."
>> 
>> functional datapath elements that exist for a given 
>> {interface,direction} combination? That would conflict with the usage 
>> in [MODEL] where it means just a single potential path (and thus would 
>> allow multiple such paths to merge into the same queue).
> 
> 
> actions" is one datapath, 

Yes

> and the sequence including the "failure 
> actions" is another data path, 

Yes

> and that it is inappropriate to ever 
> refer to the treatment of the entire class of traffic, including both 
> succeed and failure actions and winding up in the same queue, as a 
> single data path. 

That's going further than I intended although it would be a viable definition. 
The term "datapath" was introduced in the Model draft as a fairly general term 
to describe Diffserv sorts of things things that happen in the data plane - we 
could of course make the term more precise if there are cases that warrant it.

> I will argue that while the first two are obviously 
> atomic data paths, the two together is an example of applying a PHB to a 
> class of traffic, and constitutes an aggregate datapath. Personally, I'd 
> rather widen the definition in the model than try to hobble the MIB.

Didn't intend any hobbling, just clarification. I'm not sure what you're saying 
here: I think I agree with you if you are saying that a new "aggregate datapath" 
term is not needed. By "widen", do you mean that the term datapath should refer 
to both atomic and aggregate? I think I'd rather stick to just the atomic cases 
and use "applying a PHB to a class of traffic" rather than "aggregate datapath" 
wherever needed.

> That said, I would be willing to remove the controversial sentence from 
> the document. We did not, but if the working group wants to do that, fine.

The problem in the MIB document is the sentence "Each entry of the 
diffServQTable belongs to one and only one datapath." which is obviously not 
true for the example you gave which has two separate datapaths (by your "atomic 
datapath" definition) feeding into a single queue.

>> 9. 3 "DiffServ treatment parameterization" is used in several places: 
>> see comment 3 above, but suggest we use some other existing terms e.g. 
> without really clarifying anything. In a number of places, we swapped 
> the word for "functional datapath", but by no means all.

I think changing it in some places and not others, or even using the two 
interchangably, doesn't usually help with clarity. I guess I should wait to see 
where you've changed it and then provide detailed comments on that.

> Done, I think. "first" usually refers to the one that happens "before 
> all the rest", and is fairly common in English... However, we stuck in 
> "the first Diffserv Functional Datapath Element applied to a given 
> packet on a given interface is determined."
> 

I'm sorry, that was a serious comment that warranted a more mature response than 
that. Your proposed addition helps but is not sufficient - the scope of "first", 
I think, should be interface+direction, not just interface.

Andrew

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Dec 2000 00:38:16 -0800

At 06:31 PM 12/15/00 -0800, Andrew Smith wrote:
>I'm sorry, that was a serious comment that warranted a more mature 
>response than that. Your proposed addition helps but is not sufficient - 
>the scope of "first", I think, should be interface+direction, not just 
>interface.

thanks you for clarifying the comment enough that I could figure out what 
you intended to result from it.