Re: PerfHist-TC-MIB

["C. M. Heard/VVNET, Inc." <[e-mail]>]

On Fri, 5 Jun 1998, Rajesh Abbi wrote:

> Chunhui Teng wrote:
[ ... ]
> >
> > I remember somewhere in the draft it is indicated that some values might
> > decrease, i.e., not 'monotonically increasing'. For example, some seconds
> > may be counted as "Errored Seconds" but later it is found that they should
> > not be counted in (this decision can not be made any earlier), so you will
> > have to subtract number of them (seconds) from the total count.
> >
>
> Are you serious ?

Yes :-)

>
> This is 'flaky behavior' in any equipment ! After a second has expired,
> it was either 'errored' or 'non-errored'.  If the equipment cannot make
> a determination, it cannot just increment the counter and change its
> mind later.
>

The problem is that the definitions of available time and unavailable
time do not permit you to determine whether any given second is included
in available time or unavailable time until _after_ a ten second interval
has passed.  Below I quote from <draft-ietf-atommib-sonetng-02.txt>, but
essentially the same definition applies to all of the trunk mibs, and it
is just a rephrasing of the one in T1.231 (which in turn came from G.826,
I think).

          Unavailable Seconds
               At the Line, Path, and VT layers, an unavailable second
               is calculated by counting the number of seconds that the
               interface is unavailable.  At each layer, the SONET/SDH
               interface is said to be unavailable at the onset of 10
               contiguous SESs.  The 10 SESs are included in unavailable
               time.             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
               ^^^^    Once unavailable, the SONET/SDH interface becomes
               available at the onset of 10 contiguous seconds with no
               SESs.  The 10 seconds with no SESs are excluded from
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
               unavailable time.
               ^^^^^^^^^^^^^^^^

Note well:  retroactive adjustment of the counters is allowed, but _not_
required.  Here is what T1.231 says (see Sec. 9.1.2.1 of either the 1993
or 1997 version):

          If the beginning of a 15-minute accumulation period occurs
          during the processing interval leading to or from unavailability,
          adjustment of the counts in both the current and previous
          15-minute registers may be necessary [ ... ].

It goes on to say that

          Registers should be incremented in real time, but shall be
          incremented within a time interval equal to or less than
          one minute from the event of occurrence.

If you don't want to do retroactive adjustments, then you must delay
updating the counts for ten seconds.  All of the trunk mibs contain
language explaining how to do this.  In <draft-ietf-atommib-sonetng-02.txt>
you'll find it in Appendix A.

> I sure hope there is no such product out there.  Do you have one like
> that ? ;)

Well, I don't, but I would not be surprised to find implementations
that use the retroactive adjustment method.

>
> Rajesh
>

Mike
--
C. M. Heard/VVNET, Inc.
[e-mail]