Subject: RE: (FRNETMIB) FR SLA MIB - Issue 2 - Free the Freerunning Counts !

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 11 May 2000 16:53:40 +0200

RFC2493,
	which defines TC for 15 minute interval statistics

	Bert

> ----------
> From: 	Rehbehn, Kenneth[SMTP:[email-masked]]
> Sent: 	Tuesday, May 02, 2000 10:27 PM
> To: 	[email-masked]
> Subject: 	(FRNETMIB) FR SLA MIB - Issue 2 - Free the Freerunning
> Counts!
> 
> > > 2) The frsldPvcDataTable is a table of free-running counters.  This
> > > means
> > > that the time period for the min, max, and average variables in the
> > > frsldPvcDataTable would be infinite, making these values
> > > meaningless.
> > > What's the point?
> > 
> > The min, max and avg values in the data table were discussed in
> > Washington.  I pointed the same thing out there, and this correction
> > was acceptable at the time.  From the meeting minutes:
> > 
> >      Rob pointed out an error in the document on
> >      frsldPvcDataDelayMin/Max/Avg.  The reference is to the
> >      free-running table and this should have relevance only to the
> >      free running world. This will be corrected.
> > 
> > Further, I showed this change again in Adelaide.  We can either alter
> > the text to state how the object  decay should be handled or add a
> > variable to show the life span of the value.  This would bring up
> > implementation issues as to whether to use a sliding window or a
> > polled window.  I don't feel comfortable removing the values in that
> > they are needed if the implementation chooses not to do any sampling.
> > What would you prefer?
> 
> 
> If Min/Max/Avg don't make sense in a table of free running counts then
> they
> should be removed.  Don't add complexity by adding concepts such as object
> decay or life span.  Eliminate the objects.
> 
> If an implementation chooses not to do any sampling then the
> implementation
> can live with the choice.  It is simple enough to use frsldSmplCtrlTable
> to
> structure a longish period of time which will be able to snag the
> Min/Max/Avg.  Don't overload the free running counts to do this.
> 
> Staring at this makes me wonder - why do we even need free running
> counters?
> This MIB should be restricted to the historical record as delimited by the
> interval boundaries.  The MIB seems to be both a source of raw material
> for
> some manager that then "cooks" the data for reporting AND a source of
> "cooked" data for a manager to report.  Pick one approach and stick with
> it!
> I recommend the "cooked" data approach as found in the sample tables.  How
> these tables get created is an implementation specific issue.
> 
> In conclusion, remove the table free running counters.
> 
> Focus the MIB on reporting SLA results - not the mechanism for building
> the
> results.
> X-Info: To unsubscribe, email [email-masked]' with
> X-Info: 'unsubscribe frnetmib' in the body of the message.
> 
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe frnetmib' in the body of the message.