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

From: "Kwok-Ho Chan" <[email-masked]>
Date: Tue, 17 Apr 2001 18:41:50 -0400

Faye:

We have been down this road before (may be not exactly but
similar).

Your proposal resembles what used to be in the "Target Table"
of

the original DiffServ PIB.  The original Target Table entries tie
together

Classifiers, Meters, Actions, Droppers, Queues, Schedulers.

There was consensus amongst the co-authors to make the PIB to look

like the MIB instead of the other way arround, hence the RowPointer

linkage today in both MIB and PIB.

There was also the concerns with SNMPCONF WG's usage of the

DiffServ MIB.

Just some history.

-- Kwok --

At 11:22 AM 4/17/01 -0700, Faye Ly wrote:

Fred,

Certainly.  More emails will follow this one as the
proposed changes may require more description.

Proposed change:

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

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.

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.
"

The advantage of using the TCS table is to retrieve
all the relevant TCB information from one single entry.  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.  When other filter is
considered, we could always add more objects into the TCS table.  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?

-faye

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

From: Fred Baker
[mailto:[email-masked]]

Sent: Friday, April 13, 2001 10:58
PM

To: Faye Ly

Cc: [email-masked]

Subject: Re: A few comments for
draft-ietf-diffserv-mib-09.txt

At 03:23 PM 4/13/2001 -0700, Faye Ly
wrote:

>Hi,

>I apologize but I haven't gotten a chance to
subscribe to the diffserv

>list yet.  (With the IPO mailing list experience, I am not sure I
want to

>:)-)  Please feel free to forward this to the mailing list if
appropriete.

>-faye

>=========================================================================================

>Hi,

>Here are some comments for
"draft-ietf-diffserv-mib-09.txt".

>1. The major problem I see with this MIB is the
usage by NMS.  The tables

>defined are not very 'friendly' for NMS retrieval.  For example, in
order

>to find out the filter being applied to a subscriber
Joe.

>     1.1 NMS has to first get the logical
interface entry for Joe and

> derive the datapath entry.  For our discussion, I don't count the
SNMP

> packets required to get here.

>     1.2 It then issue a SNMP get to retrieve the
classifier entry using

> the DataPathStart object.

>     1.3 Using the ClfrId retrieved from the
classifier table, NMS issues

> another SNMP getnext to retrieve the Classifier element until all

> elements associated with this classifier are retrieved.

>     1.4 NMS issue SNMP get on each Specific
object to retrieve the six

> tuple classification entry for Joe.

>It takes NMS a minimum 4 SNMP requests to
retrieve a single filter for a

>particular subscriber.  This is not scalable for NMS that typically
has to

>deal with minimum thousands of subscribers.  A suggestion is to
eliminate

>the Classifier table and have the Datapath table simply provide an
INTEGER

>pointer point to the Classifier ID in the Classifier Element Table OR

>meterId in the Meter table OR ...   Note that the reverse pointer
from

>the, say Meter table, back to the Classifier table requires the
Classifier

>ID only.

That is pretty much where we started out. We changed
to RowPointer in

response to requests from the working group to allow folks to easily add

new filter types, such as picking out messages by MAC Address etc. If you

have a specific proposal that would allow for the flexibility we were
asked

to provide and addresses your concern (and I agree that this is a lot of

round trips), I'd like to hear it.

>2. For a full classifier, meter, actions,
dropper, queue and scheduler can

>be linked all together via the rowPointer.  This is although very
smart

>but again if the NMS is trying to get all the SLA provisioned on a
single

>system.  It has to traverse through 6 tables or more in order to get
a

>single flow's SLA.  Again not very scalable.  An alternative is to
place

>all these table pointers into a single data path table or profile

>table.  The profile table will have separate object specifying the

>relationship between all these tables for a single SLA.  The table
pointer

>will be NULL if a certain SLA doesn't require, for example, any queue
to

>be specified.  The datapath table in turns will be assigned with a
single

>profile.

Could you be more specific? Can you advise how
hierarchical systems such as

CBQ would be described using your approach?

_______________________________________________
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: "Andrew Smith" <[email-masked]>
Date: Tue, 17 Apr 2001 16:56:25 -0700

Faye's concern gets to the heart of whether it is best to try to have a
single data structure to access information for configuration operations
(a.k.a. "SET") and for monitoring operations (a.k.a. "GET" or "GETNEXT").
Between the Diffserv MIB, Diffserv PIB, Diffserv Policy MIB and assorted
Diffserv Schemas, I think the current state of the IETF efforts on this
topic can best be described as "pragmatic" (or, less charitably, as
"confused").

As it stands, the Diffserv MIB is suboptimal for monitoring (Faye provides
some good examples of how) and is, on its own without help from the snmpconf
Diffserv Policy MIB, highly suboptimal for configuration. My advice would be
to wait for either the snmpconf work or the COPS Diffserv PIB to stabilise
before designing any Diffserv configuration application (and you'll probably
be needing to write some proprietary MIBs for efficient monitoring of
Diffserv on anything other than a small scale).

Andrew
(speaking as a lazy co-author of both Diffserv PIB and Diffserv MIB
documents)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Kwok-Ho Chan
Sent: Tuesday, April 17, 2001 3:42 PM
To: Faye Ly
Cc: Fred Baker; diffserv
Subject: Re: [Diffserv] RE: A few comments for
draft-ietf-diffserv-mib-09.txt

Faye:
We have been down this road before (may be not exactly but similar).
Your proposal resembles what used to be in the "Target Table" of
the original DiffServ PIB.  The original Target Table entries tie together
Classifiers, Meters, Actions, Droppers, Queues, Schedulers.
There was consensus amongst the co-authors to make the PIB to look
like the MIB instead of the other way arround, hence the RowPointer
linkage today in both MIB and PIB.
There was also the concerns with SNMPCONF WG's usage of the
DiffServ MIB.
Just some history.
-- Kwok --

Fred,

Certainly.  More emails will follow this one as the proposed changes may
require more description.

Proposed change:

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

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.

   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.

"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.  "

The advantage of using the TCS table is to retrieve all the relevant TCB
information from one single entry.  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.  When other filter is considered, we could always add more
objects into the TCS table.  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.

-faye

-----Original Message-----
From: Fred Baker [mailto:[email-masked]]
Sent: Friday, April 13, 2001 10:58 PM
To: Faye Ly
Cc: [email-masked]
Subject: Re: A few comments for draft-ietf-diffserv-mib-09.txt

At 03:23 PM 4/13/2001 -0700, Faye Ly wrote:

>Hi,
>
>I apologize but I haven't gotten a chance to subscribe to the diffserv
>list yet.  (With the IPO mailing list experience, I am not sure I want to
>:)-)  Please feel free to forward this to the mailing list if appropriete.
>
>-faye
>
>Here are some comments for "draft-ietf-diffserv-mib-09.txt".
>
>1. The major problem I see with this MIB is the usage by NMS.  The tables
>defined are not very 'friendly' for NMS retrieval.  For example, in order
>to find out the filter being applied to a subscriber Joe.
>
>     1.1 NMS has to first get the logical interface entry for Joe and
> derive the datapath entry.  For our discussion, I don't count the SNMP
>     1.2 It then issue a SNMP get to retrieve the classifier entry using
>     1.3 Using the ClfrId retrieved from the classifier table, NMS issues
>     1.4 NMS issue SNMP get on each Specific object to retrieve the six
>It takes NMS a minimum 4 SNMP requests to retrieve a single filter for a
>particular subscriber.  This is not scalable for NMS that typically has to
>deal with minimum thousands of subscribers.  A suggestion is to eliminate
>the Classifier table and have the Datapath table simply provide an INTEGER
>meterId in the Meter table OR ...   Note that the reverse pointer from
>the, say Meter table, back to the Classifier table requires the Classifier
>ID only.

That is pretty much where we started out. We changed to RowPointer in
response to requests from the working group to allow folks to easily add
new filter types, such as picking out messages by MAC Address etc. If you
have a specific proposal that would allow for the flexibility we were asked
to provide and addresses your concern (and I agree that this is a lot of
round trips), I'd like to hear it.

>2. For a full classifier, meter, actions, dropper, queue and scheduler can
>be linked all together via the rowPointer.  This is although very smart
>but again if the NMS is trying to get all the SLA provisioned on a single
>system.  It has to traverse through 6 tables or more in order to get a
>single flow's SLA.  Again not very scalable.  An alternative is to place
>relationship between all these tables for a single SLA.  The table pointer
>will be NULL if a certain SLA doesn't require, for example, any queue to
>be specified.  The datapath table in turns will be assigned with a single
>profile.

Could you be more specific? Can you advise how hierarchical systems such as
CBQ would be described using your approach?

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Apr 2001 08:27:56 -0500

Andrew,

It has always been understood that either SNMPCONF or the PIB
would be necessary for diffserv configuration - indeed that is a major
reason why SNMPCONF was started at all. There is no news there.
Yes, it's pragmatic, but I don't see the confusion.

Since the WG agreed that the MIB should not represent TCBs, you and
Faye need to respond to Harrie's arguments.

Multiple SNMP GETs are suboptimal for monitoring? Is that news?

   Brian

---

From: "Andrew Smith" <[email-masked]>
Date: Wed, 18 Apr 2001 09:27:04 -0700

Brian,

My issue is that compromises were made in the Diffserv MIB in order to
accomodate those who wanted to use it for configuration. Those compromises
make it quite a lot less efficient for monitoring than it needs to be. You
are oversimplifying with your somewhat flippant comment "Multiple SNMP GETs
are suboptimal for monitoring? Is that news?". We have been over the
specific inefficiencies on this list and the WG consensus was to keep them
in there.

I am not supporting Faye's specific changes, although I don't agree with all
of Harrie's criticisms of it. I'm merely pointing out some characteristics
of the Diffserv MIB that are not obvious until you get deep into the
details. Standards'-track MIBs are not required to have an "Applicability
Statement" attached but perhaps they should be.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Brian E Carpenter
Sent: Wednesday, April 18, 2001 6:28 AM
To: [email-masked]
Cc: Kwok-Ho Chan; diffserv; Faye Ly
Subject: Re: [Diffserv] RE: A few comments for
draft-ietf-diffserv-mib-09.txt

Andrew,

   Brian

Table.
appropriete.
INTEGER
Classifier
asked
pointer
> Archive:

Archive: