[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: discontinuity timers for Counters
On Tue, 27 Jul 2004, Randy Presuhn wrote:
> > From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> ...
> > Sect 4.6.1.2 iof mib review guidelines towards the end:
> >
> > There also exist closely-related textual conventions
> > ZeroBasedCounter32 and ZeroBasedCounter64 defined in RMON2-MIB
> > [RFC2021] and HCNUM-TC [RFC2856], respectively.
> >
> > The only difference between ZeroBasedCounter32/64 TCs and
> > Counter32/64 is their starting value; at time=X, where X is their
> > minimum-wrap-time after they were created, the behaviour of
> > ZeroBasedCounter32/64 becomes exactly the same as Counter32/64.
> > Thus, the preceding paragraphs/rules apply not only to Counter32/64,
> > but also to ZeroBasedCounter32/64 TCs.
> >
> > I conclude from that that we will not allow that a ZeroBasedCounter XX
> > can REQUIRE a reset to zero at any time other than at creation time?
> >
> > Do I not interpret that correctly?
> ...
>
> I hadn't thought of considering the MIB review guidelines to be
> the definitive statement of intent for those textual
> conventions. If that is what we should do, then we should
> perhaps go over the review guidelines more closely to ensure
> that they do not over- or under- specify things like, for
> example, discontinuity behaviour of ZeroBasedCounter32.
Indeed, and doing this sooner rather than later would be good, since
we will probably last-call the next revision.
Note that there are (deliberately) very few places where the review
guidelines intentionally "trump" existing documents, and I don't
think this is one. I didn't actually write the paragraph quoted
above -- if I remember correctly, it was contributed by Bert -- but
my understanding was that the intent was just to summarize the
content of the source documents (RFCs 2021 and 2856).
> In my opinion, the reading you propose can probably be justified
> by the review guidelines, if one assumes that it the intent was
> to include discontinuity behaviour in with the "post wrap"
> behaviour. However, I also think that that reading doesn't fit
> well with the original motivations for ZeroBasedCounter32, even
> if the original use of that TC did not anticipate discontinuity
> events, which in any case should not be lumped together with
> wraps. Two samples straddling a wrap yield a meaningful delta.
> Two samples straddling a discontinuity do not.
Well, here is are the TCs reproduced from the original documents.
It's true that RFC 2021 will soon be updated; however, the
ZeroBasedCounter32 definition has not changed.
ZeroBasedCounter32 ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes an object which counts events with the
following semantics: objects of this type will be set to
zero(0) on creation and will thereafter count appropriate
events, wrapping back to zero(0) when the value 2^32 is
reached.
Provided that an application discovers the new object within
the minimum time to wrap it can use the initial value as a
delta since it last polled the table of which this object is
part. It is important for a management station to be aware of
this minimum time and the actual time between polls, and to
discard data if the actual time is too long or there is no
defined minimum time.
Typically this TC is used in tables where the INDEX space is
constantly changing and/or the TimeFilter mechanism is in use."
SYNTAX Gauge32
3.2. ZeroBasedCounter64
This textual convention defines a 64-bit counter with an initial
value of zero, instead of an arbitrary initial value.
This TC is used for counter objects in tables which are instantiated
by management application action.
...
ZeroBasedCounter64 ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes an object which counts events with the
following semantics: objects of this type will be set to
zero(0) on creation and will thereafter count appropriate
events, wrapping back to zero(0) when the value 2^64 is
reached.
Provided that an application discovers the new object within
the minimum time to wrap it can use the initial value as a
delta since it last polled the table of which this object is
part. It is important for a management station to be aware
of this minimum time and the actual time between polls, and
to discard data if the actual time is too long or there is
no defined minimum time.
Typically this TC is used in tables where the INDEX space is
constantly changing and/or the TimeFilter mechanism is in
use.
Note that this textual convention does not retain all the
semantics of the Counter64 base type. Specifically, a
Counter64 has an arbitrary initial value, but objects
defined with this TC are required to start at the value
zero. This behavior is not likely to have any adverse
effects on management applications which are expecting
Counter64 semantics.
This textual convention represents a limited and short-term
solution, and may be deprecated as a long term solution is
defined and deployed to replace it."
SYNTAX Counter64
It seems to me that the language of the definitions, particularly
the second paragraph of the DESCRIPTION clauses, clearly implies
that these objects will be used in the same way as ordinary counters
(i.e., by taking deltas) except possibly on the first time the
object is read. On that basis, I don't think that there is anything
wrong with what the MIB review guidelines have to say about this
particular point.
Mike
P.S. If we ever update RFC 2856, we should correct the
mis-statement that ZeroBasedCounter64 "does not retain all the
semantics of the Counter64 base type." It actually retains all the
semantics, and adds some. An agent that initializes all its
Counter64 variables to zero at creation time does not violate the
definition of that type; what would be wrong would be for a manager
to rely on such behaviour. On the other hand, a manager that treats
ZeroBasedCounter64 in the same way as Counter64 cannot take
advantage of the added initial value guarantee, but all of its logic
should work. (In the language of object-oriented design, a
ZeroBasedCounter64 "IsA" Counter64.)