Re: why i should like pibs

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Durham, David writes:

Dave> * Faster, better & more. 

Very impressive.

Dave> Change 10000 DiffServ Filter+meter+action
Dave> entries through a T1 line with a 10msec RTT for 48byte packets:
Dave> SNMP=((10000*8*498)/1540000)+((2*10000)/100)=226 Seconds.
Dave> COPS=((10000*8*(498/10))/1540000)=2.59 Seconds.  Is 100x
Dave> improvement sufficiently better? And the multiple goes up with
Dave> the more data you xfer. ... adding bandwidth doesn't help, it's
Dave> that dang RTT.

Even with SNMP over UDP, you can stream set requests as long as they
are independent of each other (which I guess is true if you populate a
DiffServ filter table). Since you did not take TCP acks into account,
I would say the second term is in equation (1) is 0 if you are smart
enough. With SNMP over TCP, the difference also boils down to the
reduced OID overhead in COPS-PR, which is probably not that much an
issue on the T1 link. Anyway, I agree with other folks that it is
pointless to redo all the discussions of the past so I better stop
this.

From my perspective, the major technical contribution of COPS-PR over
SNMP is:

a) TCP transport for large transactions when the network is up and
   running.

b) Reduced OID overhead and less degrees of freedom to achieve the same
   thing.

c) Slightly improved data definition language - but nothing which gives
   us real reusable and extensible data structures.

d) State sharing and one manager assumption.

e) Some failover support built into the protoco.

Items a) and b) are technically easy to support in SNMP. The real
problem here is the "SNMP community process" which is in blocking mode
for several years now for various non-technical reasons.

Item c) contains some minor enhancements over SMIv2 but if people want
a really improved data definition language, then the SMIng WG is the
place to go (sure, I am biased on this ;-).

Items d) and e) are more interesting to implement in an SNMP world
since one of the fundamentals in SNMP is the multi-manager assumption.
Sure, one can setup existing SNMP access control to allow only one
manager and one can define notifications to signal state changes - but
this is not hard wired into the protocol (and I guess it will never
be). The same is true for failover handling - it is not part of the
SNMP protocol but can be built around it.  Perhaps one could do
interesting things by actually running SNMP over SCTP, which is
perhaps theoretically much better suited for management purposes than
UDP and TCP...

[Perhaps this is closer to the technical summary Randy asked for.]

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>