Subject: Re: [Diffserv] diffserv mib rev 13 - do we need Counter32 objects

From: Fred Baker <[email-masked]>
Date: Tue, 18 Sep 2001 10:40:37 -0700

At 07:06 AM 9/18/2001, Wijnen, Bert (Bert) wrote:
>When discussing this with Fred, my understanding is that
>he would also prefer to just eliminate the 32-bit counters
>from the diffserv MIB. And I am fine with that.

A little history might be relevant here. In the first SNMP SMI, all 
counters were 32 bit quantities. This worked well enough for counters that 
moved at a slow rate, but had difficulties with packet and octet counters 
for higher speed lines. It was my opinion (and I was not alone, but I will 
speak only for myself here) at the time that such counters should always be 
64 bit values, an opinion which was politically incorrect.

A compromise of sorts was reached during the development of SMIv2. In this, 
a Counter64 type was defined, but its use was limited to counters that 
could be expected to count at a high rate. The definitive use of this is in 
RFC 1573, RFC 2233, and now RFC 2863.

As a result, any MIB developed under SMIv2 has two counters for any packet 
or octet counter supported, and a rather complicated set of rules under 
which each counter should be implemented, related to line rate. The 
implementation rules seem to assume that an agent is redeveloped for each 
product implementation, which seems ludicrous - who among us doesn't re-use 
software? An example of the complexity shows up in the currently posted 
diff-serv MIB, which describes three different cases of 
what-must-be-implemented-by-whom in the counter realm, depending on the 
line speeds implemented by the device.

Personally, I continue to believe that any packet or octet counter that 
increments in normal use should be 64 bit. This will allow us to scale 
through anything I can honestly predict, and covers the low end as well. I 
would like to see this become a BCP, and applied to all MIBs rather than to 
individual MIBs in special cases. Maybe I will have my way in SMIng, I 
don't know. That has been a loop I have left to others, due to some 
combination of lack of cycles and frustration with the historical 
difficulty of making even small advances.

The argument against this might be that this requires cost in hardware - 
rebuilding of ASICs, and dedication of memory to tables. It does in fact 
require 32 more bits in memory somewhere. I will argue that the ASIC issue 
can be worked around by reading the counter and storing it in a 64 bit 
location maintained by software - something implementations often do anyway 
for other reasons. The additional memory implied, however, is not (in my 
opinion) a killer issue - if you can support the MIB at all, the memory 
implied itself a relatively small part of it.

But then, as we all know, I'm a heretic :^)

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 20 Sep 2001 09:31:50 +0200

>>>>> Remco van de Meent writes:

Remco> While converting the old stools debian package to scli, I
Remco> noticed that the doc/stools.info file is still there,
Remco> mentioning stools instead of scli.

Yes. I am undecided about it. Either put much more work into it to
make it actually useful, or just remove it altogether. I plan to put
the LISA 2001 paper into the distribution once it is done.

/js