Return-Path: X-Original-To: nmrg@ibr.cs.tu-bs.de Delivered-To: nmrg@ibr.cs.tu-bs.de Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by salvator.ibr.cs.tu-bs.de (Postfix) with ESMTPS id A9270141D6 for ; Fri, 20 Aug 2010 22:16:42 +0200 (CEST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7KKGfIZ031598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Aug 2010 22:16:41 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7KKGeEk021023; Fri, 20 Aug 2010 22:16:40 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Aug 2010 22:16:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Aug 2010 22:16:39 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64D9AFFF@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nmrg] 26th nmrg meeting minutes uploaded thread-index: ActAo0LeQpLDoz4UT5CM55tx2U2JTQAAQwlw References: <20100820091032.GC6084@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Simon Leinen" , X-OriginalArrivalTime: 20 Aug 2010 20:16:40.0905 (UTC) FILETIME=[99C85B90:01CB40A4] X-Virus-Scanned: clamav-milter 0.96.1 at salvator X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on salvator.ibr.cs.tu-bs.de X-Mailman-Approved-At: Sat, 21 Aug 2010 09:45:57 +0200 Subject: Re: [nmrg] 26th nmrg meeting minutes uploaded X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 20:16:45 -0000 Q is question and C is most likely one of the chairs=20 (but which one ;-) Cheers, Mehmet > -----Original Message----- > From: nmrg-bounces@ibr.cs.tu-bs.de [mailto:nmrg-bounces@ibr.cs.tu- > bs.de] On Behalf Of ext Simon Leinen > Sent: Friday, August 20, 2010 2:20 PM > To: nmrg@ibr.cs.tu-bs.de > Subject: Re: [nmrg] 26th nmrg meeting minutes uploaded >=20 > Juergen Schoenwaelder writes: > > I just uploaded the minutes of the 26th NMRG meeting that took place > > during the 78th IETF meeting: >=20 > > http://www.ietf.org/proceedings/78/minutes/NMRG.txt >=20 > > Many thanks to the note takes and the minutes editors. >=20 > Thanks! >=20 > But who are "Q" and "C"? > -- > Simon. > -- > !! This message is brought to you via the `nmrg' mailing list. > !! Please do not reply to this message to unsubscribe. To unsubscribe > or adjust > !! your settings, send a mail message to > !! or look at https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. Return-Path: X-Original-To: nmrg@ibr.cs.tu-bs.de Delivered-To: nmrg@ibr.cs.tu-bs.de Received: from caval.switch.ch (caval.switch.ch [IPv6:2001:620:0:14::29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by salvator.ibr.cs.tu-bs.de (Postfix) with ESMTPS id C2A1C140D9 for ; Fri, 20 Aug 2010 14:19:33 +0200 (CEST) Received: from [130.59.6.131] (helo=macsl.switch.ch) by caval.switch.ch with esmtp (Exim 4.69) (envelope-from ) id 1OmQZJ-0006d8-7m; Fri, 20 Aug 2010 14:19:33 +0200 From: Simon Leinen To: nmrg@ibr.cs.tu-bs.de In-Reply-To: <20100820091032.GC6084@elstar.local> (Juergen Schoenwaelder's message of "Fri, 20 Aug 2010 11:10:32 +0200") References: <20100820091032.GC6084@elstar.local> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (darwin) X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Fri, 20 Aug 2010 14:19:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SWITCH-SCANNER: bypassed X-Virus-Scanned: clamav-milter 0.96.1 at salvator X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on salvator.ibr.cs.tu-bs.de X-Mailman-Approved-At: Fri, 20 Aug 2010 22:06:57 +0200 Subject: Re: [nmrg] 26th nmrg meeting minutes uploaded X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 12:19:37 -0000 Juergen Schoenwaelder writes: > I just uploaded the minutes of the 26th NMRG meeting that took place > during the 78th IETF meeting: > http://www.ietf.org/proceedings/78/minutes/NMRG.txt > Many thanks to the note takes and the minutes editors. Thanks! But who are "Q" and "C"? -- Simon. Return-Path: X-Original-To: nmrg@ibr.cs.tu-bs.de Delivered-To: nmrg@ibr.cs.tu-bs.de Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by salvator.ibr.cs.tu-bs.de (Postfix) with ESMTP id 4A7E414535 for ; Fri, 20 Aug 2010 11:10:48 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 34053C0008 for ; Fri, 20 Aug 2010 11:10:48 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Cy9BfT+Ku6S8; Fri, 20 Aug 2010 11:10:47 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5FE4C000A; Fri, 20 Aug 2010 11:10:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DA5BD1452984; Fri, 20 Aug 2010 11:10:32 +0200 (CEST) Date: Fri, 20 Aug 2010 11:10:32 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20100820091032.GC6084@elstar.local> Mail-Followup-To: nmrg@ibr.cs.tu-bs.de MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96.1 at salvator X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on salvator.ibr.cs.tu-bs.de Subject: [nmrg] 26th nmrg meeting minutes uploaded X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 09:10:51 -0000 Hi, I just uploaded the minutes of the 26th NMRG meeting that took place during the 78th IETF meeting: http://www.ietf.org/proceedings/78/minutes/NMRG.txt Many thanks to the note takes and the minutes editors. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Return-Path: X-Original-To: nmrg@ibr.cs.tu-bs.de Delivered-To: nmrg@ibr.cs.tu-bs.de Received: from mail-iw0-f181.google.com (mail-iw0-f181.google.com [209.85.214.181]) by salvator.ibr.cs.tu-bs.de (Postfix) with ESMTP id 15BFF140ED for ; Sun, 8 Aug 2010 14:16:56 +0200 (CEST) Received: by iwn6 with SMTP id 6so3150309iwn.40 for ; Sun, 08 Aug 2010 05:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=mV0ACMVdcvmbsYVETko0FpoYW5W5wUmxVg1QCWEKxLE=; b=MmFhZwJFVC8qi7qpKDsmj6tS+WyxdCQd3ZUcgDx36qfO1B3Na2YRcFf4WZ2o3oN2Z2 /tl4zt017c3lMsXP74GXZ2G4QX5RAl6G8s8G4lD0qK8BeywyJCJKeFsoOTbi8MHQxNnE Pkxg8WcEwDPWRKW7nklMBa07DmGeEZjj/5M8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=fcI1+MSaO0uEvQw01LM2IJXcbEsvxNGBNdFsUvCYztv+DRMoWrO3EscQqAqG8wq5Vb 0OKAR6YF3uthg1JiM8difn8pVquNPKjXlP+FWITc0cAWsm6Kiv5qaPmsuCZ2QZ7XEIET TYgf69M1DEBsEzoDDbagH1fHmsNFOlwhl7bO0= MIME-Version: 1.0 Received: by 10.231.159.204 with SMTP id k12mr17232099ibx.42.1281269815880; Sun, 08 Aug 2010 05:16:55 -0700 (PDT) Received: by 10.231.59.6 with HTTP; Sun, 8 Aug 2010 05:16:55 -0700 (PDT) In-Reply-To: <20100804071122.GA86194@elstar.local> References: <20100804071122.GA86194@elstar.local> Date: Sun, 8 Aug 2010 17:46:55 +0530 Message-ID: From: Hari Narayanan To: "nmrg@ibr.cs.tu-bs.de" Content-Type: multipart/alternative; boundary=005045015d4b3cae1e048d4ee0d8 X-Virus-Scanned: clamav-milter 0.96.1 at salvator X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, SPF_PASS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on salvator.ibr.cs.tu-bs.de X-Mailman-Approved-At: Mon, 09 Aug 2010 06:16:11 +0200 Subject: Re: [nmrg] SNMP OID Compression X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 12:17:00 -0000 --005045015d4b3cae1e048d4ee0d8 Content-Type: text/plain; charset=ISO-8859-1 I am trying understand GetColumn proposal by Dave Perkin ( http://www.ietf.org/proceedings/48/SLIDES/snmpv3-getcols) in the context of my current Net SNMP developments on OID compression. Pl. send me the pointers if this has already been discussed, otherwise I would like to know more about GetColumn, specifically the following questions: - GetColumn proposes to address Overshoot with agent side detection and holes with "noSuchInstance" exception. Is there any issue in using the same type of solutions for GetBulk besides compatibility? - I am assuming that the request generator is keeping a complete copy of its request to construct the OID for 2nd and subsequent column objects. What about a mid stream application like Wireshark? There is no differentiating sub-ids in the encoding. Even if we assume these are consecutive columns of a table, they do not have enough information to construct the OIDs. Regards ... Hari T.S. Narayanan On Wed, Aug 4, 2010 at 12:41 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Aug 03, 2010 at 06:20:49PM +0200, Hari Narayanan wrote: > > > OID Compression has been already discussed in two drafts ? Delta > > compression and Prefix compression. At present, I have worked on a > > simple form of prefix compression where all the requested objects > > are at the same level of MIB tree. First object in the request is > > fully specified in PDU varbind, rest of the objects are specified > > only with their respective suffix where they differ from the first > > object. > > It would be nice to know how much simpler your compression scheme is > compared to delta compression, which works with arbitrary sequences of > OIDs since it does not make any assumptions of the OIDs in the > payload. It may look more complicated at first sight but I believe the > code to implement delta compression really is not that difficult. > > > To continue this investigation, I have also added additional code to > > Net SNMP 5.5 to support this simplified prefix compression. This > > enables me to measure code size, image size, response time, bytes > > saved, and CPU cycles required etc. The additional code required is > > about 400 lines (including comment and white space). These 400 lines > > of code are sufficient to enable both agent and application to > > support OID compression. The agent image is larger by about 4Kbytes. > > I am yet to measure the response time rigorously, but I notice that > > for getbulk request with large number of objects the response time > > is better with OID compression. The code that encodes objid takes > > less time because it has to code only the suffix part for all but > > the first object. It is now easy to compare the legacy code with the > > new code in ever aspect. There is only one API function to access > > and use OID compression. There is also command line option to > > request OID compression. > > Several studies have reported that the time/cycles spent on BER > encoding/decoding is not significant compared to the overall > time/cycles it takes to process a request (see e.g. [4]). While this > is already true for insecure versions of SNMP, if you add > authentication and encryption, encoding/decoding overhead is not at > all relevant. Back in the days (> 10 years ago) when OID compression > was more heavily discussed, the main objective was to pack more data > into response PDUs, in particular allowing GetBulk requests to ship > more varbinds in responses. Since there is an overshoot issue (unless > the manager can estimate the number of instances and provide > reasonable max-repetitions), a GetRange PDU was proposed as well, > original idea in [5], more detailed description here: > > http://tools.ietf.org/html/draft-irtf-nmrg-snmp-getrange-00 > > Nowadays, interest is probably more coming from links that do have > very small frame sizes and where fragmentation should be avoided (such > as 802.15.4 networks) and where CPU cycles can potentially be saved > when security is enabled. > > > I am also doing a profiling on a large collection of MIBs (from 250 > > vendors) to understand how and where OID compression could be taken > > advantage off. This profiling includes average object depth, average > > object value size, percentage of table objects, number fixed size > > object, number of variable size objects, maximum depth, etc. > > Such studies based on an analysis of MIB modules have been done before > [1]. There have also been efforts to collect real-world SNMP traces in > order to analyze how deployed applications actually use SNMP [2]. A > more general survey of SNMP performance studies can be found in [3]. > > I am sending these references just in case they help to put your work > into context. > > /js > > [1] J. Schonwalder: Characterization of SNMP MIB Modules. 9th > IFIP/IEEE International Symposium on Integrated Network > Management, pages 615-628, Nice, May 2005. > > [2] J. Schonwalder, A. Pras, M. Harvan, J. Schippers, R. van de Meent: > SNMP Traffic Analysis: Approaches, Tools, and First Results. 10th > IFIP/IEEE International Symposium on Integrated Network > Management, Munich, May 2007. > > [3] L. Andrey, O. Festor, A. Lahmadi, A. Pras, J. Schonwalder: Survey > of SNMP Performance Analysis Studies. International Journal of > Network Management 19(6), Wiley, November 2009. > > [4] Aiko Pras, Thomas Drevers, Remco van de Meent, Dirk Quartel: > Comparing the Performance of SNMP and Web services-based > Management. Transactions on Network and Service Management, > 1(2), IEEE, 2004. > > [5] Malowidzki, M., "GetBulk Worth Fixing", Simple Times 10(1), > December 2002. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --005045015d4b3cae1e048d4ee0d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am trying understand GetColumn proposal by Dave Perkin (http://www.ietf.or= g/proceedings/48/SLIDES/snmpv3-getcols) in the context of my current Ne= t SNMP developments on OID compression. Pl. send me the pointers if this ha= s already been discussed, otherwise I would like to know more about GetColu= mn, specifically the following questions:
  • GetColumn proposes to address Overshoot with agent side detect= ion and holes with "noSuchInstance" exception. Is there any issue= in using the same type of solutions for GetBulk besides compatibility?
  • I am assuming that the request generator is keeping a complete copy of = its request to construct the OID for 2nd and subsequent column objects. Wha= t about a mid stream application like Wireshark? There is no differentiatin= g sub-ids in the encoding. Even if we assume these are consecutive columns = of a table, they do not have enough information to construct the OIDs.
Regards ... Hari T.S. Narayanan

On Wed, Aug 4, 2010 at 12:41 PM, Juergen Schoenwaelder <j.scho= enwaelder@jacobs-university.de> wrote:
On Tue, Aug 03, 2010 at 0= 6:20:49PM +0200, Hari Narayanan wrote:

> OID Compression has been already discussed in two drafts ? Delta
> compression and Prefix compression. At present, I have worked on a
> simple form of prefix compression where all the requested objects
> are at the same level of MIB tree. First object in the request is
> fully specified in PDU varbind, rest of the objects are specified
> only with their respective suffix where they differ from the first
> object.

It would be nice to know how much simpler your compression scheme is<= br> compared to delta compression, which works with arbitrary sequences of
OIDs since it does not make any assumptions of the OIDs in the
payload. It may look more complicated at first sight but I believe the
code to implement delta compression really is not that difficult.

> To continue this investigation, I have also added additional code to > Net SNMP 5.5 to support this simplified prefix compression. This
> enables me to measure code size, image size, response time, bytes
> saved, and CPU cycles required etc. The additional code required is > about 400 lines (including comment and white space). These 400 lines > of code are sufficient to enable both agent and application to
> support OID compression. The agent image is larger by about 4Kbytes. > I am yet to measure the response time rigorously, but I notice that > for getbulk request with large number of objects the response time
> is better with OID compression. The code that encodes objid takes
> less time because it has to code only the suffix part for all but
> the first object. It is now easy to compare the legacy code with the > new code in ever aspect. There is only one API function to access
> and use OID compression. =A0There is also command line option to
> request OID compression.

Several studies have reported that the time/cycles spent on BER
encoding/decoding is not significant compared to the overall
time/cycles it takes to process a request (see e.g. [4]). While this
is already true for insecure versions of SNMP, if you add
authentication and encryption, encoding/decoding overhead is not at
all relevant. Back in the days (> 10 years ago) when OID compression
was more heavily discussed, the main objective was to pack more data
into response PDUs, in particular allowing GetBulk requests to ship
more varbinds in responses. Since there is an overshoot issue (unless
the manager can estimate the number of instances and provide
reasonable max-repetitions), a GetRange PDU was proposed as well,
original idea in [5], more detailed description here:

http://tools.ietf.org/html/draft-irtf-nmrg-snmp-getrange-00<= /a>

Nowadays, interest is probably more coming from links that do have
very small frame sizes and where fragmentation should be avoided (such
as 802.15.4 networks) and where CPU cycles can potentially be saved
when security is enabled.

> I am also doing a profiling on a large collection of MIBs (from 250 > vendors) to understand how and where OID compression could be taken > advantage off. This profiling includes average object depth, average > object value size, percentage of table objects, number fixed size
> object, number of variable size objects, maximum depth, etc.

Such studies based on an analysis of MIB modules have been done befor= e
[1]. There have also been efforts to collect real-world SNMP traces in
order to analyze how deployed applications actually use SNMP [2]. A
more general survey of SNMP performance studies can be found in [3].

I am sending these references just in case they help to put your work
into context.

/js

[1] J. Schonwalder: Characterization of SNMP MIB Modules. 9th
=A0 =A0IFIP/IEEE International Symposium on Integrated Network
=A0 =A0Management, pages 615-628, Nice, May 2005.

[2] J. Schonwalder, A. Pras, M. Harvan, J. Schippers, R. van de Meent:
=A0 =A0SNMP Traffic Analysis: Approaches, Tools, and First Results. 10th =A0 =A0IFIP/IEEE International Symposium on Integrated Network
=A0 =A0Management, Munich, May 2007.

[3] L. Andrey, O. Festor, A. Lahmadi, A. Pras, J. Schonwalder: Survey
=A0 =A0of SNMP Performance Analysis Studies. International Journal of
=A0 =A0Network Management 19(6), Wiley, November 2009.

[4] Aiko Pras, Thomas Drevers, Remco van de Meent, Dirk Quartel:
=A0 =A0Comparing the Performance of SNMP and Web services-based
=A0 =A0Management. Transactions on Network and Service Management,
=A0 =A01(2), IEEE, 2004.

[5] Malowidzki, M., "GetBulk Worth Fixing", Simple Times 10(1), =A0 =A0December 2002.

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>

--005045015d4b3cae1e048d4ee0d8-- Return-Path: X-Original-To: nmrg@ibr.cs.tu-bs.de Delivered-To: nmrg@ibr.cs.tu-bs.de Received: from mail-iw0-f181.google.com (mail-iw0-f181.google.com [209.85.214.181]) by salvator.ibr.cs.tu-bs.de (Postfix) with ESMTP id A8508141DC for ; Thu, 5 Aug 2010 16:56:30 +0200 (CEST) Received: by iwn6 with SMTP id 6so283089iwn.40 for ; Thu, 05 Aug 2010 07:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=k3mbwPnsywwOxnwAClFgS7SdGEntZqrTKPBMgpdI0og=; b=t1sWxw6I0Pz5ZIAO3vmnD4lYtwaFdmzdaGUjreJkKaKYCxyGxvCNSD6OJWaLhWNsCv lI6kOWnTsvVxbMSi97dZ56974eWaQV/P6jEeYPijJ2ij5vMM0tJM/gbaHRz9dxsxSndp 7fyRgUNLIL6qY1Y7CDLTy8pXj5aUX7qdBX7m4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eI4xnE4rWuO19hbOz3qpS9YlbEgsM9pAqA6kAGPRaBT8zcUy4xFlKjs2s02kXQTOUq 6yMThIMXxK8Wk1BPD4s67Lh0KxaK7PULx0xUaroFdc6BAjfcMt6XGq9SXy62Izr1EohQ gYn2ZEwLADloy9OnaCOlX2nhCoTz/Rk+IXD/Y= MIME-Version: 1.0 Received: by 10.231.162.13 with SMTP id t13mr4213983ibx.160.1281020189347; Thu, 05 Aug 2010 07:56:29 -0700 (PDT) Received: by 10.231.59.6 with HTTP; Thu, 5 Aug 2010 07:56:28 -0700 (PDT) In-Reply-To: <36F3C7ABA7B54822A083EFC6D14A33E0@23FX1C1> References: <20100804071122.GA86194@elstar.local> <36F3C7ABA7B54822A083EFC6D14A33E0@23FX1C1> Date: Thu, 5 Aug 2010 20:26:28 +0530 Message-ID: From: Hari Narayanan To: David Harrington Content-Type: multipart/alternative; boundary=00504501400c561194048d14c142 X-Virus-Scanned: clamav-milter 0.96.1 at salvator X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, SPF_PASS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on salvator.ibr.cs.tu-bs.de X-Mailman-Approved-At: Fri, 06 Aug 2010 21:14:30 +0200 Cc: nmrg@ibr.cs.tu-bs.de, Juergen Schoenwaelder Subject: Re: [nmrg] SNMP OID Compression X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 14:56:37 -0000 --00504501400c561194048d14c142 Content-Type: text/plain; charset=ISO-8859-1 David, Circa 1997, Nortel developed the first integrated NMS using SPECTRUM for their enterprise customers. I was the project lead for that and accumulated lot of air miles between NH and San Jose. Cabletron and Nortel had a joint stall at Interop, Atlanta to showcase this. It is so long back that I am not able recall any of the names of my Cabletron contacts. === There are a wide spectrum of SNMP developers - at one one end of this spectrum we see developers who are simply coding applications for functional spec, at the other end we see developers who are trying to optimize every CPU cycle (at the agent side) because every resource is scarce and agent is one of the least priority tasks. OID compression is an additional option for the latter folks. Eventually, I see every SNMP developer to make use of this once it is available and awareness is created. This is for future developers and it is not for retrofitting unless it makes sense. OID compression is a zero overhead feature and it should not interefere with object order in varbind list. Compression is that last function to execute before a PDU is sent and decompression is the first function to execute when a PDU is received. Thus, it is least likely to affect any other optimization at the agent and application side. Mid stream debugging and sniffing tools are required to be rewritten for the compressed PDU. I am currently trying to update Wireshark to recognize my OID compressed PDU. This optimization addresses the table counter objects specifically. These objects are frequently requested and there are several rows of these counter objects. In general, it is usefull for requesting groups of related objects that are changing frequently at the agent side. Regards ... Hari T.S. Narayanan On Mon, Jul 5, 2010 at 1:14 AM, David Harrington wrote: > Hi, > > I used to work on the Spectrum network management application (years > ago). > > Juergen mentioned real world SNMP traces. My concern with these traces > is with the sample networks, which tended to be academic. I think > academic networks can be very different than commercial networks in > the nature of their management practices. I know Spectrum sold for > $100K+. I am not sure how many academic departments spend $100K+ on > their management platforms. > > I am of the impression that how individual applications collect > objects is likely to be the single biggest factor in SNMP performance. > Much like software profiling, optimizing the collection of a MIB > object that is never or seldom collected yields little benefit. > Optimizing the collection of a single object that is collected very > frequently will yield better results. In software profiling, it is > generally better to optimize printf() than initialize_application(). > > I suggest that a potentially fruitful area of research would be to > study how the major SNMP NMS platforms behave before being extended > for additional MIB modules. These platforms constantly check certain > objects (like sysUpTime) to determine connectivity, detect > discontinuities, update synchronization, monitor interface changes, > etc. They check these routinely every few minutes throughout the day, > for all devices. This generates much more traffic to optimize than > operator-initiated reads using command line tools. > > In my experience, which is now pretty dated, most MIB module > extensions are treated with custom polling instructions defined by the > operator, so they vary by deployment. Otherwise, the extension MIBs > are handled by MIB browser functionality - they are often read only on > demand. > > If an NMS platform has add-on applications, the application will have > certain objects it will monitor (possibly using traps) to determine > when a significant event occurs, and then it will launch a series of > special reads to gather more info on the event, possibly on a > vendor/model-specific basis. > > I would recommend avoiding any proposals that make varbind order > important. Spectrum optimizes (used to optimize) SNMPv1 reads by > reordering the varbinds, and they use a polling engine that might > combine requested polls from multiple applications into a single > varbind to the device. (I don't know if they still do any of that > given SNMPv3 user-based security.) You also might have threading and > subagent issues. > > Spectrum also used to optimize data collection by determining, with > administrator and historical input, how frequently an object needed to > be actually read from the device, or whether an existing database > value, possibly collected for a different application, that is less > than seconds old would suffice. Counters are the datatypes that > most frequently must be refreshed by an actual read, so optimizing for > counters would likely yield bigger benefits than optimizing static > strings. > > As Juergen points out, in the face of other optimization techniques, > OID compression might not be that important. It may be important for > resource-contrained devices, but you'll want to be careful not to > interfere with existing optimization techniques used by the > application side. > > dbh > > > -----Original Message----- > > From: nmrg-bounces@ibr.cs.tu-bs.de > > [mailto:nmrg-bounces@ibr.cs.tu-bs.de] On Behalf Of Juergen > > Schoenwaelder > > Sent: Wednesday, August 04, 2010 9:11 AM > > To: Hari Narayanan > > Cc: nmrg@ibr.cs.tu-bs.de > > Subject: Re: [nmrg] SNMP OID Compression > > > > On Tue, Aug 03, 2010 at 06:20:49PM +0200, Hari Narayanan wrote: > > > > > OID Compression has been already discussed in two drafts ? Delta > > > compression and Prefix compression. At present, I have worked on a > > > > simple form of prefix compression where all the requested > > objects are > > > at the same level of MIB tree. First object in the request is > fully > > > specified in PDU varbind, rest of the objects are specified > > only with > > > their respective suffix where they differ from the first object. > > > > It would be nice to know how much simpler your compression > > scheme is compared to delta compression, which works with > > arbitrary sequences of OIDs since it does not make any > > assumptions of the OIDs in the payload. It may look more > > complicated at first sight but I believe the code to > > implement delta compression really is not that difficult. > > > > > To continue this investigation, I have also added > > additional code to > > > Net SNMP 5.5 to support this simplified prefix compression. This > > > enables me to measure code size, image size, response time, bytes > > > saved, and CPU cycles required etc. The additional code required > is > > > about 400 lines (including comment and white space). These > > 400 lines > > > of code are sufficient to enable both agent and application > > to support > > > OID compression. The agent image is larger by about 4Kbytes. > > > I am yet to measure the response time rigorously, but I notice > that > > > for getbulk request with large number of objects the > > response time is > > > better with OID compression. The code that encodes objid takes > less > > > time because it has to code only the suffix part for all > > but the first > > > object. It is now easy to compare the legacy code with the > > new code in > > > ever aspect. There is only one API function to access and use OID > > > compression. There is also command line option to request OID > > > compression. > > > > Several studies have reported that the time/cycles spent on > > BER encoding/decoding is not significant compared to the > > overall time/cycles it takes to process a request (see e.g. > > [4]). While this is already true for insecure versions of > > SNMP, if you add authentication and encryption, > > encoding/decoding overhead is not at all relevant. Back in > > the days (> 10 years ago) when OID compression was more > > heavily discussed, the main objective was to pack more data > > into response PDUs, in particular allowing GetBulk requests > > to ship more varbinds in responses. Since there is an > > overshoot issue (unless the manager can estimate the number > > of instances and provide reasonable max-repetitions), a > > GetRange PDU was proposed as well, original idea in [5], more > > detailed description here: > > > > http://tools.ietf.org/html/draft-irtf-nmrg-snmp-getrange-00 > > > > Nowadays, interest is probably more coming from links that do > > have very small frame sizes and where fragmentation should be > > avoided (such as 802.15.4 networks) and where CPU cycles can > > potentially be saved when security is enabled. > > > > > I am also doing a profiling on a large collection of MIBs (from > 250 > > > vendors) to understand how and where OID compression could be > taken > > > advantage off. This profiling includes average object > > depth, average > > > object value size, percentage of table objects, number fixed size > > > object, number of variable size objects, maximum depth, etc. > > > > Such studies based on an analysis of MIB modules have been > > done before [1]. There have also been efforts to collect > > real-world SNMP traces in order to analyze how deployed > > applications actually use SNMP [2]. A more general survey of > > SNMP performance studies can be found in [3]. > > > > I am sending these references just in case they help to put > > your work into context. > > > > /js > > > > [1] J. Schonwalder: Characterization of SNMP MIB Modules. 9th > > IFIP/IEEE International Symposium on Integrated Network > > Management, pages 615-628, Nice, May 2005. > > > > [2] J. Schonwalder, A. Pras, M. Harvan, J. Schippers, R. van de > Meent: > > SNMP Traffic Analysis: Approaches, Tools, and First Results. > 10th > > IFIP/IEEE International Symposium on Integrated Network > > Management, Munich, May 2007. > > > > [3] L. Andrey, O. Festor, A. Lahmadi, A. Pras, J. Schonwalder: > Survey > > of SNMP Performance Analysis Studies. International Journal of > > Network Management 19(6), Wiley, November 2009. > > > > [4] Aiko Pras, Thomas Drevers, Remco van de Meent, Dirk Quartel: > > Comparing the Performance of SNMP and Web services-based > > Management. Transactions on Network and Service Management, > > 1(2), IEEE, 2004. > > > > [5] Malowidzki, M., "GetBulk Worth Fixing", Simple Times 10(1), > > December 2002. > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > -- > > !! This message is brought to you via the `nmrg' mailing list. > > !! Please do not reply to this message to unsubscribe. To > > unsubscribe or adjust !! your settings, send a mail message > > to !! or look at > > https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. > > --00504501400c561194048d14c142 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
David,
Circa 1997, Nortel developed the first integrated NMS= using SPECTRUM for their enterprise customers. I was the project lead for = that and accumulated lot of air miles between NH and San Jose. Cabletron an= d Nortel had a joint stall at Interop, Atlanta to showcase this. It is so l= ong back that I am not able recall any of the names of my Cabletron contact= s.
=3D=3D=3D

There are a wide spectrum of SNMP d= evelopers - at one one end of this spectrum we see developers who are simpl= y coding applications for functional spec, at the other end we see develope= rs who are trying to optimize every CPU cycle (at the agent side) because e= very resource is scarce and agent is one of the least priority tasks. OID c= ompression is an additional option for the latter folks. Eventually, I see = every SNMP developer to make use of this once it is available and awareness= is created. =A0This is for future developers and it is not for retrofittin= g unless it makes sense.

OID compression is a zero overhead feature and it shoul= d not interefere with object order in varbind list. Compression is that las= t function to execute before a PDU is sent and decompression is the first f= unction to execute when a PDU is received. Thus, it is least likely to affe= ct any other optimization at the agent and application side. Mid stream deb= ugging and sniffing tools are required to be rewritten for the compressed P= DU. =A0I am currently trying to update Wireshark to recognize my OID compre= ssed PDU.

This optimization addresses the table counter objects s= pecifically. These objects are frequently requested and there are several r= ows of these counter objects. In general, it is usefull for requesting grou= ps of related objects that are changing frequently at the agent side.

Regards ... Hari T.S. Narayanan


On Mon, Jul 5, 2010 at 1:14 AM, David= Harrington <ietfdbh@comcast.net> wrote:
Hi,

I used to work on the Spectrum network management application (years
ago).

Juergen mentioned real world SNMP traces. My concern with these traces
is with the sample networks, which tended to be academic. I think
academic networks can be very different than commercial networks in
the nature of their management practices. I know Spectrum sold for
$100K+. I am not sure how many academic departments spend $100K+ on
their management platforms.

I am of the impression that how individual applications collect
objects is likely to be the single biggest factor in SNMP performance.
Much like software profiling, optimizing the collection of a MIB
object that is never or seldom collected yields little benefit.
Optimizing the collection of a single object that is collected very
frequently will yield better results. In software profiling, it is
generally better to optimize printf() than initialize_application().

I suggest that a potentially fruitful area of research would be to
study how the major SNMP NMS platforms behave before being extended
for additional MIB modules. These platforms constantly check certain
objects (like sysUpTime) to determine connectivity, detect
discontinuities, update synchronization, monitor interface changes,
etc. They check these routinely every few minutes throughout the day,
for all devices. This generates much more traffic to optimize than
operator-initiated reads using command line tools.

In my experience, which is now pretty dated, most MIB module
extensions are treated with custom polling instructions defined by the
operator, so they vary by deployment. Otherwise, the extension MIBs
are handled by MIB browser functionality - they are often read only on
demand.

If an NMS platform has add-on applications, the application will have
certain objects it will monitor (possibly using traps) to determine
when a significant event occurs, and then it will launch a series of
special reads to gather more info on the event, possibly on a
vendor/model-specific basis.

I would recommend avoiding any proposals that make varbind order
important. Spectrum optimizes (used to optimize) SNMPv1 reads by
reordering the varbinds, and they use a polling engine that might
combine requested polls from multiple applications into a single
varbind to the device. (I don't know if they still do any of that
given SNMPv3 user-based security.) You also might have threading and
subagent issues.

Spectrum also used to optimize data collection by determining, with
administrator and historical input, how frequently an object needed to
be actually read from the device, or whether an existing database
value, possibly collected for a different application, that is less
than <x> seconds old would suffice. Counters are the datatypes that most frequently must be refreshed by an actual read, so optimizing for
counters would likely yield bigger benefits than optimizing static
strings.

As Juergen points out, in the face of other optimization techniques,
OID compression might not be that important. It may be important for
resource-contrained devices, but you'll want to be careful not to
interfere with existing optimization techniques used by the
application side.

dbh

> -----Original Message-----
> From: nmrg-bounces@ibr.cs.tu-bs.de
> [mailto:nmrg-bounces@ibr.cs.tu-bs.de] On Behalf Of Juergen
> Schoenwaelder
> Sent: Wednesday, August 04, 2010 9:11 AM
> To: Hari Narayanan
> Cc: nmrg@ibr= .cs.tu-bs.de
> Subject: Re: [nmrg] SNMP OID Compression
>
> On Tue, Aug 03, 2010 at 06:20:49PM +0200, Hari Narayanan wrote:
>
> > OID Compression has been already discussed in two drafts ? Delta<= br> > > compression and Prefix compression. At present, I have worked on = a

> > simple form of prefix compression where all the requested
> objects are
> > at the same level of MIB tree. First object in the request is
fully
> > specified in PDU varbind, rest of the objects are specified
> only with
> > their respective suffix where they differ from the first object.<= br> >
> It would be nice to know how much simpler your compression
> scheme is compared to delta compression, which works with
> arbitrary sequences of OIDs since it does not make any
> assumptions of the OIDs in the payload. It may look more
> complicated at first sight but I believe the code to
> implement delta compression really is not that difficult.
>
> > To continue this investigation, I have also added
> additional code to
> > Net SNMP 5.5 to support this simplified prefix compression. This<= br> > > enables me to measure code size, image size, response time, bytes=
> > saved, and CPU cycles required etc. The additional code required<= br> is
> > about 400 lines (including comment and white space). These
> 400 lines
> > of code are sufficient to enable both agent and application
> to support
> > OID compression. The agent image is larger by about 4Kbytes.
> > I am yet to measure the response time rigorously, but I notice that
> > for getbulk request with large number of objects the
> response time is
> > better with OID compression. The code that encodes objid takes less
> > time because it has to code only the suffix part for all
> but the first
> > object. It is now easy to compare the legacy code with the
> new code in
> > ever aspect. There is only one API function to access and use OID=
> > compression. =A0There is also command line option to request OID<= br> > > compression.
>
> Several studies have reported that the time/cycles spent on
> BER encoding/decoding is not significant compared to the
> overall time/cycles it takes to process a request (see e.g.
> [4]). While this is already true for insecure versions of
> SNMP, if you add authentication and encryption,
> encoding/decoding overhead is not at all relevant. Back in
> the days (> 10 years ago) when OID compression was more
> heavily discussed, the main objective was to pack more data
> into response PDUs, in particular allowing GetBulk requests
> to ship more varbinds in responses. Since there is an
> overshoot issue (unless the manager can estimate the number
> of instances and provide reasonable max-repetitions), a
> GetRange PDU was proposed as well, original idea in [5], more
> detailed description here:
>
> http://tools.ietf.org/html/draft-irtf-nmrg-snmp-getrang= e-00
>
> Nowadays, interest is probably more coming from links that do
> have very small frame sizes and where fragmentation should be
> avoided (such as 802.15.4 networks) and where CPU cycles can
> potentially be saved when security is enabled.
>
> > I am also doing a profiling on a large collection of MIBs (from 250
> > vendors) to understand how and where OID compression could be
taken
> > advantage off. This profiling includes average object
> depth, average
> > object value size, percentage of table objects, number fixed size=
> > object, number of variable size objects, maximum depth, etc.
>
> Such studies based on an analysis of MIB modules have been
> done before [1]. There have also been efforts to collect
> real-world SNMP traces in order to analyze how deployed
> applications actually use SNMP [2]. A more general survey of
> SNMP performance studies can be found in [3].
>
> I am sending these references just in case they help to put
> your work into context.
>
> /js
>
> [1] J. Schonwalder: Characterization of SNMP MIB Modules. 9th
> =A0 =A0 IFIP/IEEE International Symposium on Integrated Network
> =A0 =A0 Management, pages 615-628, Nice, May 2005.
>
> [2] J. Schonwalder, A. Pras, M. Harvan, J. Schippers, R. van de
Meent:
> =A0 =A0 SNMP Traffic Analysis: Approaches, Tools, and First Results. 10th
> =A0 =A0 IFIP/IEEE International Symposium on Integrated Network
> =A0 =A0 Management, Munich, May 2007.
>
> [3] L. Andrey, O. Festor, A. Lahmadi, A. Pras, J. Schonwalder:
Survey
> =A0 =A0 of SNMP Performance Analysis Studies. International Journal of=
> =A0 =A0 Network Management 19(6), Wiley, November 2009.
>
> [4] Aiko Pras, Thomas Drevers, Remco van de Meent, Dirk Quartel:
> =A0 =A0 Comparing the Performance of SNMP and Web services-based
> =A0 =A0 Management. Transactions on Network and Service Management, > =A0 =A0 1(2), IEEE, 2004.
>
> [5] Malowidzki, M., "GetBulk Worth Fixing", Simple Times 10(= 1),
> =A0 =A0 December 2002.
>
> --
> Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGm= bH
> Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, G= ermany
> Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/= >
> --
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To
> unsubscribe or adjust !! your settings, send a mail message
> to <nmrg-request@ibr.cs.tu-bs.de> !! or look at
> https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.


--00504501400c561194048d14c142-- Return-Path: X-Original-To: nmrg@ibr.cs.tu-bs.de Delivered-To: nmrg@ibr.cs.tu-bs.de Received: from mail-vw0-f53.google.com (mail-vw0-f53.google.com [209.85.212.53]) by salvator.ibr.cs.tu-bs.de (Postfix) with ESMTP id DEA5614392 for ; Thu, 5 Aug 2010 03:32:28 +0200 (CEST) Received: by vws15 with SMTP id 15so5265751vws.40 for ; Wed, 04 Aug 2010 18:32:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.162.148 with SMTP id v20mr6755814vcx.36.1280971946812; Wed, 04 Aug 2010 18:32:26 -0700 (PDT) Sender: mark@ellisonsoftware.com Received: by 10.220.11.133 with HTTP; Wed, 4 Aug 2010 18:32:26 -0700 (PDT) In-Reply-To: <36F3C7ABA7B54822A083EFC6D14A33E0@23FX1C1> References: <20100804071122.GA86194@elstar.local> <36F3C7ABA7B54822A083EFC6D14A33E0@23FX1C1> Date: Wed, 4 Aug 2010 21:32:26 -0400 X-Google-Sender-Auth: AZf3uLHL1W3oeDpKhtPozg2DbBU Message-ID: From: Mark Ellison To: nmrg@ibr.cs.tu-bs.de Content-Type: multipart/alternative; boundary=0016e6409c0cdb6573048d09850e X-Virus-Scanned: clamav-milter 0.96.1 at salvator X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,HTML_MESSAGE, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on salvator.ibr.cs.tu-bs.de X-Mailman-Approved-At: Fri, 06 Aug 2010 21:14:09 +0200 Cc: David Harrington , Juergen Schoenwaelder Subject: Re: [nmrg] SNMP OID Compression X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 01:32:33 -0000 --0016e6409c0cdb6573048d09850e Content-Type: text/plain; charset=ISO-8859-1 Hi, This subject is interesting. I have worked with the SNMP since 1990 and believe there might be a rather simple approach to (OID) compression. It occurs to me that the target area to be compressed resides solely within the Scoped PDU. Prior to sending, might there be benefit to simply run the Scoped PDU through a (lossless data) compression algorithm prior to transformation via privacy/encryption and calculation of authentication hashes? Such an approach would be impartial to the frequency of OID prefixes or instances present. It would simply condense the most frequent occurrences of subid patterns. Regards, Mark On Sun, Jul 4, 2010 at 3:44 PM, David Harrington wrote: > Hi, > > I used to work on the Spectrum network management application (years > ago). > > Juergen mentioned real world SNMP traces. My concern with these traces > is with the sample networks, which tended to be academic. I think > academic networks can be very different than commercial networks in > the nature of their management practices. I know Spectrum sold for > $100K+. I am not sure how many academic departments spend $100K+ on > their management platforms. > > I am of the impression that how individual applications collect > objects is likely to be the single biggest factor in SNMP performance. > Much like software profiling, optimizing the collection of a MIB > object that is never or seldom collected yields little benefit. > Optimizing the collection of a single object that is collected very > frequently will yield better results. In software profiling, it is > generally better to optimize printf() than initialize_application(). > > I suggest that a potentially fruitful area of research would be to > study how the major SNMP NMS platforms behave before being extended > for additional MIB modules. These platforms constantly check certain > objects (like sysUpTime) to determine connectivity, detect > discontinuities, update synchronization, monitor interface changes, > etc. They check these routinely every few minutes throughout the day, > for all devices. This generates much more traffic to optimize than > operator-initiated reads using command line tools. > > In my experience, which is now pretty dated, most MIB module > extensions are treated with custom polling instructions defined by the > operator, so they vary by deployment. Otherwise, the extension MIBs > are handled by MIB browser functionality - they are often read only on > demand. > > If an NMS platform has add-on applications, the application will have > certain objects it will monitor (possibly using traps) to determine > when a significant event occurs, and then it will launch a series of > special reads to gather more info on the event, possibly on a > vendor/model-specific basis. > > I would recommend avoiding any proposals that make varbind order > important. Spectrum optimizes (used to optimize) SNMPv1 reads by > reordering the varbinds, and they use a polling engine that might > combine requested polls from multiple applications into a single > varbind to the device. (I don't know if they still do any of that > given SNMPv3 user-based security.) You also might have threading and > subagent issues. > > Spectrum also used to optimize data collection by determining, with > administrator and historical input, how frequently an object needed to > be actually read from the device, or whether an existing database > value, possibly collected for a different application, that is less > than seconds old would suffice. Counters are the datatypes that > most frequently must be refreshed by an actual read, so optimizing for > counters would likely yield bigger benefits than optimizing static > strings. > > As Juergen points out, in the face of other optimization techniques, > OID compression might not be that important. It may be important for > resource-contrained devices, but you'll want to be careful not to > interfere with existing optimization techniques used by the > application side. > > dbh > > > -----Original Message----- > > From: nmrg-bounces@ibr.cs.tu-bs.de > > [mailto:nmrg-bounces@ibr.cs.tu-bs.de] On Behalf Of Juergen > > Schoenwaelder > > Sent: Wednesday, August 04, 2010 9:11 AM > > To: Hari Narayanan > > Cc: nmrg@ibr.cs.tu-bs.de > > Subject: Re: [nmrg] SNMP OID Compression > > > > On Tue, Aug 03, 2010 at 06:20:49PM +0200, Hari Narayanan wrote: > > > > > OID Compression has been already discussed in two drafts ? Delta > > > compression and Prefix compression. At present, I have worked on a > > > > simple form of prefix compression where all the requested > > objects are > > > at the same level of MIB tree. First object in the request is > fully > > > specified in PDU varbind, rest of the objects are specified > > only with > > > their respective suffix where they differ from the first object. > > > > It would be nice to know how much simpler your compression > > scheme is compared to delta compression, which works with > > arbitrary sequences of OIDs since it does not make any > > assumptions of the OIDs in the payload. It may look more > > complicated at first sight but I believe the code to > > implement delta compression really is not that difficult. > > > > > To continue this investigation, I have also added > > additional code to > > > Net SNMP 5.5 to support this simplified prefix compression. This > > > enables me to measure code size, image size, response time, bytes > > > saved, and CPU cycles required etc. The additional code required > is > > > about 400 lines (including comment and white space). These > > 400 lines > > > of code are sufficient to enable both agent and application > > to support > > > OID compression. The agent image is larger by about 4Kbytes. > > > I am yet to measure the response time rigorously, but I notice > that > > > for getbulk request with large number of objects the > > response time is > > > better with OID compression. The code that encodes objid takes > less > > > time because it has to code only the suffix part for all > > but the first > > > object. It is now easy to compare the legacy code with the > > new code in > > > ever aspect. There is only one API function to access and use OID > > > compression. There is also command line option to request OID > > > compression. > > > > Several studies have reported that the time/cycles spent on > > BER encoding/decoding is not significant compared to the > > overall time/cycles it takes to process a request (see e.g. > > [4]). While this is already true for insecure versions of > > SNMP, if you add authentication and encryption, > > encoding/decoding overhead is not at all relevant. Back in > > the days (> 10 years ago) when OID compression was more > > heavily discussed, the main objective was to pack more data > > into response PDUs, in particular allowing GetBulk requests > > to ship more varbinds in responses. Since there is an > > overshoot issue (unless the manager can estimate the number > > of instances and provide reasonable max-repetitions), a > > GetRange PDU was proposed as well, original idea in [5], more > > detailed description here: > > > > http://tools.ietf.org/html/draft-irtf-nmrg-snmp-getrange-00 > > > > Nowadays, interest is probably more coming from links that do > > have very small frame sizes and where fragmentation should be > > avoided (such as 802.15.4 networks) and where CPU cycles can > > potentially be saved when security is enabled. > > > > > I am also doing a profiling on a large collection of MIBs (from > 250 > > > vendors) to understand how and where OID compression could be > taken > > > advantage off. This profiling includes average object > > depth, average > > > object value size, percentage of table objects, number fixed size > > > object, number of variable size objects, maximum depth, etc. > > > > Such studies based on an analysis of MIB modules have been > > done before [1]. There have also been efforts to collect > > real-world SNMP traces in order to analyze how deployed > > applications actually use SNMP [2]. A more general survey of > > SNMP performance studies can be found in [3]. > > > > I am sending these references just in case they help to put > > your work into context. > > > > /js > > > > [1] J. Schonwalder: Characterization of SNMP MIB Modules. 9th > > IFIP/IEEE International Symposium on Integrated Network > > Management, pages 615-628, Nice, May 2005. > > > > [2] J. Schonwalder, A. Pras, M. Harvan, J. Schippers, R. van de > Meent: > > SNMP Traffic Analysis: Approaches, Tools, and First Results. > 10th > > IFIP/IEEE International Symposium on Integrated Network > > Management, Munich, May 2007. > > > > [3] L. Andrey, O. Festor, A. Lahmadi, A. Pras, J. Schonwalder: > Survey > > of SNMP Performance Analysis Studies. International Journal of > > Network Management 19(6), Wiley, November 2009. > > > > [4] Aiko Pras, Thomas Drevers, Remco van de Meent, Dirk Quartel: > > Comparing the Performance of SNMP and Web services-based > > Management. Transactions on Network and Service Management, > > 1(2), IEEE, 2004. > > > > [5] Malowidzki, M., "GetBulk Worth Fixing", Simple Times 10(1), > > December 2002. > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > -- > > !! This message is brought to you via the `nmrg' mailing list. > > !! Please do not reply to this message to unsubscribe. To > > unsubscribe or adjust !! your settings, send a mail message > > to !! or look at > > https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. > > -- > !! This message is brought to you via the `nmrg' mailing list. > !! Please do not reply to this message to unsubscribe. To unsubscribe or > adjust > !! your settings, send a mail message to > !! or look at https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. > --0016e6409c0cdb6573048d09850e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

This subject is interesting.=A0 I have worked with the SNMP sinc= e 1990 and believe there might be a rather simple approach to (OID) compres= sion.

It occurs to me that the target area to be compressed resides = solely within the Scoped PDU.

Prior to sending, might there be benefit to simply run the Scoped PDU t= hrough a (lossless data) compression algorithm prior to transformation via = privacy/encryption and calculation of authentication hashes?

Such an= approach would be impartial to the frequency of OID prefixes or instances = present.=A0 It would simply condense the most frequent occurrences of subid= patterns.

Regards,

Mark

On Sun, Jul 4, 2= 010 at 3:44 PM, David Harrington <ietfdbh@comcast.net> wrote:
Hi,

I used to work on the Spectrum network management application (years
ago).

Juergen mentioned real world SNMP traces. My concern with these traces
is with the sample networks, which tended to be academic. I think
academic networks can be very different than commercial networks in
the nature of their management practices. I know Spectrum sold for
$100K+. I am not sure how many academic departments spend $100K+ on
their management platforms.

I am of the impression that how individual applications collect
objects is likely to be the single biggest factor in SNMP performance.
Much like software profiling, optimizing the collection of a MIB
object that is never or seldom collected yields little benefit.
Optimizing the collection of a single object that is collected very
frequently will yield better results. In software profiling, it is
generally better to optimize printf() than initialize_application().

I suggest that a potentially fruitful area of research would be to
study how the major SNMP NMS platforms behave before being extended
for additional MIB modules. These platforms constantly check certain
objects (like sysUpTime) to determine connectivity, detect
discontinuities, update synchronization, monitor interface changes,
etc. They check these routinely every few minutes throughout the day,
for all devices. This generates much more traffic to optimize than
operator-initiated reads using command line tools.

In my experience, which is now pretty dated, most MIB module
extensions are treated with custom polling instructions defined by the
operator, so they vary by deployment. Otherwise, the extension MIBs
are handled by MIB browser functionality - they are often read only on
demand.

If an NMS platform has add-on applications, the application will have
certain objects it will monitor (possibly using traps) to determine
when a significant event occurs, and then it will launch a series of
special reads to gather more info on the event, possibly on a
vendor/model-specific basis.

I would recommend avoiding any proposals that make varbind order
important. Spectrum optimizes (used to optimize) SNMPv1 reads by
reordering the varbinds, and they use a polling engine that might
combine requested polls from multiple applications into a single
varbind to the device. (I don't know if they still do any of that
given SNMPv3 user-based security.) You also might have threading and
subagent issues.

Spectrum also used to optimize data collection by determining, with
administrator and historical input, how frequently an object needed to
be actually read from the device, or whether an existing database
value, possibly collected for a different application, that is less
than <x> seconds old would suffice. Counters are the datatypes that most frequently must be refreshed by an actual read, so optimizing for
counters would likely yield bigger benefits than optimizing static
strings.

As Juergen points out, in the face of other optimization techniques,
OID compression might not be that important. It may be important for
resource-contrained devices, but you'll want to be careful not to
interfere with existing optimization techniques used by the
application side.

dbh

> -----Original Message-----
> From: nmrg-bounces@ibr= .cs.tu-bs.de
> [mailto:nmrg-bounces@i= br.cs.tu-bs.de] On Behalf Of Juergen
> Schoenwaelder
> Sent: Wednesday, August 04, 2010 9:11 AM
> To: Hari Narayanan
> Cc: nmrg@ibr.cs.tu-bs.de > Subject: Re: [nmrg] SNMP OID Compression
>
> On Tue, Aug 03, 2010 at 06:20:49PM +0200, Hari Narayanan wrote:
>
> > OID Compression has been already discussed in two drafts ? Delta<= br> > > compression and Prefix compression. At present, I have worked on = a

> > simple form of prefix compression where all the requested
> objects are
> > at the same level of MIB tree. First object in the request is
fully
> > specified in PDU varbind, rest of the objects are specified
> only with
> > their respective suffix where they differ from the first object.<= br> >
> It would be nice to know how much simpler your compression
> scheme is compared to delta compression, which works with
> arbitrary sequences of OIDs since it does not make any
> assumptions of the OIDs in the payload. It may look more
> complicated at first sight but I believe the code to
> implement delta compression really is not that difficult.
>
> > To continue this investigation, I have also added
> additional code to
> > Net SNMP 5.5 to support this simplified prefix compression. This<= br> > > enables me to measure code size, image size, response time, bytes=
> > saved, and CPU cycles required etc. The additional code required<= br> is
> > about 400 lines (including comment and white space). These
> 400 lines
> > of code are sufficient to enable both agent and application
> to support
> > OID compression. The agent image is larger by about 4Kbytes.
> > I am yet to measure the response time rigorously, but I notice that
> > for getbulk request with large number of objects the
> response time is
> > better with OID compression. The code that encodes objid takes less
> > time because it has to code only the suffix part for all
> but the first
> > object. It is now easy to compare the legacy code with the
> new code in
> > ever aspect. There is only one API function to access and use OID=
> > compression. =A0There is also command line option to request OID<= br> > > compression.
>
> Several studies have reported that the time/cycles spent on
> BER encoding/decoding is not significant compared to the
> overall time/cycles it takes to process a request (see e.g.
> [4]). While this is already true for insecure versions of
> SNMP, if you add authentication and encryption,
> encoding/decoding overhead is not at all relevant. Back in
> the days (> 10 years ago) when OID compression was more
> heavily discussed, the main objective was to pack more data
> into response PDUs, in particular allowing GetBulk requests
> to ship more varbinds in responses. Since there is an
> overshoot issue (unless the manager can estimate the number
> of instances and provide reasonable max-repetitions), a
> GetRange PDU was proposed as well, original idea in [5], more
> detailed description here:
>
> http://tools.ietf.org/html/draft-irtf-nmrg-snmp-getrang= e-00
>
> Nowadays, interest is probably more coming from links that do
> have very small frame sizes and where fragmentation should be
> avoided (such as 802.15.4 networks) and where CPU cycles can
> potentially be saved when security is enabled.
>
> > I am also doing a profiling on a large collection of MIBs (from 250
> > vendors) to understand how and where OID compression could be
taken
> > advantage off. This profiling includes average object
> depth, average
> > object value size, percentage of table objects, number fixed size=
> > object, number of variable size objects, maximum depth, etc.
>
> Such studies based on an analysis of MIB modules have been
> done before [1]. There have also been efforts to collect
> real-world SNMP traces in order to analyze how deployed
> applications actually use SNMP [2]. A more general survey of
> SNMP performance studies can be found in [3].
>
> I am sending these references just in case they help to put
> your work into context.
>
> /js
>
> [1] J. Schonwalder: Characterization of SNMP MIB Modules. 9th
> =A0 =A0 IFIP/IEEE International Symposium on Integrated Network
> =A0 =A0 Management, pages 615-628, Nice, May 2005.
>
> [2] J. Schonwalder, A. Pras, M. Harvan, J. Schippers, R. van de
Meent:
> =A0 =A0 SNMP Traffic Analysis: Approaches, Tools, and First Results. 10th
> =A0 =A0 IFIP/IEEE International Symposium on Integrated Network
> =A0 =A0 Management, Munich, May 2007.
>
> [3] L. Andrey, O. Festor, A. Lahmadi, A. Pras, J. Schonwalder:
Survey
> =A0 =A0 of SNMP Performance Analysis Studies. International Journal of=
> =A0 =A0 Network Management 19(6), Wiley, November 2009.
>
> [4] Aiko Pras, Thomas Drevers, Remco van de Meent, Dirk Quartel:
> =A0 =A0 Comparing the Performance of SNMP and Web services-based
> =A0 =A0 Management. Transactions on Network and Service Management, > =A0 =A0 1(2), IEEE, 2004.
>
> [5] Malowidzki, M., "GetBulk Worth Fixing", Simple Times 10(= 1),
> =A0 =A0 December 2002.
>
> --
> Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGm= bH
> Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, G= ermany
> Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/= >
> --
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To
> unsubscribe or adjust !! your settings, send a mail message
> to <nmrg-request@ib= r.cs.tu-bs.de> !! or look at
> https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

--
!! This message is brought to you via the `nmrg' mailing list.
!! Please do not reply to this message to unsubscribe. To unsubscribe or ad= just
!! your settings, send a mail message to <nmrg-request@ibr.cs.tu-bs.de>
!! or look at https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.=

--0016e6409c0cdb6573048d09850e-- Return-Path: X-Original-To: nmrg@ibr.cs.tu-bs.de Delivered-To: nmrg@ibr.cs.tu-bs.de Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by salvator.ibr.cs.tu-bs.de (Postfix) with ESMTP id 4C6C01419C for ; Wed, 4 Aug 2010 21:44:56 +0200 (CEST) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta12.emeryville.ca.mail.comcast.net with comcast id qKhv1e0070b6N64ACKkudo; Wed, 04 Aug 2010 19:44:54 +0000 Received: from 23FX1C1 ([95.152.87.88]) by omta03.emeryville.ca.mail.comcast.net with comcast id qKke1e00F1uMkLn8PKkhzh; Wed, 04 Aug 2010 19:44:52 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Hari Narayanan'" References: <20100804071122.GA86194@elstar.local> Message-ID: <36F3C7ABA7B54822A083EFC6D14A33E0@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20100804071122.GA86194@elstar.local> Thread-Index: AcszpExseEhFdPQuRZy2M/n3fXog7AYTxa+g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Virus-Scanned: clamav-milter 0.96.1 at salvator X-Virus-Status: Clean X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, DATE_IN_PAST_96_XX, SPF_PASS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on salvator.ibr.cs.tu-bs.de Cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] SNMP OID Compression X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 04 Aug 2010 19:44:59 -0000 X-Original-Date: Sun, 4 Jul 2010 21:44:45 +0200 X-List-Received-Date: Wed, 04 Aug 2010 19:44:59 -0000 Hi, I used to work on the Spectrum network management application (years ago). Juergen mentioned real world SNMP traces. My concern with these traces is with the sample networks, which tended to be academic. I think academic networks can be very different than commercial networks in the nature of their management practices. I know Spectrum sold for $100K+. I am not sure how many academic departments spend $100K+ on their management platforms. I am of the impression that how individual applications collect objects is likely to be the single biggest factor in SNMP performance. Much like software profiling, optimizing the collection of a MIB object that is never or seldom collected yields little benefit. Optimizing the collection of a single object that is collected very frequently will yield better results. In software profiling, it is generally better to optimize printf() than initialize_application(). I suggest that a potentially fruitful area of research would be to study how the major SNMP NMS platforms behave before being extended for additional MIB modules. These platforms constantly check certain objects (like sysUpTime) to determine connectivity, detect discontinuities, update synchronization, monitor interface changes, etc. They check these routinely every few minutes throughout the day, for all devices. This generates much more traffic to optimize than operator-initiated reads using command line tools. In my experience, which is now pretty dated, most MIB module extensions are treated with custom polling instructions defined by the operator, so they vary by deployment. Otherwise, the extension MIBs are handled by MIB browser functionality - they are often read only on demand. If an NMS platform has add-on applications, the application will have certain objects it will monitor (possibly using traps) to determine when a significant event occurs, and then it will launch a series of special reads to gather more info on the event, possibly on a vendor/model-specific basis. I would recommend avoiding any proposals that make varbind order important. Spectrum optimizes (used to optimize) SNMPv1 reads by reordering the varbinds, and they use a polling engine that might combine requested polls from multiple applications into a single varbind to the device. (I don't know if they still do any of that given SNMPv3 user-based security.) You also might have threading and subagent issues. Spectrum also used to optimize data collection by determining, with administrator and historical input, how frequently an object needed to be actually read from the device, or whether an existing database value, possibly collected for a different application, that is less than seconds old would suffice. Counters are the datatypes that most frequently must be refreshed by an actual read, so optimizing for counters would likely yield bigger benefits than optimizing static strings. As Juergen points out, in the face of other optimization techniques, OID compression might not be that important. It may be important for resource-contrained devices, but you'll want to be careful not to interfere with existing optimization techniques used by the application side. dbh > -----Original Message----- > From: nmrg-bounces@ibr.cs.tu-bs.de > [mailto:nmrg-bounces@ibr.cs.tu-bs.de] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, August 04, 2010 9:11 AM > To: Hari Narayanan > Cc: nmrg@ibr.cs.tu-bs.de > Subject: Re: [nmrg] SNMP OID Compression > > On Tue, Aug 03, 2010 at 06:20:49PM +0200, Hari Narayanan wrote: > > > OID Compression has been already discussed in two drafts ? Delta > > compression and Prefix compression. At present, I have worked on a > > simple form of prefix compression where all the requested > objects are > > at the same level of MIB tree. First object in the request is fully > > specified in PDU varbind, rest of the objects are specified > only with > > their respective suffix where they differ from the first object. > > It would be nice to know how much simpler your compression > scheme is compared to delta compression, which works with > arbitrary sequences of OIDs since it does not make any > assumptions of the OIDs in the payload. It may look more > complicated at first sight but I believe the code to > implement delta compression really is not that difficult. > > > To continue this investigation, I have also added > additional code to > > Net SNMP 5.5 to support this simplified prefix compression. This > > enables me to measure code size, image size, response time, bytes > > saved, and CPU cycles required etc. The additional code required is > > about 400 lines (including comment and white space). These > 400 lines > > of code are sufficient to enable both agent and application > to support > > OID compression. The agent image is larger by about 4Kbytes. > > I am yet to measure the response time rigorously, but I notice that > > for getbulk request with large number of objects the > response time is > > better with OID compression. The code that encodes objid takes less > > time because it has to code only the suffix part for all > but the first > > object. It is now easy to compare the legacy code with the > new code in > > ever aspect. There is only one API function to access and use OID > > compression. There is also command line option to request OID > > compression. > > Several studies have reported that the time/cycles spent on > BER encoding/decoding is not significant compared to the > overall time/cycles it takes to process a request (see e.g. > [4]). While this is already true for insecure versions of > SNMP, if you add authentication and encryption, > encoding/decoding overhead is not at all relevant. Back in > the days (> 10 years ago) when OID compression was more > heavily discussed, the main objective was to pack more data > into response PDUs, in particular allowing GetBulk requests > to ship more varbinds in responses. Since there is an > overshoot issue (unless the manager can estimate the number > of instances and provide reasonable max-repetitions), a > GetRange PDU was proposed as well, original idea in [5], more > detailed description here: > > http://tools.ietf.org/html/draft-irtf-nmrg-snmp-getrange-00 > > Nowadays, interest is probably more coming from links that do > have very small frame sizes and where fragmentation should be > avoided (such as 802.15.4 networks) and where CPU cycles can > potentially be saved when security is enabled. > > > I am also doing a profiling on a large collection of MIBs (from 250 > > vendors) to understand how and where OID compression could be taken > > advantage off. This profiling includes average object > depth, average > > object value size, percentage of table objects, number fixed size > > object, number of variable size objects, maximum depth, etc. > > Such studies based on an analysis of MIB modules have been > done before [1]. There have also been efforts to collect > real-world SNMP traces in order to analyze how deployed > applications actually use SNMP [2]. A more general survey of > SNMP performance studies can be found in [3]. > > I am sending these references just in case they help to put > your work into context. > > /js > > [1] J. Schonwalder: Characterization of SNMP MIB Modules. 9th > IFIP/IEEE International Symposium on Integrated Network > Management, pages 615-628, Nice, May 2005. > > [2] J. Schonwalder, A. Pras, M. Harvan, J. Schippers, R. van de Meent: > SNMP Traffic Analysis: Approaches, Tools, and First Results. 10th > IFIP/IEEE International Symposium on Integrated Network > Management, Munich, May 2007. > > [3] L. Andrey, O. Festor, A. Lahmadi, A. Pras, J. Schonwalder: Survey > of SNMP Performance Analysis Studies. International Journal of > Network Management 19(6), Wiley, November 2009. > > [4] Aiko Pras, Thomas Drevers, Remco van de Meent, Dirk Quartel: > Comparing the Performance of SNMP and Web services-based > Management. Transactions on Network and Service Management, > 1(2), IEEE, 2004. > > [5] Malowidzki, M., "GetBulk Worth Fixing", Simple Times 10(1), > December 2002. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > -- > !! This message is brought to you via the `nmrg' mailing list. > !! Please do not reply to this message to unsubscribe. To > unsubscribe or adjust !! your settings, send a mail message > to !! or look at > https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. Return-Path: X-Original-To: nmrg@ibr.cs.tu-bs.de Delivered-To: nmrg@ibr.cs.tu-bs.de Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by salvator.ibr.cs.tu-bs.de (Postfix) with ESMTP id C66AD14338 for ; Wed, 4 Aug 2010 11:24:36 +0200 (CEST) Received: by ywh2 with SMTP id 2so2963898ywh.40 for ; Wed, 04 Aug 2010 02:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=KEnsAWHozblSh4rDDSpH1mqfe/B3/VgojH+D6hHM104=; b=NumaFlE/sYTuFGR05X3URCsW+2iBBHyLQ70sm8xaJSGGDTb17H2/NcZE7g177w7Hpq nu+KYrLJ7d8bmhLa1hPhcWPCAqz39obGKsx+g8LGbuqQH/P86eQp8x9hYoYPSBYf3H+O rBvz0Hm/5dTNBWlEzifHCLWUzDVPPIJTyatuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=vDPJwWYtCzQ9lM45a15F0lEQ33oovzGRiTI+UXLGK4MP3OCaqTBgo+Dz0FQZUfj+rJ CF+E5RM6GWiC7oaRJrHaXN8xFX3Hz4ApJ1XMge/72CKCmvuSJ+ScWxhdw8KslTW8Km7H ZNQdFcre0ZhWRaD8tzN67VdLCiZL24vS7glpQ= MIME-Version: 1.0 Received: by 10.231.32.200 with SMTP id e8mr10266445ibd.66.1280913875155; Wed, 04 Aug 2010 02:24:35 -0700 (PDT) Received: by 10.231.59.6 with HTTP; Wed, 4 Aug 2010 02:24:32 -0700 (PDT) In-Reply-To: <20100804071122.GA86194@elstar.local> References: <20100804071122.GA86194@elstar.local> Date: Wed, 4 Aug 2010 14:54:32 +0530 Message-ID: From: Hari Narayanan To: Juergen Schoenwaelder , Hari Narayanan , "nmrg@ibr.cs.tu-bs.de" Content-Type: multipart/alternative; boundary=0022152d6eb1843a55048cfc00e3 X-Virus-Scanned: clamav-milter 0.96.1 at salvator X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, SPF_PASS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on salvator.ibr.cs.tu-bs.de X-Mailman-Approved-At: Fri, 06 Aug 2010 21:14:25 +0200 Subject: Re: [nmrg] SNMP OID Compression X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 09:24:43 -0000 --0022152d6eb1843a55048cfc00e3 Content-Type: text/plain; charset=ISO-8859-1 Thanks JS, I do not expect the complexity of Delta compression to be significantly different. Now I understand Net SNMP better, I plan to do that in the near future. The additional complexity comes only in coding compression for three cases: Single Identifier, Range of Identifiers, and Truncation. I will have some concrete answers for you when I complete it. Keeping the compression overhead is a requirement to justify the other benefits. The main objective in my opinion is to save packets instead of bytes. In the worst case, with OID compression feature, we reduce SNMP traffic volume. In the best case, we also relieve control processor from management activity. OID Compression can reduce the CPU cycles at an agent to 50% (assuming one response does the job of two) for certain requests. For a typical table object at a depth of 14 if the response contains about 60 objects then one request will do the job of 2. This is perhaps, the real selling point for OID compression, though it requires the developers to be aware of this feature and table profile. Let me look at the references that you listed. Regards .... Hari T S Narayanan On Wed, Aug 4, 2010 at 12:41 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Aug 03, 2010 at 06:20:49PM +0200, Hari Narayanan wrote: > > > OID Compression has been already discussed in two drafts ? Delta > > compression and Prefix compression. At present, I have worked on a > > simple form of prefix compression where all the requested objects > > are at the same level of MIB tree. First object in the request is > > fully specified in PDU varbind, rest of the objects are specified > > only with their respective suffix where they differ from the first > > object. > > It would be nice to know how much simpler your compression scheme is > compared to delta compression, which works with arbitrary sequences of > OIDs since it does not make any assumptions of the OIDs in the > payload. It may look more complicated at first sight but I believe the > code to implement delta compression really is not that difficult. > > > To continue this investigation, I have also added additional code to > > Net SNMP 5.5 to support this simplified prefix compression. This > > enables me to measure code size, image size, response time, bytes > > saved, and CPU cycles required etc. The additional code required is > > about 400 lines (including comment and white space). These 400 lines > > of code are sufficient to enable both agent and application to > > support OID compression. The agent image is larger by about 4Kbytes. > > I am yet to measure the response time rigorously, but I notice that > > for getbulk request with large number of objects the response time > > is better with OID compression. The code that encodes objid takes > > less time because it has to code only the suffix part for all but > > the first object. It is now easy to compare the legacy code with the > > new code in ever aspect. There is only one API function to access > > and use OID compression. There is also command line option to > > request OID compression. > > Several studies have reported that the time/cycles spent on BER > encoding/decoding is not significant compared to the overall > time/cycles it takes to process a request (see e.g. [4]). While this > is already true for insecure versions of SNMP, if you add > authentication and encryption, encoding/decoding overhead is not at > all relevant. Back in the days (> 10 years ago) when OID compression > was more heavily discussed, the main objective was to pack more data > into response PDUs, in particular allowing GetBulk requests to ship > more varbinds in responses. Since there is an overshoot issue (unless > the manager can estimate the number of instances and provide > reasonable max-repetitions), a GetRange PDU was proposed as well, > original idea in [5], more detailed description here: > > http://tools.ietf.org/html/draft-irtf-nmrg-snmp-getrange-00 > > Nowadays, interest is probably more coming from links that do have > very small frame sizes and where fragmentation should be avoided (such > as 802.15.4 networks) and where CPU cycles can potentially be saved > when security is enabled. > > > I am also doing a profiling on a large collection of MIBs (from 250 > > vendors) to understand how and where OID compression could be taken > > advantage off. This profiling includes average object depth, average > > object value size, percentage of table objects, number fixed size > > object, number of variable size objects, maximum depth, etc. > > Such studies based on an analysis of MIB modules have been done before > [1]. There have also been efforts to collect real-world SNMP traces in > order to analyze how deployed applications actually use SNMP [2]. A > more general survey of SNMP performance studies can be found in [3]. > > I am sending these references just in case they help to put your work > into context. > > /js > > [1] J. Schonwalder: Characterization of SNMP MIB Modules. 9th > IFIP/IEEE International Symposium on Integrated Network > Management, pages 615-628, Nice, May 2005. > > [2] J. Schonwalder, A. Pras, M. Harvan, J. Schippers, R. van de Meent: > SNMP Traffic Analysis: Approaches, Tools, and First Results. 10th > IFIP/IEEE International Symposium on Integrated Network > Management, Munich, May 2007. > > [3] L. Andrey, O. Festor, A. Lahmadi, A. Pras, J. Schonwalder: Survey > of SNMP Performance Analysis Studies. International Journal of > Network Management 19(6), Wiley, November 2009. > > [4] Aiko Pras, Thomas Drevers, Remco van de Meent, Dirk Quartel: > Comparing the Performance of SNMP and Web services-based > Management. Transactions on Network and Service Management, > 1(2), IEEE, 2004. > > [5] Malowidzki, M., "GetBulk Worth Fixing", Simple Times 10(1), > December 2002. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --0022152d6eb1843a55048cfc00e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks JS,
I do not expect the complexity of Delta compression to be si= gnificantly different. Now I understand Net SNMP better, I plan=A0to do tha= t in the near future. The additional complexity comes only in coding compre= ssion for three cases: Single Identifier, Range of Identifiers, and Truncat= ion. I will have some concrete answers for you when I complete it.

Keeping the compression overhead is a requirement to ju= stify the other benefits. The main objective in my opinion is to save packe= ts instead of bytes. =A0In the worst case, with OID compression feature, we= reduce SNMP traffic volume. In the best case, we also relieve control proc= essor =A0from management activity. OID Compression can reduce the CPU cycle= s at an agent to 50% (assuming one response does the job of two) for certai= n requests. For a typical table object at a depth of 14 if the response con= tains about 60 objects then one request will do the job of 2. This is perha= ps, the real selling point for OID compression, though it requires the deve= lopers to be aware of this feature and table profile.

Let me look at the references that you listed.

Regards .... Hari T S Narayanan

On Wed, Aug 4, 2010 at 12:41 PM, Juergen Schoenwaelder <= j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Aug 03, 2010 at 0= 6:20:49PM +0200, Hari Narayanan wrote:

> OID Compression has been already discussed in two drafts ? Delta
> compression and Prefix compression. At present, I have worked on a
> simple form of prefix compression where all the requested objects
> are at the same level of MIB tree. First object in the request is
> fully specified in PDU varbind, rest of the objects are specified
> only with their respective suffix where they differ from the first
> object.

It would be nice to know how much simpler your compression scheme is<= br> compared to delta compression, which works with arbitrary sequences of
OIDs since it does not make any assumptions of the OIDs in the
payload. It may look more complicated at first sight but I believe the
code to implement delta compression really is not that difficult.

> To continue this investigation, I have also added additional code to > Net SNMP 5.5 to support this simplified prefix compression. This
> enables me to measure code size, image size, response time, bytes
> saved, and CPU cycles required etc. The additional code required is > about 400 lines (including comment and white space). These 400 lines > of code are sufficient to enable both agent and application to
> support OID compression. The agent image is larger by about 4Kbytes. > I am yet to measure the response time rigorously, but I notice that > for getbulk request with large number of objects the response time
> is better with OID compression. The code that encodes objid takes
> less time because it has to code only the suffix part for all but
> the first object. It is now easy to compare the legacy code with the > new code in ever aspect. There is only one API function to access
> and use OID compression. =A0There is also command line option to
> request OID compression.

Several studies have reported that the time/cycles spent on BER
encoding/decoding is not significant compared to the overall
time/cycles it takes to process a request (see e.g. [4]). While this
is already true for insecure versions of SNMP, if you add
authentication and encryption, encoding/decoding overhead is not at
all relevant. Back in the days (> 10 years ago) when OID compression
was more heavily discussed, the main objective was to pack more data
into response PDUs, in particular allowing GetBulk requests to ship
more varbinds in responses. Since there is an overshoot issue (unless
the manager can estimate the number of instances and provide
reasonable max-repetitions), a GetRange PDU was proposed as well,
original idea in [5], more detailed description here:

http://tools.ietf.org/html/draft-irtf-nmrg-snmp-getrange-00<= /a>

Nowadays, interest is probably more coming from links that do have
very small frame sizes and where fragmentation should be avoided (such
as 802.15.4 networks) and where CPU cycles can potentially be saved
when security is enabled.

> I am also doing a profiling on a large collection of MIBs (from 250 > vendors) to understand how and where OID compression could be taken > advantage off. This profiling includes average object depth, average > object value size, percentage of table objects, number fixed size
> object, number of variable size objects, maximum depth, etc.

Such studies based on an analysis of MIB modules have been done befor= e
[1]. There have also been efforts to collect real-world SNMP traces in
order to analyze how deployed applications actually use SNMP [2]. A
more general survey of SNMP performance studies can be found in [3].

I am sending these references just in case they help to put your work
into context.

/js

[1] J. Schonwalder: Characterization of SNMP MIB Modules. 9th
=A0 =A0IFIP/IEEE International Symposium on Integrated Network
=A0 =A0Management, pages 615-628, Nice, May 2005.

[2] J. Schonwalder, A. Pras, M. Harvan, J. Schippers, R. van de Meent:
=A0 =A0SNMP Traffic Analysis: Approaches, Tools, and First Results. 10th =A0 =A0IFIP/IEEE International Symposium on Integrated Network
=A0 =A0Management, Munich, May 2007.

[3] L. Andrey, O. Festor, A. Lahmadi, A. Pras, J. Schonwalder: Survey
=A0 =A0of SNMP Performance Analysis Studies. International Journal of
=A0 =A0Network Management 19(6), Wiley, November 2009.

[4] Aiko Pras, Thomas Drevers, Remco van de Meent, Dirk Quartel:
=A0 =A0Comparing the Performance of SNMP and Web services-based
=A0 =A0Management. Transactions on Network and Service Management,
=A0 =A01(2), IEEE, 2004.

[5] Malowidzki, M., "GetBulk Worth Fixing", Simple Times 10(1), =A0 =A0December 2002.

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>

--0022152d6eb1843a55048cfc00e3-- Return-Path: X-Original-To: nmrg@ibr.cs.tu-bs.de Delivered-To: nmrg@ibr.cs.tu-bs.de Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by salvator.ibr.cs.tu-bs.de (Postfix) with ESMTP id 86A5614313 for ; Wed, 4 Aug 2010 09:11:31 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F7EDC0011; Wed, 4 Aug 2010 09:11:31 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wEF9j2RChwcg; Wed, 4 Aug 2010 09:11:29 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E4BAC000C; Wed, 4 Aug 2010 09:11:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EA6401410D71; Wed, 4 Aug 2010 09:11:22 +0200 (CEST) Date: Wed, 4 Aug 2010 09:11:22 +0200 From: Juergen Schoenwaelder To: Hari Narayanan Message-ID: <20100804071122.GA86194@elstar.local> Mail-Followup-To: Hari Narayanan , "nmrg@ibr.cs.tu-bs.de" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96.1 at salvator X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on salvator.ibr.cs.tu-bs.de Cc: "nmrg@ibr.cs.tu-bs.de" Subject: Re: [nmrg] SNMP OID Compression X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 07:11:34 -0000 On Tue, Aug 03, 2010 at 06:20:49PM +0200, Hari Narayanan wrote: > OID Compression has been already discussed in two drafts ? Delta > compression and Prefix compression. At present, I have worked on a > simple form of prefix compression where all the requested objects > are at the same level of MIB tree. First object in the request is > fully specified in PDU varbind, rest of the objects are specified > only with their respective suffix where they differ from the first > object. It would be nice to know how much simpler your compression scheme is compared to delta compression, which works with arbitrary sequences of OIDs since it does not make any assumptions of the OIDs in the payload. It may look more complicated at first sight but I believe the code to implement delta compression really is not that difficult. > To continue this investigation, I have also added additional code to > Net SNMP 5.5 to support this simplified prefix compression. This > enables me to measure code size, image size, response time, bytes > saved, and CPU cycles required etc. The additional code required is > about 400 lines (including comment and white space). These 400 lines > of code are sufficient to enable both agent and application to > support OID compression. The agent image is larger by about 4Kbytes. > I am yet to measure the response time rigorously, but I notice that > for getbulk request with large number of objects the response time > is better with OID compression. The code that encodes objid takes > less time because it has to code only the suffix part for all but > the first object. It is now easy to compare the legacy code with the > new code in ever aspect. There is only one API function to access > and use OID compression. There is also command line option to > request OID compression. Several studies have reported that the time/cycles spent on BER encoding/decoding is not significant compared to the overall time/cycles it takes to process a request (see e.g. [4]). While this is already true for insecure versions of SNMP, if you add authentication and encryption, encoding/decoding overhead is not at all relevant. Back in the days (> 10 years ago) when OID compression was more heavily discussed, the main objective was to pack more data into response PDUs, in particular allowing GetBulk requests to ship more varbinds in responses. Since there is an overshoot issue (unless the manager can estimate the number of instances and provide reasonable max-repetitions), a GetRange PDU was proposed as well, original idea in [5], more detailed description here: http://tools.ietf.org/html/draft-irtf-nmrg-snmp-getrange-00 Nowadays, interest is probably more coming from links that do have very small frame sizes and where fragmentation should be avoided (such as 802.15.4 networks) and where CPU cycles can potentially be saved when security is enabled. > I am also doing a profiling on a large collection of MIBs (from 250 > vendors) to understand how and where OID compression could be taken > advantage off. This profiling includes average object depth, average > object value size, percentage of table objects, number fixed size > object, number of variable size objects, maximum depth, etc. Such studies based on an analysis of MIB modules have been done before [1]. There have also been efforts to collect real-world SNMP traces in order to analyze how deployed applications actually use SNMP [2]. A more general survey of SNMP performance studies can be found in [3]. I am sending these references just in case they help to put your work into context. /js [1] J. Schonwalder: Characterization of SNMP MIB Modules. 9th IFIP/IEEE International Symposium on Integrated Network Management, pages 615-628, Nice, May 2005. [2] J. Schonwalder, A. Pras, M. Harvan, J. Schippers, R. van de Meent: SNMP Traffic Analysis: Approaches, Tools, and First Results. 10th IFIP/IEEE International Symposium on Integrated Network Management, Munich, May 2007. [3] L. Andrey, O. Festor, A. Lahmadi, A. Pras, J. Schonwalder: Survey of SNMP Performance Analysis Studies. International Journal of Network Management 19(6), Wiley, November 2009. [4] Aiko Pras, Thomas Drevers, Remco van de Meent, Dirk Quartel: Comparing the Performance of SNMP and Web services-based Management. Transactions on Network and Service Management, 1(2), IEEE, 2004. [5] Malowidzki, M., "GetBulk Worth Fixing", Simple Times 10(1), December 2002. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Return-Path: X-Original-To: nmrg@ibr.cs.tu-bs.de Delivered-To: nmrg@ibr.cs.tu-bs.de Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by salvator.ibr.cs.tu-bs.de (Postfix) with ESMTP id D06BE142D8 for ; Tue, 3 Aug 2010 18:20:52 +0200 (CEST) Received: by gxk28 with SMTP id 28so2618781gxk.40 for ; Tue, 03 Aug 2010 09:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=maOK64qOVjmNS+L/nyRmqAn3sLPbPZnBTu9rBBWmAJU=; b=TfuIZagadq3QOZy7HX4RY9MGUaYeZjHfxVpmo1ClIfiCSnimQlaDflJ2yF1hvNGP1v Xa5ErNLIxZvBgBbsc/AurldrqjPeCeD48fgmKA4Yfm8TvI6zbu45cekSitbr+KNTVyyI gsYcSAgkBcvjOyiDZvyVxG5rUQI5vXjc4ochI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KZ0rdIE6oyxeBvjCA2IgzXi6b4ZRTWVp5EH7AlicXx3zhj7Hcv6bAI6eLXJGgH/aqv zTChGYNtYfygnsM+b3QWkxbMkAmmSZel/20dZWcezrOl0iRWYKOJAfzL/mgakBwWCYHs 6LUmFrlJNJaXAlQqIfjswT/v4pUfAtfA0GILU= MIME-Version: 1.0 Received: by 10.90.91.17 with SMTP id o17mr5920985agb.99.1280852451390; Tue, 03 Aug 2010 09:20:51 -0700 (PDT) Received: by 10.231.148.209 with HTTP; Tue, 3 Aug 2010 09:20:49 -0700 (PDT) Date: Tue, 3 Aug 2010 21:50:49 +0530 Message-ID: From: Hari Narayanan To: nmrg@ibr.cs.tu-bs.de Content-Type: multipart/alternative; boundary=0016361e87ce5ff6da048cedb39d X-Virus-Scanned: clamav-milter 0.96.1 at salvator X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, SPF_PASS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on salvator.ibr.cs.tu-bs.de X-Mailman-Approved-At: Tue, 03 Aug 2010 23:06:10 +0200 Subject: [nmrg] SNMP OID Compression X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 16:20:55 -0000 --0016361e87ce5ff6da048cedb39d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I have been working on the OID compression for the last few months. The objective of my work is to understand the overall benefit of it. If the OI= D Compression is simple then it could reduce the management traffic, improve the response time, and more crucially reduce the CPU cycles required at the Agent side. In certain cases a single compressed request-response can do th= e job of 3 request-response. OID Compression has been already discussed in two drafts =96 *Delta*compression and *Prefix* compression. At present, I have worked on a simple form of prefix compression where all the requested objects are at the same level of MIB tree. First object in the request is fully specified in PDU varbind, rest o= f the objects are specified only with their respective suffix where they differ from the first object. A simple analytical model is developed to understand the potential benefits and their limitations as functions of object depth (in MIB tree), number of objects requested, and their relationship, and object value size. This mode= l has been submitted for review. I am not sure if I can share the content of this paper here; I will find out from the journal where I submitted this work. To continue this investigation, I have also added additional code to Net SNMP 5.5 to support this simplified prefix compression. This enables me to measure code size, image size, response time, bytes saved, and CPU cycles required etc. The additional code required is about 400 lines (including comment and white space). These 400 lines of code are sufficient to enable both agent and application to support OID compression. The agent image is larger by about 4Kbytes. I am yet to measure the response time rigorously, but I notice that for getbulk request with large number of objects the response time is better with OID compression. The code that encodes objid takes less time because it has to code only the suffix part for all but the first object. It is now easy to compare the legacy code with the new code i= n ever aspect. There is only one API function to access and use OID compression. There is also command line option to request OID compression. I am also doing a profiling on a large collection of MIBs (from 250 vendors) to understand how and where OID compression could be taken advantage off. This profiling includes average object depth, average object value size, percentage of table objects, number fixed size object, number o= f variable size objects, maximum depth, etc. I will be more than happy to share the above code and other findings with you if there is interest, let me know. In summary, I see there are benefits with simple but non-trivial effort and no run time overhead. Regards =85 Hari TS Narayanan Netprowise Chennai India --0016361e87ce5ff6da048cedb39d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I have been working on = the OID compression for the last few months. The objective of my work is to underst= and the overall benefit of it.=A0 If th= e OID Compression is simple then it could reduce the management traffic, improve = the response time, and more crucially reduce the CPU cycles required at the Age= nt side. In certain cases a single compressed request-response can do the job = of 3 request-response.

=A0

OID Compression has bee= n already discussed in two drafts =96 Delta compression and Prefix compress= ion. At present, I have worked on a simple form of prefix compression where all = the requested objects are at the same level of MIB tree. First object in the request is fully specified in PDU varbind, rest of the objects are specifie= d only with their respective suffix where they differ from the first object.

=A0

A simple analytical mod= el is developed to understand the potential benefits and their limitations as functions of object depth (in MIB tree), number of objects requested, and t= heir relationship, and object value size. This model has been submitted for revi= ew. I am not sure if I can share the content of this paper here; I will find ou= t from the journal where I submitted this work.

=A0

To continue this invest= igation, I have also added additional code to Net SNMP 5.5 to support this simplified prefix compression. This enables me to measure code size, image size, respo= nse time, bytes saved, and CPU cycles required etc. The additional code require= d is about 400 lines (including comment and white space). These 400 lines of cod= e are sufficient to enable both agent and application to support OID compression.= The agent image is larger by about 4Kbytes.=A0 I am yet to measure the response time rigorously, but I notice that = for getbulk request with large number of objects the response time is better wi= th OID compression. The code that encodes objid takes less time because it has= to code only the suffix part for all but the first object. It is now easy to c= ompare the legacy code with the new code in ever aspect. There is only one = API function to access and use OID compression. =A0There is also command line option to request OID compression.

=A0

I am also doing a profi= ling on a large collection of MIBs =A0(from 2= 50 vendors) to understand how and where OID compression could be taken advanta= ge off. This profiling includes average object depth, average object value siz= e, percentage of table objects, number fixed size object, number of variable s= ize objects, maximum depth, etc.

=A0

I will be more than hap= py to share the above code and other findings with you if there is interest, let = me know.

=A0

In summary, I see there= are benefits with simple but non-trivial effort and no run time overhead.

=A0

Regards =85 Hari TS Nar= ayanan


Netprowise

Chennai

India=A0

--0016361e87ce5ff6da048cedb39d--