Subject: RE: why i should like pibs

From: "Durham, David" <[email-masked]>
Date: Tue, 19 Mar 2002 01:12:18 -0800

The Industry Realities COPS-PR & its PIBs Address:
Dynamic Edge vs. Static Core - 
 * COPS exists to address the Dynamic Provisioning needs of the Network's
Edge.
     - Access Control Requests (from a variety of signaled protocols)
     - Controlled allocation of network resources
     - Micro-flow to aggregate traffic characterization
     - QoS
     - Security
     - Tunneling
     - Usage feedback
 * Meanwhile the Network Core tends to be static and deal with traffic
aggregates being mainly concerned with routing & moving packets as fast as
possible with minimal overhead.

... And ... It's a Multi-protocol World, COPS-PR is the Integrator. It
closes the loop by tying together diverse signaling and provisioning
mechanisms. Access control/session initiation/QoS requests come in and
dynamically allocating/provisioning device resources based on policy goes
out. Finally policy usage feedback closes the loop.

Qualitative:

* Enables entirely new classes of dynamic and integrated services that would
not be possible without it.
* It can integrate resource allocation and control for pretty much every
in-band + out-of-band signaling protocol AND pretty much any form of
resource Provisioning (eg. DiffServ).
* BIG and RELIABLE TRANSACTIONS with rollback, failover and synchronization
built-in.
* It just works. It pulls outsourcing and provisioning together in one nice
state-driven solution. Stateful means it maintains the state of all sessions
on a device at all times as well as the resources they consume.
* Completely event driven.
* Device capabilities reporting is integral to the PIBs. Everything the
device can syntactically parse and semantically do is precisely yet
generically reported to the PDP. 
* Implementations are easy... COPS-PR sends you all your data in one
complete reliable transaction. SNMP can throw all your attributes into a
blender, so your implementation needs to be able to unscramble what comes
out the other side, loss and all.
* Three levels of easily understandable security.
* New and improved data model and definition language with a consistent
theme of a data-flow throughout. Enables better and improved tools over SNMP
to make the job of implementers and users even easier!
* Solves the multi-manager problem, data instances cannot overlap managers
in COPS-PR and, thus, managers cannot step on one-another's toes.
* NO row-status, owner description strings, storage-types, etc. to deal with
AT ALL... And good riddance.

Quantitative:
* It can do one RTT provisioning based on outsourced events = well within
call-setup time = as fast as is possible between two remote systems.
* Intrinsically 10x more efficient on the wire than SNMP (1/10th the data to
xfer) for e.g. the ever common DiffServ IP-filter tables. Efficiency
multiplies with the more attributes you have in a row.
* Faster, better & more. Change 10000 DiffServ Filter+meter+action entries
through a T1 line with a 10msec RTT for 48byte packets: 
SNMP=((10000*8*498)/1540000)+((2*10000)/100)=226 Seconds.
COPS=((10000*8*(498/10))/1540000)=2.59 Seconds.
Is 100x improvement sufficiently better? And the multiple goes up with the
more data you xfer. ... adding bandwidth doesn't help, it's that dang RTT.

-Dave 

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Monday, March 18, 2002 6:13 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: why i should like pibs
> 
> wearing my iesg hat but being just a stupid operator, i am trying to
> understand the pib/mib controversy.  fyi, i currently use snmp heavily
> for monitoring devices on my network.  i configure using large db-driven
> code and spew text-based cli to the devices.
> 
> let's assume i want to take the leap to a binary, as opposed to textual,
> configuration language.  i.e. for some reason(s) [which we will PLEASE
> NOT discuss here] i decide to move from pushing text-based cli configs
> out to pushing a binary format.
> 
> hence, i would have to push my vendors to implement snmp/cops writes for
> all configuration aspects of all devices.  this would be big cost for
> both me and for my vendors.
> 
> why would cops/pibs be significantly better (remember it has to replace
> my current investment, so it can not be 'just as good') than snmp/mibs?
> 
> randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Mar 2002 11:40:04 +0100

>>>>> 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/>