Subject: RE: [Diffserv] RSVP vs DiffServ

From: "Yoram Bernet (Exchange)" <[email-masked]>
Date: Mon, 22 Nov 1999 07:43:11 -0800

Istvan:

Thank you for your in-depth response. Comments below...

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

I don't quite understand the numbers here. When you say that "TC takes 2-3
msec from the 8 msec processing time of RESV", what exactly do you mean?
Let's normalize the measurements to per-flow measurements. In that case -
RESV messages come in at a certain rate (typically one per 30 seconds per
flow), and each message needs some processor time. Data packets on the flow
come in at a certain rate (usually a couple of orders of magnitude higher
than the signaling messages)and they incurr some processor time. So - is the
2-3 msec the time required per packet or for all the packets that come in
every 30 seconds (for each signaling message)? What rate is the data flow?
You provide numbers below that do seem to normalize signaling burden vs.
trafic handling burden, but - it's not clear from this statement per-se. Of
course - I haven't yer read the source you pointed out - so - it may be
clear in there...

> 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

I'm not sure how to read this table, though it seems to hold the answers i'm
looking for... I assume that the second row holds the numbers for a traffic
flow of 1 Kbps and the third row for a traffic flow of 1 Mbps. I gather that
the packet size (in both cases is 1500 bytes, though for the 1 Kbps flow,
it's likely that smaller packet sizes would be used). I'm not sure what the
1000/2000/3000 numbers across the top row mean - background something or
other... Also - what does the 'signaling intensity [1/sec]' mean? Is that
the assumed signaling rate for the flow? or is that all the signaling from
background flows?
> 
> 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). 
> 

Interesting - these numbers do confirm that the burden due to traffic
handling is substantially greater than that due to signaling. You note that
the ratio won't be as bad for tiny flows. With smaller flows, there is less
data to move, but - the packet sizes tend to be smaller, because these tend
to be audio flows requiring less latency. So - the per-packet burden of
traffic handling would not go down quite as quickly as one might consider.
Since policing and scheduling are per-packet, this is an important
consideration.

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

Great - i'm very interested in hearing more. Thanks for the insight.

> Istvan

---

From: "Istvan Cselenyi" <[email-masked]>
Date: Tue, 23 Nov 1999 08:39:59 +0100

Yoram,

> > Moreover, we disabled the TC setup in the source code and 

I mean that the Linux-RSVP router needs about 8 ms to process *one* 
Resv message, but if you switch off the setup of TC in the RSVP 
daemon, it takes 2-3 ms less to process one Resv message.

> course - I haven't yer read the source you pointed out - so - it may be

Yes, I hope so.
 
> looking for... 

That 2 dimensional table might be tricky for the first glance. The idea 
was to test the Boomerang router's performance in different load 
conditions. Thus we measured the forwarding latency of packets of a 
reserved flow in case of different load on data and control planes (i.e. 
different background load and signaling intensity).

> I assume that the second row holds the numbers for a traffic
> it's likely that smaller packet sizes would be used). 

Here we fed two UDP flows into the Boomerang router - one 1 Mbps 
"foreground" flow and a "background" flow with changing bitrate (1 Kbps 
and 1 Mbps). Reservation was made for the foreground flow, which had 
a fix packet size of 1500 bytes. What about these tables:

Background data load 1 Kbps
Signaling Intensity [1/sec]	1000	2000	3000
Ratio of TC / signaling        4886	14657	41331

Background data load 1 Mbps
Signaling Intensity [1/sec]	1000	2000	3000
Ratio of TC / signaling        7321	19803	43578

> I'm not sure what the

Besides the data flows, we also generated extra Boomerang messages 
(without corresponding data flows) in order to load the control plane. 
Signaling intensity expresses how many Boomerang messages are 
received by the router within one second (not the assumed signaling 
rate).

I hope this helps.

Istvan

--------------------------------------------------
                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: Sarraju Narasinga Rao <[email-masked]>
Date: Wed, 24 Nov 1999 09:03:09 +0530

Hi

I have been following this thread with keen interest. Thank you all for
bringing up and discussing a topic that helps clarify the direction that
deployment of signaled QoS will take.

That said, IMHO, this discussion would probably benefit from being moved
to a separate mailing list. I recollect that Bob Braden had pointed out
in one of the early mails in this thread that neither the RSVP nor the
DiffServ list is the "appropriate" list for this discussion.

Apart from the "appropriateness" criteria, this will also help conserve
bandwidth (this thread is currently duplicated on both lists). Also, it
leads to less clutter in the mailboxes (for those of us that are
subscribed to both lists).

Bob, is your offer of a separate list ([email-masked]) still
open? 

I apologise for the routine, administrative nature of this posting. I
hope to make useful technical contributions soon. 

Regards
-Sarraju

*******************************
* Sarraju Narasinga Rao       *
* Duet Technologies Pvt. Ltd  *
* SDF # B-1, NEPZ             *
* Noida, UP 201305            *
* INDIA                       *
*-----------------------------*
* Phone: +91(1191)568302-9    *
*        +91(1191)567002-5    *
*         x136                *
* eFax : +1(603)843-3302      *
* Fax  : +91(1191)562970      *
* email: [email-masked]   *
*******************************

"Yoram Bernet (Exchange)" wrote:
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

--