[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OID compression/suppression support
I strongly object to what I've seen being proposed that is "pure"
OID compressing (and any compression or other operation that is
Elimination of redundant information is very important and is
a HUGE win, but only when it is NOT at the cost of CPU cycles.
If anyone doesn't understand the reason why CPU usage is VERY
important, send me your phone number and best time to call and
we can have a chat.
At 11:19 AM 9/6/2002 -0400, Kristine Adamson wrote:
> I have only recently been following the discussions on this mailing list
>and have not reviewed the drafts in depth. But, I would like to see some
>'micro-evolutionary' changes, in the area of OID compression/suppression,
>defined for existing PDU operations.
>As David Harrington wrote on 8/21:
>>>I am interested in the OID compression/suppression proposals. They seem
>fairly easy to accomplish and yield an immediate benefit. SNMP is
>constantly being criticised >>by the flavor of the month competitive
>protocol for being too inefficient carrying all those long OIDs. We
>probably spend more time listening to the complaints than it >>would take
>to add OID suppression and compression to the message format. Let's correct
>the problem and improve the efficiency.
>We have had a lot of complaints from network management apps about their
>ability to get all the data they want from SNMP efficiently. And with IPv6
>IP addresses in instance values in the new version-neutral MIBs, this
>problem will only get worse. Object oriented protocol operations may be
>the best future direction but, we really need an improvement now, and it
>will probably be a long time before object oriented operations become a
>reality. So, I would like to see the WG invest time on the OID
>IBM Communications Server for MVS: TCP/IP Development
/david t. perkins