RE: FW: 64 bit counters in MPLS MIBs

[Andy Bierman <abierman@cisco.com>]

At 07:09 PM 1/6/2003 -0500, Harrington, David wrote:
>Hi,
>
>part 1:
>
>While I recognize the overhead caused by supporting 64-bit values on devices without native 64-bit support, I think it is something of a red herring. If the amount of traffic crossing an interface will exceed the one-hour guideline, and the hardware/software being used is incapable of supporting emulation of 64-bit Counters, then the designers of the product should take a closer look at their designs. 

The overhead is non-trivial if there are lots of slow interfaces and
very few fast interfaces.  The extra memory and SW polling and code
complexity can be a burden compared to always retrieving the counter
value from the HW, whether it's 32 or 64 bits.


>If I need to count greater than 2^32, I can use one 64-bit register or memory location and report the value in a Counter64 varbind. I can also count using two registers or two memory locations (or a combination), one for the lower half and the other for the upper half, and combine the two 32-bit values into a Counter64 varbind. 

Wrong.  You have to honor the 64-bit wrap semantics if you return
Counter64 objects or the upper half of a Counter32 pair.  You cannot
ignore wrap events of the lower 32 bit counter.  You have to maintain
64-bit shadow counters and poll them often enough to never miss a
wrap event in the native counter. You also have to invoke this
code on every get, to return fresh counter values instead of
stale shadow values.  (I've implemented this code on the agent side
many times.)


>It seems to me that the overhead of mallocing, filling in the OIDs and types and values, and then sending two Counter32 varbinds is typically greater than the overhead for mallocing one Counter64 varbind, combining two 32bit values values into the Counter64 varbind, and then sending one varbind.

You are assuming that the agent is using memory for the native counters.
This is not always (usually?) the case.  Allocating 8 bytes per counter
can be a huge hit on memory if there enough native counter instances.


>part 2:
>
>I do not believe it makes sense to select the counter size based on the deployment. If there is any likelihood that an interface may exceed the one-hour guideline, then Counter64s are called for. This would exempt a managed object designed to support an interface that cannot possibly exceed the one-hour guideline, such as the byte count for a 1M Ethernet interface.

This is the NMS-centric perspective. The device-centric perspective says
"the HW has a mixture of 32 and 64 bit counters. Deal with it."


>For mib objects supporting interfaces where the speed is not known at mib-design-time, then it should be assumed that at some point, it will be applied to an interface that qualifies for the one-hour guideline, and thus they should use Counter64s.
>
>part 3:
>The only justification I can see for the dual Counter32s is to support SNMPv1-only applications. While I don't like needing to support these, the fact is there are few SNMPv3-capable applications available to date. People need to manage their networks. By insisting that mibs be designed with features not yet available in many existing applications, we would make SNMP even harder to use than it is already.

agreed


>Using deprecated 32-bit counters to support SNMPv1 will help the end-users in the short term.

agreed

>dbh

Andy



>> -----Original Message-----
>> From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com]
>> Sent: Monday, January 06, 2003 6:07 PM
>> To: mreview@ops.ietf.org
>> Subject: RE: FW: 64 bit counters in MPLS MIBs
>> 
>> 
>> Hi -
>> 
>> > Date: Mon, 6 Jan 2003 12:22:44 -0800 (PST)
>> > From: "C. M. Heard" <heard@pobox.com>
>> > To: "Mreview (E-mail)" <mreview@ops.ietf.org>
>> > Subject: RE: FW: 64 bit counters in MPLS MIBs
>> > In-Reply-To: 
>> <7D5D48D2CAA3D84C813F5B154F43B1559899DF@nl0006exch001u.nl.lucent.com>
>> > Message-ID: 
>> <Pine.LNX.4.10.10301061215100.26591-100000@shell4.bayarea.net>
>> ...
>> > I agree with all of that.  But for the scenario set forth above,
>> > the MIB module's compliance statement would presumably say that
>> > HC counters are required for highspeed ifaces, while
>> > LC counters are required for lowspeed ifaces.
>> ...
>> 
>> One thing really bugs me about this particular formulation:
>> where RFC 2578 clause 7.1.10 is about the selection of a
>> SYNTAX for OBJECT-TYPEs, this formulation goes farther and
>> makes it a per-instance rule.
>> 
>> I think we should encourage, rather than disparage,
>> implementations which support the 64-bit counters
>> unconditionally.  (Assuming of course that it's architecturally
>> appropriate for the object to be 64 bits in the first place.)
>> I believe this would reduce the "yuck" factor Glenn mentioned.
>> 
>>  ------------------------------------------------------
>>  Randy Presuhn          BMC Software, Inc.  SJC-1.3141
>>  randy_presuhn@bmc.com  2141 North First Street
>>  Tel: +1 408 546-1006   San José, California 95131  USA
>>  ------------------------------------------------------
>>  My opinions and BMC's are independent variables.
>>  ------------------------------------------------------
>> 
>>