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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 5 Dec 2002 17:49:04 +0100

I believe so: RFC3304

Bert 

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: donderdag 5 december 2002 16:18
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: SNMPv3 as MIDCOM protocol: Opinions?
> 
> 
> 
> >>>>> Martin Stiemerling writes:
> 
> Martin> as you may have heard: the MIDCOM WG is currently doing a
> Martin> protocol evaluation which protocol to use as the MIDCOM
> Martin> protocol. SNMPv3 is amongst these candidates (diameter,
> Martin> cops(-pr), megaco).  Would you strongly recommend to use
> Martin> SNMPv3 as the MIDCOM protocol without having a bad feeling?
> 
> Feeling is one dimension in a multi-dimensional space. And we all know
> that SNMP has a reputation which is kind of special.
> 
> Anyway, it usually makes sense to also look at the functional
> requirements and the features offered by a protocol if you are not
> completely driven by feelings. Are the MIDCOM requirements spelled out
> somewhere?
> 
> /js
> 
> -- 
> Juergen Schoenwaelder    
> <http://www.informatik.uni-osnabrueck.de/schoenw/>
> 
> 
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Harrington, David" <[email-masked]>
Date: Thu, 5 Dec 2002 11:54:24 -0500

Hi,

Message #1: As SNMPv3 co-chair.

Let me inform the SNMPv3 working about the fact that SNMP has been proposed as a candidate for the Middlebox Communications protocol. This has been mentioned on the mailing list in the past.

RFC3303 and 3304 describe the MIDCOM architecture and requirements.

The evaluation is being done against a checklist of requirements specified in RFC3304.
An evaluation of SNMPv3 versus MIDCOM requirements, done by Juergen Quittek and I, can be found in draft-ietf-midcom-protocol-eval-06.txt.

Juergen did an earlier evaluation of SNMP (all versions) in draft-quittek-midcom-snmp-eval-00.txt

It would be helpful if the people in the WG reviewed the requirements and analyses and contributed any comments to the process.

---
David Harrington            
[email-masked]           
co-chair, IETF SNMPv3 WG

> Sent: Thursday, December 05, 2002 10:18 AM

---

From: Scott Bradner <[email-masked]>
Date: Fri, 6 Dec 2002 08:22:36 -0500 (EST)

> Given the information collected during the IAB nm-ws from operators showing
> that SNMP isn't used for configuring much of anything, I would strongly
> object to removing COPS-PR from consideration. 

I think the wrong mesage is being understood here - it is not that
operators don't use SNMP per se - its that operators do not use any
configuration protocol of this type - they use command line and 
expect scripts

i.e., there is no indication that the operators who do not use SNMP 
would be interested in using COPS-PR 

COPS-PR and SNMP should be discussed on their merits not on
what operators may or may not do with SNMP (or COPS-PR)

Scott

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 6 Dec 2002 09:30:20 -0600

Juergen,

I should let Melinda respond, but I'll at least reply as to how I understand
the process and current charter (along with some of my own opinions).  My
understanding is that the WG must first come to consensus that none of the
protocols that have been evaluated are suitable before we can move to the
next step. Realistically when we started the process, we could only cover
the protocols for which we had volunteers to do the evaluation.  

Start of my opinions: If you're suggesting we go through another round of
evaluating existing protocol proposals, then I'd have to disagree as I don't
think we've honestly accomplished much over the past 9 months except to
prove that there are a wide range of opinions and views on which protocol
best fits the problem domain. We don't have any metrics by which to exclude
any of the protocols other than the (hopefully) educated opinions and WG
concensus.  Unless we define and prioritize some metrics for making a
selection or some of the given protocol defenders just give up, I can't see
us ever agreeing to selecting one of the 4 remaining protocols, although I
think we'd get the least objections to the removal of megaco from
consideration. My opinion is that we're never going to agree that only one
of the remaining protocols is suitable as there appear to be very strong
supporters for at least 2 of them. 

The current charter states that "In the unlikely case that one is not found
to be suitable, the working group will undertake development of a new
protocol."  

Perhaps we need to discuss amending the charter to deal with the case that
one or more are found to be suitable, but not ideal.  They have all
shortcomings and issues, which we've endlessly debated as to whether they're
minor or major, with applicability to the MIDCOM framework and/or
requirements.

Mary. 

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]]
Sent: Friday, December 06, 2002 9:09 AM
To: Barnes, Mary [NGC:B602:EXCH]; 'Durham, David'; [email-masked]'
Subject: RE: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions?

Mary,

-- Mary Barnes wrote on 06 December 2002 08:38 -0600:
> Dave,
>
> With Regards to your PS:
>> PS. Where is XML over HTTP or BEEP in the consideration? That's the
>> direction the nm-community seems to be going these days.
>
> As stated in the protocol evaluation document, only the protocols put
forth
> at the time this process began (March/April timeframe) were considered.
> There were no volunteers for the evaluation to inclue XML over HTTP or
BEEP,
> thus they're out of scope for this discussion.

So, you say even if someone showed that XML over HTTPS is the perfect
solution, the working group would ignore it?

    Juergen

> Regards,
> Mary.

---

From: "Moisand, Jerome" <[email-masked]>
Date: Fri, 6 Dec 2002 10:31:23 -0500

I think I made that clear in previous e-mails, but just for clarity sake...

As an individual NOT being one of the authors of the COPS evaluation, I
agree with Dave and strongly object to remove COPS/COPS-PR from
consideration.

Personally, in addition to the various points emphasized in the protocol
assessment document and the (excellent) point made by Dave, my main line of
reasoning is to think to a bigger picture, and to add that we should:

a) not exclude the stateful-policy-server-oriented architectures that I
mentioned before (either driven by off-path signaling -ala SIP- or by
in-path signaling -ala RSVP/NSIS-)

b) allow the dynamic setting of middlebox rules to include not only nat/fw
rules, but also Diffserv/QoS rules (for which COPS/COPS-PR and the PIBs
mentioned by Dave can be leveraged on)

This being said, I also think that allowing COPS as a possible answer does
not necessarily imply to exclude other solutions which certainly have their
own distinct value (e.g. SNMPv3). 

Tx
Jerome

-----Original Message-----
From: Durham, David [mailto:[email-masked]]
Sent: Thursday, December 05, 2002 5:33 PM
To: [email-masked]'
Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions?

Given the information collected during the IAB nm-ws from operators showing
that SNMP isn't used for configuring much of anything, I would strongly
object to removing COPS-PR from consideration. The directionality of
connection establishment for COPS-PR is easily circumvented by running a
dual mode PEP/PDP at the middlebox. Also, IPSP functionality, DiffServ,
Access Control, and Framework PIBs are all there at the wgs disposal. It
seems to me to be the perfect match.

-Dave

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 6 Dec 2002 10:47:56 -0500

My bad feeling?  Performance.

I can see SNMPv3 working for a residential or SOHO gateway, where there will be a few transactions per day.

I might be able to see SNMPv3 working for a small enterprise gateway, where there will be a few transaction per hour.

I can't imagine using SNMPv3 SETs for a large enterprise or inter-service provider gateway, where there will be a number of transactions per minute.  We've done the math, and you need a LOT of processing power to support such a rate.

> From: Martin Stiemerling [mailto:[email-masked]]
> Sent: Thursday, December 05, 2002 9:24 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [midcom] SNMPv3 as MIDCOM protocol: Opinions?
> 
> 
> [please keep me in the recipient list, since I'm not subscribed to 
> snmvp3 list]
> 
> Hi,
> 
> as you may have heard: the MIDCOM WG is currently doing a protocol 
> evaluation which protocol to use as the MIDCOM protocol. SNMPv3 is 
> amongst these candidates (diameter, cops(-pr), megaco).
> Would you strongly recommend to use SNMPv3 as the MIDCOM protocol 
> without having a bad feeling? Actually there are only a few 
> pro and cons 
> discussed so far.
> 
> Thanks in advance
> Martin

---

From: "Harrington, David" <[email-masked]>
Date: Fri, 6 Dec 2002 13:26:29 -0500

Hi,

Let me respond as an evaluator, as SNMPv3 WG author/co-chair, and as a vendor.

As an evaluator, I did not come into the evaluation process as a proponent of a protocol solution. I entered the process because I was asked by the O&M AD to verify that the document was factually accurate, and I found that there were some factual inaccuracies in the representation of SNMP capabilities. As an evaluator, I care that SNMPv3 is factually represented in this evaluation, but I don't care whether SNMPv3 is chosen as the MIDCOM protocol. 

As an author of SNMPv3, and co-chair of SNMPv3 WG, obviously it is always nice to see one's protocol chosen, so I cannot claim complete impartiality. But I also do not see MIDCOM as ever becoming the "killer app" that will help justify SNMP as a standard protocol. SNMPv3 is already full standard, and SNMP is already well justified for its troubleshooting and monitoring functionality, and arguably for its ability to create and modify configurations of specific functionality. So from this perspective I don't care if SNMPv3 becomes the MIDCOM protocol, and I don't think anybody else in the SNMPv3 community cares a great deal either (I am copying this message to the SNMPv3 WG so anybody who disagrees can respond).

As a vendor, I don't care and I do care. My company produces network equipment that includes firewalls and NAT and IDS functionality, and other features that could benefit from a standard MIDCOM solution. As a vendor, we have no requirement that we use what this WG selects as the MIDCOM protocol, but if the IETF produces a useful standard that does not cost us much to support, we will likely implement the standard. I think it unlikely the market cares which is selected; our customers merely want us to produce something that solves their problems. So for those reasons, I do not care whether SNMPv3 becomes the MIDCOM protocol.

The issue to a vendor is largely one of cost of implementation. We already support SNMPv3 and RADIUS, and we will probably support Diameter as an upgrade to RADIUS if our customers demand it (which so far they do not). Enterasys will probably never support COPS/PR or MEGACO. We already need to deal with the difficulties of balancing security across SNMPv3 and RADIUS (and other protocols), and the problems of balancing security across multiple protocols are significant. Adding an unnecessary protocol to our mix, and addressing the resulting combinatorial security concerns, would be very expensive. We would need to pass on those costs to our customers, who would prefer not to suffer price increases and not to have to learn new protocols to manage their networks when existing protocols could have been used. Therefore, as a vendor, I would much rather see the WG select a protocol that I already need to support and secure anyway, since it would make delivering product easier, and!
 would not cause price increases in our products. For those reasons, I would favor SNMPv3 first, and Diameter second.

David Harrington
Network Management Architect
Office of the CTO
Enterasys Networks

> From: Melinda Shore [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 12:13 PM
> To: Juergen Quittek
> Cc: Mary Barnes; 'Durham, David'; [email-masked]'
> No - we absolutely don't value/privilege process over
> technical soundness.  However, we do need to push on ahead
> if we're going to get our work done, and I'm hoping against
> hope that people will start showing greater willingness to
> compromise.  Each of us needs to think hard about what the
> consequences would be for the working group (not our
> employers) if midcom were to select a protocol other than
> the one we individually favor.  Consensus-based decision
> making simply does not work - at all - in the face of
> inflexibility and rigidity on the part of participants.
> 
> Melinda

---

From: "Harrington, David" <[email-masked]>
Date: Fri, 6 Dec 2002 15:23:42 -0500

Hi Eric,

You've done the math; can you share the math with us?
I'd like to see the data to back up your assertion.
Did you do comparable trials with the other protocols, whose data you could share?
That data could be very valuable for the evaluation process.

The amount of CPU processing will be dependent on a large number of variables, such as how many varbinds, which varbinds, what types of changes are being requested in the underlying implementation, which security model and mechanisms you choose, how many entries are in the tables you need to perform lookup on, implementation decisions about lookup algorithms, and so on. I'd be interested in seeing how much of the overhead is in the SNMP and how much is related to the non-SNMP aspects of the transactions and I'd like to see data for the other candidates as well, so we have real data to work with.

dbh

> From: Eric Burger [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 10:48 AM
> To: Martin Stiemerling
> Cc: [email-masked]
> Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?
> 
> 
> I can see SNMPv3 working for a residential or SOHO gateway, 
> where there will be a few transactions per day.
> 
> I might be able to see SNMPv3 working for a small enterprise 
> gateway, where there will be a few transaction per hour.
> 
> I can't imagine using SNMPv3 SETs for a large enterprise or 
> inter-service provider gateway, where there will be a number 
> of transactions per minute.  We've done the math, and you 
> need a LOT of processing power to support such a rate.
>

---

From: "Harrington, David" <[email-masked]>
Date: Fri, 6 Dec 2002 17:09:36 -0500

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Friday, December 06, 2002 4:50 PM
To: Chris Elliott
Cc: Wijnen, Bert (Bert); Harrington, David; [email-masked]
(E-mail)

I think you can factor out crypto of any stripe
because it's a requirement regardless of which
layer you implement it at.

That said: assuming the number of round trips is
identical for SNMP vs other contenders, this "too
expensive" argument strikes me as yet another
rehash of the ASN.1/ABNF crusades. Is it that time
of year again?

	Mike

Chris Elliott writes:
 > I think we need to define what we're talking about here.
 > 
 > SNMPv3 noAuthNoPriv shouldn't be any more expensive than any other
 > version, but obviously doesn't give you any increased security.
 > 
 > AuthNoPriv will be somewhat more expensive, but my experience (no, I
 > haven't benchmarked it) is that the cost is relatively low and is "good
 > enough" security for many environments.
 > 
 > AuthPriv will be the most expensive and I agree that, without
 > support for hardware encryption (and I don't know of anyone that has
 > implemented that--does anyone?) will be quite expensive.
 > 
 > It would be very interesting to benchmark the three on a representative
 > sample of equipment. I'd love to do this, but my current load, combined
 > with the conditions here now (no power at home or work, working off of
 > laptop battery and recharging in the car, and dialup access only, with no
 > schedule for power restoration yet) make it difficult to predict if I
 > could get to this anytime soon.
 > 
 > Chris.
 > 
 > On Fri, 6 Dec 2002, Wijnen, Bert (Bert) wrote:
 > 
 > > 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.
 > >
 > > Thanks,
 > > Bert
 > >
 > > > From: Harrington, David [mailto:[email-masked]]
 > > > Sent: vrijdag 6 december 2002 21:10
 > > > To: [email-masked] (E-mail)
 > > > Subject: FW: [midcom] SNMPv3 as MIDCOM protocol: Opinions?
 > > >
 > > >
 > > > Hi,
 > > >
 > > > Does anybody have any stats regarding the processing power
 > > > required for SNMPv3?
 > > >
 > > > dbh
 > > >
 > Chris Elliott  CCIE# 2013       |         |
 > Customer Diagnostic Engineer   |||       |||
 > RTP, NC, USA                  |||||     |||||
 > 919-392-2146              .:|||||||||:|||||||||:.
 > [email-masked]        c i s c o S y s t e m s

---

From: "Harrington, David" <[email-masked]>
Date: Fri, 6 Dec 2002 17:09:23 -0500

-----Original Message-----
From: Chris Elliott [mailto:[email-masked]]
Sent: Friday, December 06, 2002 4:29 PM
To: Wijnen, Bert (Bert)
Cc: Harrington, David; [email-masked] (E-mail)
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?

Chris.

---

From: "Harrington, David" <[email-masked]>
Date: Mon, 9 Dec 2002 13:09:55 -0500

Another note on SNMPv3 performance.
Apparently BMC has had no problems with SETs except due to implementation choices in a master/subagent implementation.

dbh

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

Hi -

> Message-ID: <[email-masked]>
> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: "Harrington, David" <[email-masked]>,
>         "[email-masked] (E-mail)" <[email-masked]>
> Date: Fri, 6 Dec 2002 22:05:55 +0100 
> 
...

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-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Harrington, David" <[email-masked]>
Date: Tue, 10 Dec 2002 14:04:15 -0500

Wes posted yesterday stating that it was messages per second.

dbh

> From: Bob Penfield [mailto:[email-masked]]
> Sent: Tuesday, December 10, 2002 1:30 PM
> To: Harrington, David; [email-masked]
> 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-masked]
> 
> ----- Original Message ----- 
> From: "Harrington, David" <[email-masked]>
> > From: Wes Hardaker [mailto:[email-masked]]
> > 
> > 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

---

From: "Cedric Aoun" <[email-masked]>
Date: Tue, 10 Dec 2002 20:40:28 +0100

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-masked]]
Sent: 10 December 2002 20:04
To: Bob Penfield; [email-masked]
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?

dbh

---

From: "Pyda Srisuresh" <[email-masked]>
Date: Tue, 10 Dec 2002 16:07:46 -0800

Resending…

-----Original Message-----
From: Pyda Srisuresh [mailto:[email-masked]]
Sent: Tuesday, December 10, 2002 3:04 PM
To: Harrington, David; [email-masked]
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?

You are right. There is no minimum requirement on min. no. of transactions
per se.
However, it is clear that the protocol should have no inherent issues with
scaling.

Couple of questions.

1.       I believe, security is the main distinction between v2 and v3 of
SNMP.
SNMPv3 is being suggested as the MIDCOM protocol because of it security
suit.

I believe, the trust level and the ensuing rev of SNMP should be the left to
the
choice of the customers/enterprises that house the middlebox, even as IETF
recommends SNMPv3 as the preferred protocol choice.

2.       Let us say, SNMP is chosen as the MIDCOM protocol of choice.
Several host stations acting as MIDCOM agents could simultaneously be
running as SNMP server applications, right.

Are there any scaling issues with the middlebox interfacing with multiple
SNMP servers simultaneously. How will the traps work in the multi-server
scenario?

Thanks.

Cheers,
suresh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Harrington, David
Sent: Tuesday, December 10, 2002 12:40 PM
To: [email-masked]
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

---

From: "Cedric Aoun" <[email-masked]>
Date: Fri, 13 Dec 2002 11:53:34 +0100

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-masked]]
Sent: 10 December 2002 23:58
To: Harrington, David; [email-masked]
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-masked]

----- Original Message -----
From: "Harrington, David" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, December 10, 2002 3:40 PM
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?

Hi Cedric,

dbh

 -----Original Message-----
From: Cedric Aoun [mailto:[email-masked]]
Sent: Tuesday, December 10, 2002 2:40 PM
To: Harrington, David; Bob Penfield; [email-masked]
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?

Thanks
Cedric

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

dbh

> From: Bob Penfield [ mailto:[email-masked]]
> > From: Wes Hardaker [ mailto:[email-masked]]
> >

---

From: "Harrington, David" <[email-masked]>
Date: Fri, 13 Dec 2002 09:26:53 -0500

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-masked]]
Sent: Friday, December 13, 2002 5:54 AM
To: 'Bob Penfield'; Harrington, David; [email-masked]; [email-masked]'
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: "Harrington, David" <[email-masked]> 
To: <[email-masked]> 
Sent: Tuesday, December 10, 2002 3:40 PM 
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? 

Hi Cedric,

---

From: "Harrington, David" <[email-masked]>
Date: Fri, 13 Dec 2002 10:04:21 -0500

Hi Cedric,

How well SNMP will be able to perform the specific transactions depends a great deal on how the mibs are designed. I, an experienced SNMP solutions designer, believe SNMP will be able to handle the semantic requirements. I and other experienced SNMP developers believe that in a well-designed mib solution, supporting transactions between two reasonably well-implemented snmp engines, you will not have a performance problem.

I have already commented that the semantics requirements should be modified to align itself with the best current practices of the protocol selected, whichever one that may be. Doing a purely theoretical analysis of the efficiency of implementing according to semantic requirements that are not aligned with best current practices for the protocol seems like a gigantic waste of time. 

I believe there are so many variables involved, that we cannot answer this question using theory alone. I believe network latency will have a larger impact on performance than the SNMP operations involved. We don't know yet which snmp operations would be involved. We don't know how those operations map to underlying implementation details. and on and on and on...

We have no real data to work with; we cannot prove nor disprove any claims that any of the protocols will or will not meet performance requirements.

Forgive me for being blunt. I have a real job, and responding to a bunch of theoretical analyses requires a lot of my time, and I don't feel it is my responsibility to keep having to respond to new ill-conceived requirements made up on the fly. 

If the WG wants to consider the theoretical efficiencies of the different protocols, when used in a manner that is not aligned with best current practices for the protocols, I say "go ahead - have a good time". If you want meaningful analyses, you need to agree on your requirements, then do comparisons of the protocols, and compare well-designed solutions, and you should use REAL data not theoretical data.

I'm not sure how long the industry will wait for you though. 

dbh

----- Original Message ----- 
From: "Harrington, David" <[email-masked]> 
To: <[email-masked]> 
Sent: Tuesday, December 10, 2002 3:40 PM 
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions? 

Hi Cedric,

---

From: "Harrington, David" <[email-masked]>
Date: Fri, 13 Dec 2002 10:14:03 -0500

Hi,

RFCs 1906-1907 and RFCs 2570-2576 describe SNMP behaviors. I recommend you read them. There are also numerous books available that are easier to read (although some have known inaccuracies).

SNMP SET behavior is clearly defined in RFC1905. It is basically the same behavior SNMP has always followed for SETs since 1988. SNMP SETs are always atomic. The whole message succeeds or the whole message fails. Error codes are returned; a pointer shows the managed object that caused the problem.

dbh