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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Apr 2001 15:19:42 -0500

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
> 
> -----Original Message-----
> 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
> Subject: Re: [Diffserv] RE: A few comments for
> draft-ietf-diffserv-mib-09.txt
> 
> 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)
> >
> > -----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 --
> >
> > 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.h
> > tml
> >
> > _______________________________________________
> > 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

_______________________________________________
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: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Apr 2001 16:54:48 -0500

I detect agreement here - if there is a requirement for 1000s of classifiers
in one box, a special purpose monitoring solution will be needed anyway. 
I never envisaged the current MIB being used for more than a handful of
classifiers per interface. 

    Brian

Andrew Smith wrote:
> 
> Brian,
> 
> 1. Several thousands of interfaces per SNMP agent is not at all uncommon
> these days.
> 2. Several thousands of classifier elements on one interface at the edge of
> a particular Diffserv domain is not unlikely either: it is only the middle
> of a Diffserv domain that benefits from the 64 limit (for some appropriate
> definitions of "middle" and "edge").
> 
> Probably no need for both of these thousands at the same time though.
> 
> One solution, of course, would be to implement an appropriately powerful
> supercomputer for the management plane (I'm less concerned about the
> network-bandwidth requirements than processing cycles for the SNMP protocol
> operations). The traditional alternative to this has been some sort of
> proprietary "encoded octet string" representation to pack the data and
> indexing into PDUs, passing the processing burden largely to the management
> station. The latter approach usually sells better.
> 
> Andrew
> 
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Brian E Carpenter
> Sent: Wednesday, April 18, 2001 1:20 PM
> To: Faye Ly
> Cc: diffserv
> > 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
> > > Archive:

---

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

Brian,

Andrew

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

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.

   Brian

> > From: [email-masked] [mailto:[email-masked]]On Behalf
Of

---

From: "Andrew Smith" <[email-masked]>
Date: Wed, 18 Apr 2001 15:41:21 -0700

re Numbers of classifiers: then there should be an added disclaimer
(Applicability Statement) that says this MIB is meant only for Diffserv Core
nodes, not Edge nodes and we should probably go back to the original
BA-classifier-only version (-01 I believe). That would be a shame but it
might be more honest.

re Numbers of interfaces: I don't think I yet understand your position on
this (1000s of interfaces per box implies 1000s of classifiers per box -
that's physics).

But some of these scaling issues are resolvable, for configuration
operations, by the use of "template" mechanisms, as in the SNMPCONF work
(that makes the writable part of this Diffserv MIB somewhat moot, in my
opinion). We haven't yet seen much work on this topic for monitoring
operations (RMON-like mechanisms don't help - they help scale the time axis,
not the "number of instances" axis) so we should do all we can to optimise
the utility of this MIB for monitoring at the present time using existing
protocols (specifically SNMP/GETBULK).

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Brian E Carpenter
Sent: Wednesday, April 18, 2001 2:55 PM
To: Andrew Smith
Cc: diffserv
Subject: Re: Scaling of management plane for Diffserv (was RE:
[Diffserv] RE: A few comments for draft-ietf-diffserv-mib-09.txt)

    Brian

Andrew Smith wrote:
> > Can we at least be willing to deal with the 'optimization' issue with
this
> MIB?
> > > >list yet.  (With the IPO mailing list experience, I am not sure I
want
> to
> > > >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
> > > >2. For a full classifier, meter, actions, dropper, queue and
scheduler
> can
> > > Could you be more specific? Can you advise how hierarchical systems
such
> as

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Apr 2001 09:01:04 -0500

Andrew,

There will be lots of enterprise and ISP edge routers with modest numbers 
of interfaces. An MF classifier MIB is entirely appropriate for them. That 
is indeed what we've been working on for the last couple of years.

You are referring to consumer-subscriber edge boxes and that is certainly
a different ball game. We could argue philosophy here (will we be
applying diffserv per home user or per small office user?) but for
present purposes I agree that we should qualify the diffserv MIB as not
scaling to that situation.

Fred, can you insert an appropriate applicability sentence?

    Brian

---

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

>Fred, can you insert an appropriate applicability sentence?

of course.