Subject: RE: [Diffserv] RSVP vs DiffServ

From: "Yoram Bernet (Exchange)" <[email-masked]>
Date: Fri, 19 Nov 1999 11:16:30 -0800

Hmmm. Istvan - from our discussions at the IETF, it is not clear to me what
fraction of processing overhead you atrribute to *signaling* vs. to
*traffic-handling*. In fact, it seemed to me that the traffic handling
burden is far heavier than the signaling burden. Traditionally, RSVP
triggers per-flow traffic handling. WFQ is commonly used for this. From my
experience, the policing and queuing that ar required for per-flow traffic
handling render the signaling overhead negligible. 

Thus, I would claim that your study is about the scalability of "RSVP
signaling *with* per-flow traffic handling", as opposed to "RSVP signaling".
The distinction is important because, diffserv, as an aggregate form of
traffic handling can be used with per-flow signaling to yield a very
scalable QoS architecture.

I would be interested in seeing the following stats:

Assume a 1 Mbps flow, signaled by RSVP (one signaling message very 30
seconds):
How much processing power per-second is expended on handling RSVP signaling
in the router?
How much processing power per-second is expended on trafic handling the 1
Mbps data flow?

Of course, processing power can be expressed in some normalized, unitless
sense. It's the ratio that is interesting.

Yoram 

> -----Original Message-----
> From: Istvan Cselenyi [mailto:[email-masked]]
> Sent: Friday, November 19, 1999 10:36 AM
> To: [email-masked]
> Cc: Yoram Bernet (Exchange); Albert Manfredi; [email-masked];
> [email-masked]
> Subject: Re: [Diffserv] RSVP vs DiffServ
> 
> 
> Goorah,
> 
> > 	at least this is a topic of discussion which I am interested in
> 
> me too - just before we are moved to diffserv-interest...
> 
> > > > > My description would be that RSVP is thought by some
> > > > not to "scale
> > > > > well" in very large networks,
> > 
> > 	It would clarify things if you could explain 
> "scalability with respect
> > to what?"
> 
> I hope you can find an answer to this in our study about 
> scalability of 
> QoS signaling as of today:
> 
http://soha.ttt.bme.hu/boomerang/public/decides.zip

BR
Istvan Cselenyi

--------------------------------------------------
                Istvan Cselenyi                      
 Telia Research AB           Phone: +46-8-7138173
 Vitsandsgatan 9 B431          Fax: +46-8-7138199          
 S-12386 Farsta            Mobile: +46-70-3228801  
 Sweden        E-mail: [email-masked]
--------------------------------------------------

---

From: "Istvan Cselenyi" <[email-masked]>
Date: Mon, 22 Nov 1999 06:40:33 +1

Hi Yoram,

> *traffic-handling*. 

Our goal was to quantify the scalability of processing _signaling_ 
messages (i.e. load on control plane) as a function of 
* total number of concurrent reservation sessions in the router
* intensity of new reservation attempts (hits per sec).

The control plane performance of QoS signaling is important, since 
(1) that is what end-user applications and network designers are 
facing with (e.g. reservation setup time, maximum # of reservations 
and max. intensity of setups) and
(2) heavy signaling can have a serious impact on handling other 
protocols (e.g. routing, management - if they are not isolated).

As you wrote earlier on this thread, the selection of traffic-
handling approach (per-flow or per-BA) is not directly coupled to 
signaling. Thus the (data plane) processing overhead due to 
conditioning the traffic of reserved flows is also independent from 
the performance of signaling protocol.

> In fact, it seemed to me that the traffic handling

This is true (see below), but another story.

> signaling *with* per-flow traffic handling", as opposed to "RSVP signaling".

Yes, we had to use the per-flow RSVP version, the only one which was 
available. Moreover, we disabled the TC setup in the source code and 
found that it takes only 2-3 msec from the  8 ms processing time of 
Resv. Thus setting up per-BA TC instead of per-flow TC probably does 
not speeds up RSVP handling. We submitted a paper on this: 
http://soha.ttt.bme.hu/boomerang/public/net2k_abs.html

> scalable QoS architecture.

I agree. For the same reason, we have two Boomerang prototypes, one 
with per-flow and another with per-BA traffic conditioning: 
http://soha.ttt.bme.hu/boomerang/public/boom_sw/boomerang-net.tgz

> sense. It's the ratio that is interesting.

I was also curious, thus searched our measurements and found 
something similar for the per-flow TC Boomerang prototype:

Processing power of traffic handling / signaling

				Signaling Intensity [1/sec]	
Backgr. rate	1000	2000	3000
1 Kbps			4886	14657	41331
1 Mbps			7321	19803	43578

Foreground (reserved) traffic rate 1 Mbps
Boomerang refresh rate 30 sec
Size of data packets 1500 bytes

That is traffic handling of a 1 Mbps flow consumes about 5000 - 45000 
times more CPU than the related signaling, depending on the load of 
control and data planes. Since our Linux box needs more than 100 
times more time for handling RSVP than Boomerang, these figures are 
probably between 50 - 450 for the Linux/RSVP. Moreover, this ratio is 
less for tiny flows (e.g. 64K or 8K VoIP). 

But anyway, I accept that traffic handling is also worth to look at 
and we will measure this for RSVP a.s.a.p.

Istvan

---

From: Masanobu Yuhara <[email-masked]>
Date: Mon, 22 Nov 1999 20:58:53 +0900

There's a paper on RSVP performace:

A. Neogi, et. al, "Performance Analysis of an RSVP-Capable Router",
IEEE Network, Vol.14, No. 5, Sep./Oct. 1999.

------
Masanobu Yuhara		[email-masked]
Fujitsu Laboratories Ltd.