Subject: Re: PerfHist-TC-MIB

From: Rajesh Abbi <[email-masked]>
Date: Fri, 05 Jun 1998 10:31:15 -0400

Chunhui Teng wrote:
> 
> In message "Re: PerfHist-TC-MIB", you write:
> 
> >Keith McCloghrie wrote:
> >>
> >> > The 'Perf***Count' objects are supposed to be 'monotonically increasing'
> >> > -
> >> > thus Counter32/Counter64 would have been a better representation.
> >>
> >> This is incorrect.  For each of these objects, its value in one interval
> >> can be smaller than its value in the preceeding interval.
> >>
> >> Keith.
> >
> >These objects have a lifetime of 15-minutes.  During their lifetime
> >their
> >value is certainly 'monotonically increasing' !  After the interval is
> >over,
> 
> 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 ?

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.

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

> >the current counter starts again - ie: a new instance is created.
> >
> >Regarding Interval Counters - each interval is a 'separate instance' of
> >the
> >object.  The value in all 'historic' intervals (except the current one)
> >is
> >fixed - neither increasing nor decreasing.
> >
> >Rajesh
> >

Rajesh

---

From: Rajesh Abbi <[email-masked]>
Date: Fri, 05 Jun 1998 10:31:15 -0400

Are you serious ?

Rajesh

---

From: Rajesh Abbi <[email-masked]>
Date: Fri, 05 Jun 1998 10:31:15 -0400

Are you serious ?

Rajesh

---

From: [email-masked]
Date: Fri, 5 Jun 1998 11:11:40 -0700 (PDT)

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

anybody who has sonet equipment compliant with ANSI T1.231 has
equipment like that.  an errored second is an errored second unless
it's an unavailable second.  unfortunately you don't know if it's an
unavailable second until up to 10 seconds in the future.  so if you're
doing real-time couting in sonet equipment, you may have to "correct"
counts up to ten seconds in the past as the interface moves in and out
of unavailable time.

the latest sonet mib draft (draft-ietf-atommib-sonetng-02.txt) covers
this in detail, as well as covers a mechanism that utilizes a
10-second shift register to avoid having to make the corrections.

/jeff

---

From: Rajesh Abbi <[email-masked]>
Date: Fri, 05 Jun 1998 14:43:37 -0400

Jeff,

You are correct about the UAS definition as per ANSI T1.231.  It is
somewhat 
absurd that a second that was 'available' in tha past may become
'unavailable' 
in the future, and vice-versa.

Any ANSI folks around to comment ?

Rajesh

---

From: [email-masked]
Date: Fri, 5 Jun 1998 11:11:40 -0700 (PDT)

/jeff

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Fri, 5 Jun 1998 12:30:06 -0700 (PDT)

> Chunhui Teng wrote:
[ ... ]
> > have to subtract number of them (seconds) from the total count.

Yes :-)

> 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

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.
[email-masked]

---

From: Rajesh Abbi <[email-masked]>
Date: Fri, 05 Jun 1998 14:43:37 -0400

Jeff,

Rajesh

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Fri, 5 Jun 1998 12:30:06 -0700 (PDT)

[ ... ]

Yes :-)

          Unavailable Seconds

It goes on to say that

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]