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

From: "Faye Ly" <[email-masked]>
Date: Tue, 17 Apr 2001 11:22:37 -0700

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?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Apr 2001 14:16:47 -0500

Faye,

We did discuss several times whether TCBs should be explicit in the MIB, and a number
of people indicated that this would be an unwanted constraint on implementations.
So my guess is that we will get opinions both for and against a TCS table. Given that
this MIB is already a year late, it would take a very clear WG consensus to make
such a change. I'm not saying we won't get such a consensus, but I think Fred needs
to get the next MIB version out without this change. So I request two actions:

1. Fred to get the MIB out on the basis of what he has already agreed to change.
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.

(Faye, the consensus on this will be formed on the diffserv list, and if you
don't join the list, you can't be certain of seeing all the relevant mail.)

Thanks
    Brian Carpenter
    diffserv co-chair

> Faye Ly wrote:
> 
> Fred,
> 
> Certainly.  More emails will follow this one as the proposed changes may require more description.
> 
> Proposed change:
> 
>    Algorithm Drop pointer - points to an entry in the Algorithm Drop Table.
>    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.
> 
> 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
> 
> >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,
> >
> >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
> >     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
> >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
> >the, say Meter table, back to the Classifier table requires the Classifier
> >ID only.
> 
> 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
> >2. For a full classifier, meter, actions, dropper, queue and scheduler can
> >but again if the NMS is trying to get all the SLA provisioned on a single
> >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

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org

_______________________________________________
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: Wed, 18 Apr 2001 09:39:37 +0200

Brian E Carpenter wrote:
[snip]
>     - 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.

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

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

Do I have to say more??

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