Subject: [Diffserv] RE: why i should like pibs

From: "Durham, David" <[email-masked]>
Date: Wed, 20 Mar 2002 09:52:32 -0800

Actually, I did some pings and found my 10ms RTT was unrealistic. 100ms is
more like it. At 100ms RTT, things get much worse for the SNMP equation for
the configuration example I described:

SNMP=2026 Seconds  (over half an hour!)
COPS=2.59 Seconds

Now we're talking 1000x faster...

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Tuesday, March 19, 2002 2:40 AM
>
> 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.
> 
[Dave] TCP ACKs piggyback on messages going the other way. TCP is quite
efficient in that way. Actually, I think I was far too kind in my
calculations. Just the other day an operator said SNMP implementations can
take hours to update his big BGP tables. Clearly with SNMP, results will
vary. While with COPS-PR, it's the TCP stack that matters, and that makes it
a no-brainer for implementations. Remember also that COPS-PR presents a
transactional model to the user, while SNMP simply provides a get/set
interface, so it's not just an implementation issue; it's a presentation
issue as well.

[Dave] The SNMP example gets far worse when you have to consider the
multiple manager problem. Now you will have to hold each of the 30000 row
status variables until the transaction completes, and reset them thereafter.
In such cases you also will have to constantly check that some other manager
didn't come and munge your configuration. This quickly becomes an
unmanageable situation, and I cannot write an equation that is long enough
to adequately express that problem.

> 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.
> 
[Dave] I disagree. You certainly do get full reusability and extensible data
structures. The reusability is both syntactic and semantic.

> d) State sharing and one manager assumption.
> 
[Dave] One manager for its set of instance data (so there is no danger of
configuration corruption). The COPS-PR protocol supports 64000 managers per
device. 

> 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.
> 
[Dave] By the time you integrate all the COPS-PR features and advancements
into SNMP, you still get COPS-PR, just 5 years too late. But, perhaps the
best reason of all for COPS-PR and PIBs is that you don't have the "SNMP
community process" that you just described.

> 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 ;-).
> 
[Dave]Yes, go to the SMIng WG, that's where the good stuff is being done ;-)

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Mar 2002 11:26:42 +0100

[ Based on Dave Durhams comments, I will update my attempt to
  summarize the major technical contributions of COPS-PR over SNMP.  I
  will do so on the <[email-masked]> only so that we can stop these
  cross posts. Below are just my hopefully final comments on Dave's
  numbers. ]

>>>>> Durham, David writes:

Dave> Actually, I did some pings and found my 10ms RTT was
Dave> unrealistic. 100ms is more like it. At 100ms RTT, things get
Dave> much worse for the SNMP equation for the configuration example I
Dave> described:

Dave> SNMP=2026 Seconds (over half an hour!)  COPS=2.59 Seconds

Dave> Now we're talking 1000x faster...

I probably do not understand your equations. There is the actual
transmission time Tx and the propagation delay Tp. We have

     n = number of filter entries
     m = size of a single filter entry
     s = "speed" of the link
     r = round trip time

If I understand you correctly, you assume:

     Tx_s = (n * m) / s		# SNMP n messages of size m
     Tx_c = (n * m/10) / s	# COPS filters are 10 times smaller

     Obviously: Tx_c = 1/10 Tx_s

You also seem to assume:

     Tp_s = (2 * n) * r		# SNMP sequential one set a time
     Tp_c = 0			# COPS does not need a round trip

In case this is your model (forgive me if I messed it up), I think it
is an over-simplification and the numbers you get out of it do not
impress me that much. (Did you ever calculate how big your TCP window
must be to do your example in one^H^H^Hzero RTT?)

Still I agree (and have ever done so in the past) with the qualitative
statment "COPS-PR is faster due to larger transactions and the TCP
transport in cases the network is running normally".

Dave> Remember also that COPS-PR presents a transactional model to the
Dave> user, while SNMP simply provides a get/set interface, so it's
Dave> not just an implementation issue; it's a presentation issue as
Dave> well.

I never got that into my brain. An SNMP SET is a single transaction
just as a COPS-PR DEC is a single transaction. The difference is just
the message sizes you can use.

/js

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