Subject: RE: [Diffserv] RSVP vs DiffServ

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

I am not aware of any studies which quantify this formally. Istvan's comes
close, but does not, that I understand, yield a ratio of 'processing/memory
burden required for *signaling* processing' of a given traffic flow to
'processing/memory burden required for *trafic-handling* processing' of the
same flow.

I have turned off trafic handling on RSVP capable routers and observed,
quantifiably, that the impact on the router's processor is minimal, as
compared to the same conditions with traffic handling enabled.

Yoram

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Friday, November 19, 1999 1:23 AM
> To: Yoram Bernet (Exchange)
> Cc: [email-masked]
> Subject: RE: [Diffserv] RSVP vs DiffServ
> 
> 
> 
> 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: "Istvan Cselenyi" <[email-masked]>
Date: Mon, 22 Nov 1999 06:46:02 +1

Hi Matthias,

We tried to scrutinize the performance of per-flow QoS signaling (but 
not necessarily per-flow TC) defining a couple of metrics in:

http://soha.ttt.bme.hu/boomerang/public/ic2k_abs.html

Moreover, we made measurements for identifying the critical 
operations of signaling handling:

http://soha.ttt.bme.hu/boomerang/public/net2k_abs.html

and other measurements, simulations for quantifying the impact of a 
signaling-based service on traffic of other service classes. It is 
quite likely that our next study will be about the control vs. data 
plane load caused by signaling and data traffic of a reserved flow  - 
following Yoram's proposal.

Istvan