Subject: Re: RSVP vs DiffServ

From: Bob Braden <[email-masked]>
Date: Tue, 16 Nov 1999 09:22:39 -0800 (PST)

*> 
  *> I was browsing the iBand3 website (http://www.stardust.com/iband3/) and
  *> discovered a section in the 'iBAND3 Network Showcase Tour Guide' that outlined
  *> applications using QoS and Policy protocols.  Of the six applications that iBand
  *> profiled, 5 applications are using DiffServ and 1 is using RSVP.
  *> This was a bit surprising since I thought that RSVP was further along than
  *> DiffServ (wrt standardization and deployment) and RSVP was actually gaining
  *> momentum in the industry.  I understand the benefits of DiffServ over RSVP, but
  *> I thought that RSVP's end-to-end guarantee outweighed the scalability and
  *> overhead issues.
  *> 
  *> In a few years when these QoS methods become more mature, it makes sense that
  *> certain applications would favor one over the other.  But in the early stages,
  *> are the benefits clear enough that applications are focusing on DiffServ rather
  *> than RSVP?
  *> 
  *> Any comments about this issue are appreciated.
  *> 
  *> Thanks.
  *> 
  *> Patrick Foy
  *> 
  *> 
  *> 
I do not think EITHER of these two lists is the appropriate forum
for such a discussion.  I can offer the [email-masked]
list as a possible alternative.

Bob Braden

---

From: [email-masked]
Date: Fri, 19 Nov 1999 09:23:16 +0000

Hi Yoram,

I got your email from the RSVP list.
I have read about the limited scalability of RSVP in respect of
- flow basis (as you pointed out below)
- signalling.
The reasons seem to be logical,
however, I have not yet found papers that prove those limitations neither
analytically, nor experimentally nor with simulations.

Can you point me to some publications?

Matthias
++++++++++++++++++++++++++++++++++++++++++++++
Matthias Kraner
University of Sheffield
Department of Computer Science
Communications and Distributed Systems Research Group
Regent Court
211, Portobello Street
Sheffield S1 4DP
United Kingdom
+++++++++++++++++++++++++++++++++++++++++++++++

                    "Yoram Bernet                                                                                          
                    (Exchange)"                  To:     Albert Manfredi <[email-masked]>, Bob Quinn         
                    <[email-masked]        <[email-masked]>                                                        
                    osoft.com>                   cc:     [email-masked], [email-masked]                                   
                    Sent by:                     Subject:     RE: [Diffserv] RSVP vs DiffServ                              
                    [email-masked]                                                                                  
                    rg                                                                                                     

                    18/11/99 16:42                                                                                         

> My description would be that RSVP is thought by some not to "scale
> well" in very large networks,

RSVP is just a signaling protocol. It is traditionally associated with
Intserv and with per-flow trafic handling mechanisms. The scalability
concerns are really with the per-flow trafic handling mechansism more than
with the signaling per-se.

  and that therefore diffserv is being
> developed to provide QoS within the network core. RSVP is instead
> used at the edges,

Let's look at this a little further. What do we mean when we say "RSVP is
used at the edges". RSVP is an end-to-end signaling protocol, so - RSVP
travels through every device on the end-to-end path through the network.
The
question is - who listens to RSVP? Typically, we would expect devices to
listen to RSVP if they are serving as ingress points to valuable or
congested regions of the network. An example is the ingress router to a
diffserv network (at the edge). Another example might be a router serving a
WAN connection. The fact that certain devices listen to RSVP does not
necessarily mean that they apply per-flow traffic handling. They may listen
to RSVP in order to apply admission control to aggregate trafic handling.
In
this case, we can say that:

RSVP is used end-to-end.
Aggregate traffic handling (a.k.a. diffserv) is used in the core.
Per-flow trafic handling may be applied where it benefits us, but for
scalability reasons would not be applied where there are a large number of
flows.

which might include interfaces within diffserv
> routers (after all, core routers are likely to be edge routers as
> well).
>
> 802.1p is a priority scheme for a Layer 2 LAN environment, so it is
> a different issue from IP QoS. But IP QoS could invoke IEEE 802.1p,
> when appropriate.
>
> Similarly, ATM might be an alternative to diffserv or to intserv
> over datagram LANs, in that ATM could be used either in the core or
> at the edges, instead of datagram nets like Ethernet or FDDI. So ATM
> has proposals for mapping of RSVP and diffserv QoS into ATM QoS,
> when IP is carried over ATM.
>

One could imagine a very complex world, in which there are N different link
layer QoS mechanisms and we need to define NxN mappings - from each link
layer to each other link layer. On the other hand, one could imagine a high
layer abstraction for expressing QoS requrieemtns (what Intserv started
doing, and still hasn't been proven wrong at - though there may be room for
one or two additional services). This high layer abstraction can then be
mapped to each different link layer QoS mechansim. That's what the ISSLL
group has done (with 802.1p, ATM, ISSLOW) and continues to do with
diffserv.
With this approach, you end up with a much more manageable N mappings (as
opposed to NxN).

> Bert
> [email-masked]
>

Check out the recent drafts in the ISSLL WG on a framework for using RSVP
and Intserv over diffserv networks. It clarifies many of the points
discussed in this thread.

_______________________________________________
diffserv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

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

comments below...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, November 19, 1999 2:00 AM
> To: Albert Manfredi
> Cc: Yoram Bernet (Exchange); [email-masked]; [email-masked]
> Subject: Re: [Diffserv] RSVP vs DiffServ
> 
> RSVP can be used to provide end-to-end admission control.
> 
> With reference to 
> 
> 	Bernet Y., Yavatkar R., Ford P., Baker F., Zhang L., 
> Speer M., Braden
> R., Davie B., "Integrated Services Operation Over Diffserv Networks",
> Internet Draft, June 1999
> 
> Diffserv is being considered as a NETWORK ELEMENT along the end-to-end
> path. So at  least the ingress/egress points should be RSVP-aware -
> isn't?
> 

Indeed. A diffserv network, through provisioning of some sort, is presumed
to be able to offer an SLA at its ingress points. The provider's ingress
router and the customer's egress router both know this SLA. Thus either (or
both) could use RSVP to admit or deny requests for admission to one of the
service classes offered by the SLA.

> 
> > But, to summarize, a diffserv core router does not listen to RSVP.
> > Not unless we really change the diffserv charter.
> > 
> 

The diffserv charter says nothing about precluding routers in the diffserv
network from listening to signaling. There are many ideas about how to
configure the routers in the diffserv core to be able to offer the SLAs at
the edges. Different provisioning options will enable the core of the
diffserv network to be more or less efficient in its use of resources (or to
br able to offer higher or lower quality services). If the core of the
diffserv network is going to offer high quality (e.g. telephony) service
*and* is not going to be highly over-provisioned, then - chances are that
some kind of signaling will have to be applied to provisioning the core. One
option is the magical and mystical bandwidth broker. Another is aggregate
RSVP, of the form defined by Fred Baker and Carol Ituralde in thir draft in
the ISSLL WG. Yet another is per-flow RSVP. I expect that certain diffserv
providers will configure certain key nodes in the core of the network to
listen to some kind of signaling. That signaling is going to talk about
resource requirements. It's probably gonna look an awful lot like RSVP. 

> This is interesting but I tend to agree with Yoram on that it 
> depends on
> what RSVP signaling does to "network elements" or RSVP-aware 
> devices and
> whether Diffserv should be RSVP-aware or not. 
> 	Do you have some proposals on how to change it?
> 
> 		Per-Flow set-up of Path/Resv state is one task 
> that can be done using
> RSVP. RSVP could be modified in such a way so as NOT to 
> install per-flow
> state or to have no state at all in Diffserv

RSVP per-flow signaling state is not the scalability problem. The
scalability problem is relaed to the per-flow *traffic handling* state that
is typically asociated with RSVP. RSVP, per-se does not mandate any
particular form of traffic handling. Difserv, being an aggregate form of
traffic handling works nicely *with* RSVP to support scalable QoS in large
networks.
> 
> 	Your views?
> 
> Best Regards,
> Shravan Goorah
> -- 
> Shravan Goorah
> Lecturer, Department of Computer Science,
> Faculty of Engineering, University of Mauritius
> Tel. 454 1041 		Fax.  465 71 44
>

---

From: Andrew Smith <[email-masked]>
Date: Fri, 19 Nov 1999 11:51:44 -0800

I think the jury is still out on the scalability of RSVP control-plane
signaling state - but I think that is just a measure of the early state of
implementations right now. Using ATM as an example, early implementations of
Q.2931 and PNNI were pathetically inefficient and, IMHO, were a major
barrier to deployment of ATM; these days they are much more useful. Whilst
RSVP is a lot simpler (no routing, no hierarchy, much simpler parameter
set), I think the same sort of maturity-process will occur.

Just to expand on Yoram's point regarding the data-plane: we have found that
it is what I call the "per-flowspec" state rather than the "per-filterspec"
state that is expensive i.e. packet filters are quite cheap but queues and
rate-meters/markers are expensive. So any scheme that can aggregate
microflows into a smaller number of scheduling classes seems worth pursuing,
even if it still relies on microflow classification. This leads to the
heretical observation that you don't really need upstream marking with "QoS
labels" (modulo the IPSEC scenario) but you do need to be able to aggregate
scheduling classes ... but we digress.

Andrew

****************************************************************
Andrew Smith                              tel: +1 (408) 579-2821
Extreme Networks                          fax: +1 (408) 579-3000
3585 Monroe St.                   http://www.extremenetworks.com
Santa Clara CA 95051-1450        em:  [email-masked]
****************************************************************

> From: Yoram Bernet (Exchange) [mailto:[email-masked]]
> Sent: Friday, November 19, 1999 11:03 AM
> To: [email-masked]; Albert Manfredi
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Diffserv] RSVP vs DiffServ
...

---

From: Andrew Smith <[email-masked]>
Date: Fri, 19 Nov 1999 12:00:29 -0800

And of course another interesting question is: 

"How much electrical power (as in how many transitions of how many
flip-flops in router ASIC silicon) is expended on traffic handling the 1
Mbps data flow?"

:-)

Andrew

> Sent: Friday, November 19, 1999 11:17 AM
> To: [email-masked]; [email-masked]
> Cc: Albert Manfredi; [email-masked]; [email-masked]
> 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 
> 
> > 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]
> > Goorah,
> > > 	at least this is a topic of discussion which I am interested in
> > 
> > me too - just before we are moved to diffserv-interest...
> > 
> > > 	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: "Yoram Bernet (Exchange)" <[email-masked]>
Date: Fri, 19 Nov 1999 13:45:38 -0800

I agree.

> From: Andrew Smith [mailto:[email-masked]]
> Sent: Friday, November 19, 1999 11:52 AM
> To: Yoram Bernet (Exchange)

---

From: "Rajiv Chakravorty" <[email-masked]>
Date: Tue, 23 Nov 1999 19:56:36 +0530

Right. The paper can downloaded from the authors Web-site
http://www.cs.sunysb.edu/~neogi/

Regards,
Rajiv Chakravorty
----------------------------------------------------------------------------
---
Silicon Automation Systems(SAS), Bangalore, India
Email: [email-masked]            http://www.sasi.com

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