Subject: RE: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 6 Nov 2001 14:46:52 +0200

So, would the following DS-MON MIB changes be satisfactory?

- Rename the *DS-MON aggregation* to something else to avoid confusion
with the *diffserv aggregates*
- Support the *diffserv aggregates*, maybe by mapping the rename *DS-MON
aggregates* into the *diffserv aggregates*

If the answer is yes, we still need to hear the opinion of the DS-MON
MIB author. I am just looking at it from the perspective of the
implementation of DS-MON together with other RMON family protocols. 

Regards,

Dan

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 2:16 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; Harrie Hazewinkel; 
> [email-masked]; Diffserv
> Subject: Re: [Diffserv] RE: Differences between DSMON-MIB and 
> DIFFSERV-MIB
> 
> 
> snipping...
> 
> "Romascanu, Dan (Dan)" wrote:
> > 
> ...
> > I would like to point to two separate issues here:
> > 
> > - It seems to me that there might be cases when the 
> aggregation concept
> > is two little or two much from a monitoring tool point of 
> view. It might
> > be too little if the aggregation applies to a specific policy
> > administrative domain, and packets that are monitored at a certain
> > monitoring point are the result of them originating from 
> such different
> > domains. It may be two much because in some real life situations an
> > operator may need (or may be forced to use because of the 
> limitations of
> > his monitoring probe) a coarser set of code points values 
> (like default
> > and 'all-but-default')
> 
> But the point is that this form of aggregation is pretty much
> orthogonal to the diffserv architecture. It's meaningless, in terms
> of diffserv, to add together the statistics of separate traffic
> aggregates (yes, the word "aggregate" already has a very specific
> meaning in diffserv, and it is different from the usage in DSMON.)
> The only case where it might make sense is for PHB groups. 
> The DSMON "aggregates" *in any case* need to be renamed, to avoid
> confusion with diffserv traffic aggregates. 
> 
> Frankly I don't see the point. Nobody expects to deploy real diffserv
> networks with more than a few traffic classes (i.e. DSCPs) active.
> In any case, the theoretical maximum (64) is a small number. Why not
> just monitor DSCPs? (I agree that an "everything else" bucket 
> is useful,
> at least for presentation.)
> 
> > - The other issue is that DiffServ MIB is designed to run 
> in diffserv
> > routers. It makes assumptions about the agent understanding how such
> > routers work, and you need this understanding even in the read-only
> > mode. One cannot make such assumptions about all RMON probes.
> 
> Correct, that is a valid point: a pure probe can't be expected to
> have full knowledge of the diffserv configuration. Equally, it
> can't measure everything, for example it can't count packet drops,
> which is one of the basic metrics of a diffserv traffic aggregate.
> But why can't it use the same concept of traffic aggregates as
> the DSMIB, and count a subset of the same things?
> 
> ...
> > >
> > 
> > yes, there is a 'fundamental' issue here. The issue is in 
> my opinion the
> > difference between a MIB focused on device management, and a MIB
> > focusing on network level monitoring. According to my operational
> > experience, these two views are complementary, and are both needed.
> 
> No disagreement there. But they can be complementary without
> being inconsistent.
> 
>    Brian
> 

_______________________________________________
diffserv mailing list
[email-masked]
https://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: Tue, 06 Nov 2001 15:07:15 +0100

Dan,

I think this is a good compromise approach, since I doubt if you
want to start again :-)

> with the *diffserv aggregates*

Right, something like "DS-MON summary" since it summarizes data
for a number of diffserv aggregates.

> aggregates* into the *diffserv aggregates*

This is easy. A diffserv aggregate is just all the traffic marked with
the same DSCP on a given link in a given direction. (The formal definition
is in the terminology section of RFC 2474.) So since DSMON is driven by DSCPs,
you are already summing diffserv aggregates to create your aggregates/summaries.

There's one subtlety here which is not yet in an RFC, the concept of an
"ordered aggregate" where multiple PHBs within a PHB group are applied
to the same traffic flow, requiring a packet ordering constraint. This
is a case where summing the counters *does* make sense. 
draft-ietf-diffserv-new-terms-05.txt (-06.txt imminent) discusses this.

> implementation of DS-MON together with other RMON family protocols.

Understood
   
Regards
   Brian

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