Subject: RE: [Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt

From: "Faye Ly" <[email-masked]>
Date: Wed, 18 Apr 2001 12:53:32 -0700

Harrie,

Another point you mentioned is the ordering.  You are very right that I
have not addressed it.  The fact is I didn't know that some TCB text is
subject to be dropped from the [MODEL].  The proposal I proposed does
ensure the ordering to be (as you rightly pointed out):

classifier -> meter -> action (count or dropper) -> queue -> scheduler

One solution came to my mind is to add an ordering object that specify
the ordering via a string of OIDs.  Or some other numbering scheme like
assigning each table with an ENUM value and show the ENUM value order in
the ordering object.  

In conclusion, ordering can be resolved.  If by resolving the ordering
we can somehow provide NMS a more scalable MIB, I think it is well worth
it.

Your thoughts?

-faye

-----Original Message-----
From: Harrie Hazewinkel [mailto:[email-masked]]
Sent: Wednesday, April 18, 2001 12:40 AM
To: Brian E Carpenter
Cc: Faye Ly; Fred Baker; [email-masked]
Subject: Re: [Diffserv] RE: A few comments for
draft-ietf-diffserv-mib-09.txt

Brian E Carpenter wrote:
[snip]
> 2. Everybody who has an opinion to give us a binary answer within a
week:
>     - yes this TCS table is a good idea and the MIB should be changed
>     - no it isn't a good idea.

Looking just to the proposal as MIB designer/reviewer, NO.
This proposal is broken. Why?? see below.

> >
> > Change diffServDataPathStart to point to an entry in the TCS table.

If you make this change a TCS/TCB is required. Which is not the case.
You still want the 'diffServDataPathStart' to point to the other 4
datapath elements. You make a requirement for the TCB.

> >
> > TCS Table is defined as:
> >
> > INDEX {TCBIndex}
> >
> > OBJECTS
> >
> >    Classifier Filter pointer - points to a set of filters defined in
> >                                  diffServSixTupleClfrTable.  Change
> >                                the indexing of
diffServSixTupleClfrTable
> >                                to double index {ClassifierId,
ClfrId}
> >                                By specifying the classifier ID in
this
> >                                object, NMS can easily retrieve all
the
> >                                filters defined for this classifier.
> >                                The syntax of this object will be
> >                                the same as the ClassifierId defined
> >                                in the diffServSixTupleClfrTable.
> >
> >    Meter pointer - points to an entry in the meter table as defined.
> >
> >    Action pointer - points to an entry in the Action table as
defined.
> >
> >    Algorithm Drop pointer - points to an entry in the Algorithm Drop
Table.
> >    Queue table pointer - points to an entry in the diffServQTable.
> >    Scheduler table pointer - points to an entry in the
diffServSchedulerTable.
> >
> > Note that these pointers can be zeros meaning the operation should
be skipped.  Also the NEXT pointer should only be used to
> > point to the next entry in the same table.

Does this mean that you say a TCB has either 1 of these pointers??
If the Classifier Filter pointer is 'zeroDotZero' you must
follow the Meter pointer. If the Meter pointer is zeroDotZero
you must follow the Action Pointer.

However, you allow all pointers fill with RowPointers to datapath 
elements. The elements are also ordered in a sequential path
traffic can follow. In this proposal there is no such thing.
Or should I assume that the order is, classifier, meter, action,
algorithmic dropper, Queue table, Scheduler??
Maybe people want to have different orders.

This does not work. You only create more confusion for
as well MIB implementors as well management application.
The DIFFSERV-MIB already has this. You just put the RowPointer
to the first datapath element in the diffServDataPathSTart.

> >
> > This matches what is described in [MODEL]:
> >
> > "This model describes the configuration and management of a Diffserv
> > interface in terms of a TCB that contains, by definition, zero or
more
> > Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler
> > elements.  These elements are arranged arbitrarily according to the
> > policy being expressed, but always in the order here. Traffic may be
> > classified; classified traffic may be metered; each stream of
traffic
> > identified by a combination of classifiers and meters may have some
set
> > of actions performed on it, followed by drop algorithms; packets of
the
> > traffic stream may ultimately be stored into a queue and then be
> > scheduled out to the next TCB or physical interface.  "

No this is not the same. Just having a bunch of datapaths with no
ordering
is not the same. And you just want to have just a bunch of datapaths.
It is also a bit unfortenate that TCB is still mentioned here.
It is legacy text to be removed.

> >
> > The advantage of using the TCS table is to retrieve all the relevant
TCB information from one single entry.

No, the ordering information is not there. It also assumes there is only
1
of each of the datapath elements in a TCB.

> >  It also got rid
> > of the Classifier and Classifier element table by using the double
indexing scheme.  Unless other classifer is being
> > considered or else the classifier element table is not necessary. 

You need that to make more classified traffic. If I understand your
proposal
you just want 1 classified stream. Diffserv allows for more.

> > When other filter is considered, we could always add more
> > objects into the TCS table. 

You can add indeed more objects in the TCS table, but once the table is
defined
it is defined and static. Are you proposing here that you want to add
another column
to the table if you need to have 2 meters?? That is not possible.
You only can add then more entries, but since they will have a different
index
all objects (and thus the datapath elements) do not belong to the same
TCB.

> > I suspect we can further simplify the design of the meter, action, q
and scheduler tables as well
> > using the same technique.  More emails to come.
> >
> > This is just a concept proposal.  I will send MIB table definition
out if this concept is acceptable and adoptable.  Your
> > thoughts?

Do I have to say more??

Harrie
-- 
phone: +39-3474932300
http://www.lisanza.net/

---

From: "Andrew Smith" <[email-masked]>
Date: Wed, 18 Apr 2001 14:43:23 -0700

Just for clarification: as far as I know, there is nothing due for removal
from the current [MODEL] draft. I think Harrie was referring to the fact
that it was decided to remove almost all references to the TCB concept from
the *MIB* draft.

Andrew
(editor of MODEL draft)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Faye Ly
Sent: Wednesday, April 18, 2001 12:54 PM
To: Harrie Hazewinkel; Brian E Carpenter
Cc: Fred Baker; [email-masked]
Subject: RE: [Diffserv] RE: A few comments for
draft-ietf-diffserv-mib-09.txt

Harrie,
Another point you mentioned is the ordering.  You are very right that I have
not addressed it.  The fact is I didn't know that some TCB text is subject
to be dropped from the [MODEL].  The proposal I proposed does ensure the
ordering to be (as you rightly pointed out):
classifier -> meter -> action (count or dropper) -> queue -> scheduler
One solution came to my mind is to add an ordering object that specify the
ordering via a string of OIDs.  Or some other numbering scheme like
assigning each table with an ENUM value and show the ENUM value order in the
ordering object.
In conclusion, ordering can be resolved.  If by resolving the ordering we
can somehow provide NMS a more scalable MIB, I think it is well worth it.
Your thoughts?
-faye

-----Original Message-----
From: Harrie Hazewinkel [mailto:[email-masked]]
Sent: Wednesday, April 18, 2001 12:40 AM
To: Brian E Carpenter
Cc: Faye Ly; Fred Baker; [email-masked]
Subject: Re: [Diffserv] RE: A few comments for

Brian E Carpenter wrote:
[snip]
> 2. Everybody who has an opinion to give us a binary answer within a week:
> >                                the indexing of diffServSixTupleClfrTable
> >                                to double index {ClassifierId, ClfrId}
> >                                By specifying the classifier ID in this
> >                                object, NMS can easily retrieve all the
> >    Action pointer - points to an entry in the Action table as defined.
> >
Table.
diffServSchedulerTable.
> >
> > Note that these pointers can be zeros meaning the operation should be
skipped.  Also the NEXT pointer should only be used to
> > interface in terms of a TCB that contains, by definition, zero or more
> > classified; classified traffic may be metered; each stream of traffic
> > identified by a combination of classifiers and meters may have some set
> > of actions performed on it, followed by drop algorithms; packets of the
> >
> > The advantage of using the TCS table is to retrieve all the relevant TCB
information from one single entry.
No, the ordering information is not there. It also assumes there is only
1
of each of the datapath elements in a TCB.
> > I suspect we can further simplify the design of the meter, action, q and
scheduler tables as well
> > This is just a concept proposal.  I will send MIB table definition out
if this concept is acceptable and adoptable.  Your
Do I have to say more??
Harrie
--
phone: +39-3474932300
http://www.lisanza.net/

_______________________________________________
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: Harrie Hazewinkel <[email-masked]>
Date: Fri, 20 Apr 2001 09:50:00 +0200

HI Faye,

> Faye Ly wrote:
> 
> Harrie,
> 
> Another point you mentioned is the ordering.  You are very right that
> I have not addressed it.  The fact is I didn't know that some TCB text
> is subject to be dropped from the [MODEL].  The proposal I proposed
> does ensure the ordering to be (as you rightly pointed out):
> 

SO, you restrict the order by only the order as given above.
I believe the DIFFSERV-MIB does not want that.
How do I for instance, a count action and a absolute
drop action for a perticular part of a datapath??
Not possible here, since the datapath element that
follows the action is a queue and not another action.

What happens when someone wants to have an action before the meter??
For instance, after a classification on DSCP 34, I want to count all
that traffic after which I want to meter that traffic.

Correct me if I am wrong but that does not fit in your schema.

> the ordering via a string of OIDs.  Or some other numbering scheme
> like assigning each table with an ENUM value and show the ENUM value
> order in the ordering object.

If you add an ordering object, you still have the problem when you want
2 actions. In this proposal you can neither have a split in a datapath,
ie. after a meter how do you handle a FailNext and SucceedNext??
You cannot you have only 1 pointer. Or am I missing something??

> we can somehow provide NMS a more scalable MIB, I think it is well
> worth it.
> 
> Your thoughts?

As Brian mentioned, the amount of datapath elements and so
will be at a reasonable scale. Your proposal neither seems
to reflect what is needed from the DIFFSERV-MIB.

Harrie

PS: I am not taking anyside on whether to add it or not.
I just look at the proposal which I think does not work
for what it needs to represent.
-- 
phone: +39-3474932300
http://www.lisanza.net/

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 Apr 2001 17:06:44 -0700

>I believe the DIFFSERV-MIB does not want that.

yes. That is exactly what was originally proposed, and folks asked for 
things like CBQ hierarchical queuing support, or the ability to support 
multiple actions (both counting and RED dropping, for example), or the 
ability to cascade schedulers (use priority scheduling for some queues and 
some form of processor sharing for the rest, for example). So we 
specifically made it general enough that one can string together whatever 
one likes, like tinker toys.