Subject: [MIB-DOCTORS] Counter32/ZeroBasedCounter32

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Wed, 21 Feb 2007 13:30:58 +0100

Mike, I was doing a prelimenary review of the ANCP MIB for
a colleague of mine (Stefaan). And we run into the
problem that he needs a counter that can be reset to zero 
when an ANCP session is being reset.

RFC4181, sect 4.6.1.2 (last bullet) says:

   - It is NOT OK for one manager to request the agent to reset the
     value(s) of counter(s) to zero, and Counter32/64 is the wrong
     syntax for "counters" that regularly reset themselves to zero.  For
     the latter, it is better to define or use textual conventions such
     as those in RFC 3593 [RFC3593] or RFC 3705 [RFC3705].

But those 2 RFCs talk about 15 minute counters. That is not what we're
after. So I am at a loss here how those RFCs 3592 and 3705 help us.

I could defend a reset to zero by considering a "reset of an ancp
session" 
to be similar to a reset of a line-card.

Do you have an opinion or advise?

Thanks,
Bert

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 21 Feb 2007 07:51:54 -0500

Hi Bert,

I don't know anything about ANCP. The question that jumps to my mind
is, when an ANCP session is reset, is it reset by a manager or by an
agent? 

If it reset by an agent, then all you should need is a discontinuity
indicator so all managers know the session was reset and when, and if
useful, you might want to have a reset counter to reflect how many
times a reset has occurred, like snmpEngineBoots.

If it is reset by manager action, then I recommend that each session
be tracked in a row "owned" by a specific manager, who has the only
authority to reset the session, like OwnerString from RMON. 

dbh

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Wednesday, February 21, 2007 7:31 AM
> To: [email-masked]
> Cc: [email-masked]; DE CNODDER,STEFAAN (STEFAAN)
> Subject: [MIB-DOCTORS] Counter32/ZeroBasedCounter32
>

---

From: [email-masked]
Date: Wed, 21 Feb 2007 16:08:08 +0100

Hi,

A restarting ANCP session (which is nothing more than a TCP session 
between an access node and a BRAS because ANCP is running over TCP) 
means that the TCP session goes down and then up again.

This can happen for 2 reasons:
1) ANCP session is set in down state by the operator, and later to up 
state again.
2) a link failure somewhere in the network causes loss of IP 
connectivity between access node and BRAS, hence TCP session will go down.

It is not the case that the operator can request to reset the counters 
while the session is up.

When the ANCP session comes up again, then the counters must be reset to 
zero again.  There is an object in the same table as the counters named 
ancpAnCurrentSessionStartUptime (SYNTAX timeticks) which gives the 
sysUpTime of when the session came up, so this is in fact a 
discontinuity indicator.

So it looks that Counter32 is OK with an extra sentence to make the 
meaning of ancpAnCurrentSessionStartUptime more clearer, although 
RFC4181 says about counter32: "Counter32/64 is the wrong syntax for 
"counters" that regularly reset themselves to zero."  Here the word 
"regularly" is confusing.  Under normal operations, the sessions almost 
never go down and up again, but of course, there is always the 
possibility to have toggling TCP connections, although very unlikely.

regards,

Stefaan

David B Harrington wrote:

>>But those 2 RFCs talk about 15 minute counters. That is not what
> 
> we're
>

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 21 Feb 2007 11:01:42 -0500

Hi,

I think two clauses from RFC4181 section 4.6.1.2 are relevant:
   - It is OK to use Counter32/64 for counters that may/will be reset
     when the management subsystem is re-initialized or when other
     unusual/irregular events occur (e.g., counters maintained on a
line
     card may be reset when the line card is reset).  However, if it
is
     possible for such other unusual/irregular events to occur, the
     DESCRIPTION clause MUST state that this is so and MUST describe
     those other unusual/irregular events in sufficient detail that it
     is possible for a management application to determine whether a
     reset has occurred since the last time the counter was polled.
The
     RECOMMENDED way to do this is to provide a discontinuity
indicator
     as described in RFC 2578 Sections 7.1.6 and 7.1.10.  For an
example
     of such a discontinuity indicator, see the
     ifCounterDiscontinuityTime object in the IF-MIB [RFC2863].

   - It is NOT OK to put in the DESCRIPTION clause of a Counter32/64
     that there is a requirement that on a discontinuity the counter
     MUST reset to zero or to any other specific value.

I think the first describes the situation you are trying to
instrument, and the presence of a discontinuity indicator metts the
requirements of that clause.

The second clause unfortunately has no explanation for why this rule
exists. If I remember correctly, this rule exists because setting the
value to an indeterminate starting value forces an NMS to use counters
the way counters are designed to be used in SNMP - as relative values
over time, not definite values; you take two readings and calculate
the delta between the relative values (and usually you also read
something like sysUpTime to calculate the corresponding time delta
between readings).

By resetting to zero and counting from there, this gives the
impression the value of the counter on one device can be compared to
the value of the counter on another device. This is not true because
the start of the epoch may not be comparable, so using a zero-based
counter is misleading.

Comparing two reads of a counter against a fixed time stamp, such as
ancpAnCurrentSessionStartUptime, is misleading unless you are also
reading sysUpTime (or something similar) which you can use to
calculate the time delta between the two counter readings.
ancpAnCurrentSessionStartUptime does not provide you with the ability
to do time deltas, since it does not change over time, except for a
discontinutity.

A comment from another MIB Doctor on a related matter: "For
performance monitoring, it is important to report counters and not
gauges as it is important to report the time spent in a state rather
than the actual state. In other words, objects that report snapshots
are of less value."

My $.02

dbh

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Wednesday, February 21, 2007 10:08 AM
> To: David B Harrington
> Cc: 'Wijnen, Bert (Bert)'; [email-masked]; [email-masked]
> Subject: Re: [MIB-DOCTORS] Counter32/ZeroBasedCounter32
> 
> 
> Hi,
>

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 21 Feb 2007 08:43:15 -0800 (PST)

...
> When the ANCP session comes up again, then the counters must be 
> reset to zero again.  There is an object in the same table as the 
> counters named ancpAnCurrentSessionStartUptime (SYNTAX timeticks) 
> which gives the sysUpTime of when the session came up, so this is 
> in fact a discontinuity indicator.

Indeed, ancpAnCurrentSessionStartUptime qualifies as a discontinuity
indicator.

> So it looks that Counter32 is OK with an extra sentence to make 
> the meaning of ancpAnCurrentSessionStartUptime more clearer, 
> although RFC4181 says about counter32: "Counter32/64 is the wrong 
> syntax for "counters" that regularly reset themselves to zero." 
> Here the word "regularly" is confusing.  Under normal operations, 
> the sessions almost never go down and up again, but of course, 
> there is always the possibility to have toggling TCP connections, 
> although very unlikely.

The only problem is this restriction (from RFC 4181):

There are two solutions for this:

(a) Drop the requirement that the counters be reset to any specific 
value when an ANCP session is restarted.  The requirement for 
management stations would then be to compute the delta between two 
polls and to be aware that a delta is not valid unless the value of 
ancpAnCurrentSessionStartUptime is the same for both polls.

(b) Define a TC using a base type of Unsigned32 which allows for 
reset to zero when an ANCP session is started or restarted.  It 
would differ from ZeroBasedCounter32 in that the latter is set to 
zero only on creation (the prohibition quoted above on resetting to 
zero on a discontinuity applies to ZeroBasedCounter32 also).

//cmh