Re: {42} OID Compression

Aleksey Y Romanov <ralex@world.std.com> Sat, 07 January 1995 19:36 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02886; 7 Jan 95 14:36 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02882; 7 Jan 95 14:36 EST
Received: from relay.tis.com by CNRI.Reston.VA.US id aa08759; 7 Jan 95 14:36 EST
Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma018551; Sat Jan 7 14:10:01 1995
Received: from magellan.tis.com by magellan.TIS.COM id aa08829; 7 Jan 95 14:03 EST
Received: from sol.tis.com by magellan.TIS.COM id aa08825; 7 Jan 95 13:59 EST
Received: from europe.std.com(192.74.137.10) by relay via smap (V1.3) id sma018524; Sat Jan 7 14:01:15 1995
Received: from world.std.com by europe.std.com (8.6.8.1/Spike-8-1.0) id OAA11259; Sat, 7 Jan 1995 14:00:44 -0500
Received: by world.std.com (5.65c/Spike-2.0) id AA10490; Sat, 7 Jan 1995 14:01:04 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Aleksey Y Romanov <ralex@world.std.com>
Message-Id: <199501071901.AA10490@world.std.com>
Subject: Re: {42} OID Compression
To: snmp2@tis.com
Date: Sat, 07 Jan 1995 14:01:04 -0500
In-Reply-To: <199501071608.AA217894891@nsmdserv.cnd.hp.com> from "bok@nsmdserv.cnd.hp.com" at Jan 7, 95 09:08:11 am
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Length: 2147

> > I haven't seen anyone shoot it down.
> 
> Not out-right shoot it down, anyway.

Bob refernced some previous discussion on the subject.
And I just could recall any. May be some kind soul will referesh
my memeory.

> However, I have seen several repsonses questioning the
> bang for the buck, especially with the original proposal.
> The subsequent proposals increase the bang (benefit) but 
> have an even higher buck (cost).  

IMHO, original proposal has practically no cost associated with it,
worst case for subsequent proposals is extra 1.5KB of buffer space
per SNMP thread, and one additional 1.5KB buffer. Extra memory at
this rate does not have to be considered a problem.

Let me explain how I get these numbers. Let us assume that we
have a physical 1.5KB limit on MaxMessage size for particular entity.
Let us assume that our target compression ratio is 3 and 
let us not consider space required for packet header, for a while.
So, roughly speacking in the case we will need two 4.5K mongo
buffers to keep decompressed data and 1.5K buffer to store incoming
compressed packet while they are being processed per SNMP thread and
one 1.5K buffer which will temporarily hold compressed response 
for short period of time of compression and send operation to be
performed and which will be shared by all threads.

Let us compare these layout with that of  SNMP entity able
to communicate uncompressed 4.5K packets: it has to have two
4.5K buffers per SNMP thread. 

Hence the cost of compression in the case is 1.5KB extra per thread
and 1.5KB extra per SNMP entity. BTW, the extra cost does not depend
upon targed compression ratio. And once again it is a worst case.

> I'm not convinced that consensus has been reached either
> for or against this proposal.  One flaw in the process is
> it is difficult to distinquish lack of response as out-right
> support versus undecided (i.e., monitor discussion) positions.
> 
> At best, the call for consensus on this thread may be a bit
> premature.

It seems premature for me too, unless Bob is right and it is established
already that it does not worth discussing at all.

> bok

Aleksey