RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?

Just a monitor's comment :-)

I find that SNMP SETS are slow because of the fact that you can
only send as many OID/value objects as can fit into 1024 byte packet(no-defrag).
Also since SNMP doesn't support packet windowing on the SET side (no setbulk or TCP/windowing)
you basically have to wait for a SET packet to be fully processed by the receiver
before moving on to the next batch of SET objects. This really slows things down.

jay knotts

-----Original Message-----
From: Randy Presuhn [mailto:[email protected]]
Sent: Friday, December 06, 2002 8:31 PM
To: [email protected]
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?


Hi -

> Message-ID: <F74EF3316D9CD4118D8400508BAEDCAA07A5A024@nl0006exch001u.nl.lucent.com>
> From: "Wijnen, Bert (Bert)" <[email protected]>
> To: "Harrington, David" <[email protected]>,
>         "[email protected] (E-mail)" <[email protected]>
> Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?
> Date: Fri, 6 Dec 2002 22:05:55 +0100 
> 
> I don;t have the stats, but remembering the implementation I did
> a few years back, I see no problem with a number of transactions
> per minute. Many SETs per second might become problematic,
> depending on the complexity of the SETs and what a SET
> would cause in underlying work and such.
...

My recollection from several years ago was that for
single-varbbind requests in a noAuth/noPriv configuration,
we were geting about 100 per second on ancient hardware using
SMUX, and proportionately less (due to greater overhead)
with AgentX.  YMMV, but I have to agree with Bert that SET
throughput has not been an issue in general.  There are two
specific cases where I HAVE seen it become an issue:

    1) high latency (due to long links or processing time)
       subagents

    2) incorrect  SMUX/Agentx connection TCP options.
       (TCP_NODELAY is especially important) Some packet
       exchange patterns would cause "stalls" while one
       side or the other was waiting to put more into an
       output buffer.  Flow patterns like ><> ><> or ><<><
       ><<>< were particularly prone.  setsockopt() fixed
       this permanently.  (Thanks Bobby Krupczak!)

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  SJC-1.3141
 [email protected]  2141 North First Street
 Tel: +1 408 546-1006   San Jose, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------