RE: SNMPv3 as MIDCOM protocol: Opinions?

"Harrington, David" <[email protected]>
Newsgroups gmane.ietf.midcom,gmane.ietf.snmpv3
Message-ID <6D745637A7E0F94DA070743C55CDA9BA4892BD@NHROCMBX1.ets.enterasys.com>
Hi,

First, as co-chair of SNMPv3, I would like to set some guidelines on which messages should be copied to the snmpv3 mailing list and which should not.

I don't object to messages sent to the snmpv3 mailing list seeking input from SNMP-knowledgeable people about the capabilities of snmpv3. I encourage any interested SNMP-ers to join the midcom mailing list to participate.

However, this WG is still involved in debates over just what the midcom requirements should be. That discussion is a topic for the midcom wg, not the snmpv3 wg. 


dbh
-----Original Message-----
From: Cedric Aoun [mailto:[email protected]]
Sent: Friday, December 13, 2002 5:54 AM
To: 'Bob Penfield'; Harrington, David; [email protected]; '[email protected]'
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?


Bob thanks for giving a practical example, have a minor comment on the calculation we might need 5 transactions if 
we follow the reservation model prior to enabling the policy rule (I'm referring to the protocol semantics document). 
David, I agree that at this point looking at the number of messages per sec won't take us anywhere as we don't have SNMPv3, DIAMETER or COPS-PR code running the required extensions (in what ever form of extension) so comparing performance figures of existing implementations doesn't help (unless people have sometime to write some code for all the evaluated protocols and we do a bake off).
Instead we could look how SNMPv3 can match MIDCOM pseudo messages documented in the protocol semantics (I already raised that previously).
It would be interesting as well to understand the aggregation of commands (several policy rules installed or taken out without being in the same policy group) and see if in case there are some errors in the message how SNMP behaves (i.e. discard the whole request and send an error flag, or accept some of the commands and reply back with success for some commands and list the ones that have failed).
Thanks 
Cedric 


-----Original Message----- 
From: Bob Penfield [mailto:[email protected]] 
Sent: 10 December 2002 23:58 
To: Harrington, David; [email protected] 
Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions? 


Assume a VOIP application using a middlebox handling a 1-Gigabit link. If 
you filled that link with G729-codec (8kbs/20ms samples) VOIP calls, you'd 
have 41,600 calls (using a bandwidth calculator I found on the web). If you 
assume a 3-minute call length, a continuously full 1-gigabit link would have 
a call rate of about 230 calls per second. At minimum, each call requires 2 
transactions (open pinhole & close pinhole). That's 460 transactions per 
second. If it is a NAT box, and we might need to add a "reserve binding 
transaction", that's 690 transactions per second. If you had two 1-gigabit 
links, that's 1380 transactions per second. 
Hope that helps. 
cheers, 
(-:bob 
Robert F. Penfield 
Chief Software Architect 
Acme Packet, Inc. 
130 New Boston Street 
Woburn, MA 01801 
[email protected] 
----- Original Message ----- 
From: "Harrington, David" <[email protected]> 
To: <[email protected]> 
Sent: Tuesday, December 10, 2002 3:40 PM 
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? 


Hi Cedric, 
I agree that the numbers don't say much without knowing what you're 
measuring and what you're comparing to. 
Are there specific requirements about the number of transactions per minute 
that must be met to qualify? I didn't see any in the requirements documents. 
Eric raised the issue the other day, saying that the requireent was for a 
number of transactions per minute. Even if it took multiple request/reply 
pairs to perform a transaction, at ~500 SET messages per second I don't see 
that SNMPv3 would have a problem. 
I fear that this is an unnecessary rathole. There are no identified minimum 
requirements. There are no comparative numbers for the other protocols 
available. The numbers by themselves are meaningless, except to show that 
SNMPv3 throughput has not been found to be a problem in other environments. 
dbh 
 -----Original Message----- 
From: Cedric Aoun [mailto:[email protected]] 
Sent: Tuesday, December 10, 2002 2:40 PM 
To: Harrington, David; Bob Penfield; [email protected] 
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? 



In order to comment on these performance figures we need to understand if in 
order to install a policy rule we need 
more than a pair of messages (set and set response), I don't know if we got 
closure on the command aggregation or not without any proprietary hacks 
(sorry got lost in all the threads). 
The figures could be more representative if we could use the NAT MIB and see 
how the figures are affected. 
Is it possible to get the figures on the MIDCOM agent side (SNMP manager)? 
The next step is to see how to match this to real application sessions per 
sec that people expect this protocol to deliver on their boxes. 
We might get some agreement on the expected performance by saying that 6 or 
8 pairs of MIDCOM messages (a pair is made of a request and reply) are 
required (between policy rule installation and policy rule deletion), in an 
average hold time of 1 min (let's say this is the worst case) this takes us 
to 16 MIDCOM messages (SNMP messages? ref to my note above) per mins for 
every application session (VoIP session, RTSP etc ...). 
After that, everyone can see if SNMPv3 meets their performance expectation 
(obviously without doing any implementation hacks, we're talking of a 
standard SNMPv3 stack). 
Thanks 
Cedric 



-----Original Message----- 
From: Harrington, David [ mailto:[email protected]] 
Sent: 10 December 2002 20:04 
To: Bob Penfield; [email protected] 
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? 


Wes posted yesterday stating that it was messages per second. 
dbh 
> -----Original Message----- 
> From: Bob Penfield [ mailto:[email protected]] 
> Sent: Tuesday, December 10, 2002 1:30 PM 
> To: Harrington, David; [email protected] 
> Subject: Re: [midcom] SNMPv3 as MIDCOM protocol: Opinions? 
> 
> 
> Are those numbers transactions per second? 
> 
> cheers, 
> (-:bob 
> 
> Robert F. Penfield 
> Chief Software Architect 
> Acme Packet, Inc. 
> 130 New Boston Street 
> Woburn, MA 01801 
> [email protected] 
> 
> ----- Original Message ----- 
> From: "Harrington, David" <[email protected]> 
> > -----Original Message----- 
> > From: Wes Hardaker [ mailto:[email protected]] 
> > 
> > Just for kicks, I ran 10000 requests of various kinds against the 
> > Net-SNMP stack (which is not a well optimized stack compared to 
> > the commercial vendors) and timed the results.  This was on 
> a 233 PIII 
> > laptop which was not idle by any means, so take the numbers with a 
> > grain of salt.  MD5 and DES were used for auth and priv. 
> > 
> > sysContact.0 in the Master agent: 
> > 
> >                        GET    GETNEXT    SET 
> >   AuthPriv            1277    1176       493 
> >   AuthNoPriv          1462    1475       514 
> >   SNMPv1/2c           3769    3467       675 
> > 
> > sysContact.0 in a subagent: 
> > 
> >                        GET    GETNEXT    SET 
> >   AuthPriv             772     596       304 
> >   AuthNoPriv           860     661       355 
> >   SNMPv1/2c           1461    1018       420 
> > 
> > 
> > -- 
> > Wes Hardaker 
> > Network Associates Laboratories 
> > _______________________________________________ 
> > midcom mailing list 
> > [email protected] 
> > https://www1.ietf.org/mailman/listinfo/midcom 
> > 
> 
> 
_______________________________________________ 
midcom mailing list 
[email protected] 
https://www1.ietf.org/mailman/listinfo/midcom 



_______________________________________________ 
midcom mailing list 
[email protected] 
https://www1.ietf.org/mailman/listinfo/midcom
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.