Subject: [Diffserv] Summary of feedback on conceptual model draft

From: "Yoram Bernet (Exchange)" <[email-masked]>
Date: Tue, 9 Nov 1999 18:11:04 -0800

Steve, Andrew:

Brian presented Steve's slides at the diffserv WG meeting last night. I
attempted to represent your last round of changes to the draft as faithfully
as possible. Though i'm not the official scribe of the meeting, I took notes
regarding feedback on the draft. Others that attended - pls feel free to
jump in and correct as appropriate...

Here goes:

1. As noted by STeve, the term 'mirroring' needs to be replaced. Suggested
alternatives included:
splitter, tee, tap (as in wire-tap), inverse-mux... 
I think that the point is to use a term that makes it clear that this is a
logical copy, not a physical copy (as in for example, multicast).

2. Some expressed the opinion that the abstraction of queus in terms of max
rate/min rate is too simplistic to implement the queuing mechanisms that
they envisioned. Others (including at least on emajor router
vendor/implementor) indicated that the queuing abstraction in the draft
enables the expression of a variety of queuing mechanisms including those
that are most used. Suggestion to those who are not happy with the current
abstraction - write to the mailing list. Dan Grossman offered to submit text
on this to the list. 

Aside: A recurring theme realted to the purpose of the draft and the nature
of indirection intended. The draft attempts to identify the *types* of
traffic conditioning elements (e.g. meter, classifier, etc.) and to offer a
minimal set of *sub-types* of these types, with the parameter set that would
be appropriate. For example - a 'classifier' is a TC element and a BA
classifier is a sub-type of a classifier that has a six-bit field as its
only parameter. The draft *does not* state that the set of sub-types is
exhaustive. On the contrary, it suggests that anybody can define a new
sub-type, by specifying the parameter set that is appropriate (and the name
of the new sub-type). The draft *offers* a minimal set of sub-types that is
believed to be useful and necessary for realizing basic implementations of a
diffserv router. 

Some suggested that the draft should not define any 'sub-types'. However,
the counterpoint presented is that without specifying a minimal set of
sub-types, the draft would not go far enough as it would not fulfill its
purpose of  specifying the basis of a diffserv MIB needed to implement a
diffserv router. Since the draft allows for additional sub-types to be
defined in other drafts, there is no harm in offering a minimal subset in
this draft.

3. There was a discussion of whether the queuing parameters should include 
a. a value and a flag indicating whether that value is a max rate or a min
rate.  
b. two values, one for max rate, one for min rate
Suggestion was made that 'b' is preferrable, as it would allow for the
specification of both a max and min rate simultaneously. It would also allow
for a special value to indicate 'unspecified' min rate and/or max rate.

4. There are words in the Glossary  (section 2) to the effect that a TCB has
a "single input and output". This conflicts with some of the sample TCB
diagrams and was believed by the group to be overly restrictive. A TCB
should be allowed to have an arbitrarty number of inputs/outputs. One of the
slides presented, suggested a 1:1 nature of a TCB. Nobody really understood
what was meant by this. We assumed that it referred to the 1 input, 1 output
restriction, which should be removed.

5. There are words in the draft to the effect that a monitor 'increments'
for every packet passing through it. This was also believed to be overly
restrictive and the suggestion was made that it be specified as something
that simply 'counts', with no specification as to whether it counts 'up' or
'down'.

6. There was a suggestion that we look at the 'RFC for the cable device MIB'
for an example of traffic conditioning abstractions.

7. There was some discussion regarding the emphasis/de-emphasis of RSVP as a
configuration mechanism. The following points were made:
a. to the extent that it is mentioned, it should be cited as an *example of
one mechanism* to effect configuration.
b. that it should be captured as a 'qos configuration box'.
c. that it should not simply be captured as a 'qos configuration box'
because there is already a box titled 'diffserv config and management
interface' and that the box labeled RSVP is sufficiently different because
it represents a configuration mechanism that tends to be much more dynamic
and much finer grain (per-microflow) a mechanism than represented by its
diffserv config counterpart.
d. that MPLS is another example of the need for a dynamic, finer grain
configuration mechanism that justifies using two boxes to represent the
different types of configuration.

8. The question was asked as to whether MPLS support required anything
additional. Response was that the only requirement for MPLS appears to be
that the model support a classifier sub-type for MPLS.

That's all I have.

Yoram