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

From: Fred Baker <[email-masked]>
Date: Fri, 13 Apr 2001 22:52:44 -0700

>Subject: A few comments for draft-ietf-diffserv-mib-09.txt
>Date: Fri, 13 Apr 2001 15:23:13 -0700
>Thread-Topic: A few comments for draft-ietf-diffserv-mib-09.txt
>Thread-Index: AcDEaD9bSUtfVC3PEdWeBQABA7y1rw==
>From: "Faye Ly" <[email-masked]>
>To: <[email-masked]>, <[email-masked]>,
>         <[email-masked]>
>Cc: "Faye Ly" <[email-masked]>
>
>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.
>
>Does this make sense or did I totally miss the point of your table 
>rowpointer design?
>
>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.
>
>Your thoughts?
>
>-faye

_______________________________________________
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: Fred Baker <[email-masked]>
Date: Fri, 13 Apr 2001 22:58:00 -0700

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

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.

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

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

---

From: "Faye Ly" <[email-masked]>
Date: Wed, 18 Apr 2001 10:51:45 -0700

Harrie,

RowPointer is used to represent a 1:1 relationship between table
entries.  Straight integer pointer (for example, using the index field
from another table) can be used to represent 1:N relationship between
entries from 2 tables.  The proposal actually proposes using the
straight integer as the pointer, not RowPointer.  In another words, you
can easily group a group of classifier elements into one classifier and
have the ClassifierStart simply point to the classifier index.  NMS can
easily traverse the classifier element table to retrieve all the
classifier elements associated with one classifier.  For example:

To traverse the classifier element table that is sorted as:

ClassifierId   ClassifierElementId
1              1
1              2
1              3
2              1
2              2

NMS retrieves the ClassifierStart that is set to 1, it then issues SNMP
getbulk with the following instance value:

1,0

Agent will return {1,1 1,2 and 1,3 ...}  however many rows that is
required in the getbulk request.  This will save a lot of management
bandwidth on the wire and NMS has all the classifier elements associated
with one classifier in one SNMP round trip.  

-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: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Apr 2001 08:45:49 -0500

I can't make the layout look right since your user agent sends HTML...

Are you suggesting that the problem you want to solve needs a separate solution from
the basic MIB? It begins to look like that.

I don't think the DSCPs will get modified during retrieval process, unless
the NMS itself allows this, or unless some third party interferes.

   Brian

> Faye Ly wrote:
> 
> Brian,
> 
> You actually brought up a very good point.  Each subscriber will have only maybe up to 2 DSCP levels.  But NMS has to deal
> with hundreds of subscribers per network device that supports diffserv.  Let's say this network device supports only 16 DSCP
> levels but NMS has to be able to read each subscriber DSCP level somehow via the diffserv MIB.  In another words, there might
> be hundreds of data path's but only a few (e.g. 16) classifiers.
> 
> NMS could retrieve the 16 DSCP configurations (may this be a linked list of classifier, meter, action ...) first and then
> retrieve each individual subscriber's information by getting the datapath entries.  NMS can do the OID matching easily in it's
> database.
> 
> This only presents a problem that there might be a small window that these 16 DSCP levels may be changed during the retrieval
> of the datapath entries?
> 
> -faye
> 
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2001 1:20 PM
> To: Faye Ly
> Cc: diffserv
> Faye,
> Can you clarify the point about thousands of subscribers for me? Diffserv deals with
> a small number of traffic aggregates - by construction, at most 64 including best effort.
> So diffserv technology, including the management plane, only has to scale to 64 queues
> per interface, and that is a very theoretical number, with just a few queues more
> likely.
> 
> If you are talking about scaling to thousands at the NMS, then my remark about
> SNMP GETs is not frivolous because we aren't talking about saving a small factor;
> I can't see any solution at that scale that isn't bulked up much more than a generic
> per-interface per-queue MIB is ever going to support.
> 
> That doesn't mean I'm against optimising the MIB somewhat of course, but it
> won't fundamentally affect scaling as far as I can see.
> 
> I suspect you are asking for what is fundamentally a diagnostic MIB to
> behave like a bulk monitoring MIB, and maybe that is simply a different
> beast.
> 
>    Brian
> 
> > Faye Ly wrote:
> >
> > Brian,
> >
> > Actually that is exactly why people started developing their own proprietary MIB.  The MIB simply does not scale to hundreds
> 
> > or thousdands (if you take snmpconf-diffpolicy draft into account) subscribers in the network.  Some optimization is needed
> to
> 
> > make this MIB 'friendly' to the NMS tools.  Note that some NMS tools typically will come and refresh it's database
> > periodically (daily or weekly).  This MIB requires a subtantial amount of time to do so.  Note that NMS has a problem that
> not
> 
> > all configuration are done via the same tool and hence NMS is forced to refresh it's database from time to time.
> >
> > Can we at least be willing to deal with the 'optimization' issue with this MIB?
> >
> > -faye
> >
> > From: Brian E Carpenter [mailto:[email-masked]]
> > Sent: Wednesday, April 18, 2001 6:28 AM
> > To: [email-masked]
> > Cc: Kwok-Ho Chan; diffserv; Faye Ly
> > 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
> >
> > Andrew Smith wrote:
> > >
> > > 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)
> > >
> > > 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
> > > 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:
> > >
> > >                                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.
> > >
> > >    Algorithm Drop pointer - points to an entry in the Algorithm Drop Table.
> > > 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.
> > >
> > > 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.  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
> > >
> > > 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
> > >
> > > _______________________________________________ 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
> > >

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

---

From: "Faye Ly" <[email-masked]>
Date: Fri, 20 Apr 2001 10:02:04 -0700

Harrie,

Yes, I think we are in violent agreement that no ordering should be
forced
by the MIB.  Only implied as a linked list by the current MIB design.  

Let's try to look at the MIB design from another angle:

If we try to vidualize a NMS screen that allow you to provision
a 'flow' or a 'data path', one way will be listing all the possible
items
you can pick from and this includes all the classifier, meter, action
...
Very unfortunately we have to list all the options on a single screen
and
other screens will popup based on the selection such as six-tuple
filters.

A GUI becomes a lot less flexible than a straight command line in this
case
given the MIB designed.  But this MIB works perfectly well if you allow
customer to enter configuration via command line like interface.  This
is a
pure design issue but with my personal experience, GUI works much better
if
you list all the things out explicitely and all the customer needs to do
is to
point and click. 

If you agree with this kind of NMS screen design, you will find that we
will
have to provide all the selections (classifier, meter ...) in one screen
or
one table.  
Why not make the MIB match it?  If certain ordering is to be enforced as
the 
current linked list MIB objects indicated, we can always design a smart
MIB 
object to dictate the ordering.  That is, customer can specify it
explicitely.

Another point you mentioned is multiple actions, this is a relatively
easy
issue.  Just have a double indexed action table and the problem is
solved.

At this point, I suspect the list doesn't really want to change the MIB
design.
I will most likely use portion of this MIB and portion of proprietary
MIB. 
Thank you very much for all your inputs though as they are all very
helpful to
me. 

-faye  

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

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):
> 
> classifier -> meter -> action (count or dropper) -> queue -> scheduler

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.

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

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

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

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:53:38 -0700

At 10:02 AM 4/20/2001 -0700, Faye Ly wrote:
>a 'flow' or a 'data path', one way will be listing all the possible items
>you can pick from and this includes all the classifier, meter, action ...
>Very unfortunately we have to list all the options on a single screen and
>other screens will popup based on the selection such as six-tuple filters.

true, but as your words imply, that is not the only way to design the screen.

When I write a document, I use an outline generator called "Inspiration". I 
like it, it's a good tool, and it allows me to do a number of fairly 
flexible things. One of the things it enables me to do is easily build flow 
charts, such as the ones I deployed in 
ftp://ftpeng.cisco.com/fred/diffserv/Diffserv-MIB.htm, which is the 
presentation I used when I originally proposed this approach to the MIB to 
the working group in Oslo.

I'd suggest you glance through it. You get a flavor of my thinking at the 
time, some of which has been retained.

Now, the tool I used to build those flow charts, Inspiration, gives me some 
simple graphics and the ability to link them together by pointing and 
clicking. I am not a GUI designer, but if I were designing a GUI for using 
this MIB to configure, my GUI would have a lot of the same characteristics. 
It would have a think I could grab and drop in place for each kind of 
meter/action/etc, and it would allow me to link them together in certain 
ways, and it would allow me to easily parameterize the various boxes I was 
putting in.

The relationship between the SNMP stuff and the pictures on the screen 
would be apparent to someone who knew the MIB, but not determined by the 
structure of the MIB. every arrow on the screen would correspond to a 
RowPointer, for example, but every RowPointer in the MIB need not show up 
as an arrow. the idea behind the mumble-specific pointers, for example, is 
to be able to write something down once and apply it may times. If I were 
configuring a role, and then applying the role to the interface, I don't 
know that the fact of the mumble-specific pointer would appear on the 
screen at all - I suspect it would be a fact hidden by the tool. I can also 
imagine that there might be some templates built into the tool, that 
allowed you to say "I want to configure one EF and three AF classes" and 
then start filling in blanks.

As to the counters coming out, I suspect that I might put them into a 
format I could easily import to a plotter or spread sheet.

I don't see how all this relates to the UI in any way, frankly, unless the 
UI is being designed in a very simplistic manner that only supports a very 
limited set of features... SNMP is not designed to be a user interface, or 
to guide the development of user interfaces. It is intended to be a machine 
to machine language that lets whatever the UI did to materialize somewhere else.