Subject: RE: [Diffserv] RSVP vs DiffServ

From: "Yoram Bernet (Exchange)" <[email-masked]>
Date: Thu, 18 Nov 1999 08:42:36 -0800

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

---

From: "Albert Manfredi" <[email-masked]>
Date: Thu, 18 Nov 1999 12:38:00 -0500

Yoram Bernet wrote:

> Albert Manfredi wrote:
> travels through every device on the end-to-end path
> through the network.

Yes, but it doesn't operate to provide QoS knobs within the diffserv
domain. As was proposed in one of the diffserv drafts at the recent
IETF meeting, it's possible to use RSVP as an admission control
protocol at the diffserv edge. Or other means could be used instead.

> The
> necessarily mean that they apply per-flow traffic
> handling.

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

> RSVP is used end-to-end.
> Aggregate traffic handling (a.k.a. diffserv)

AND per hop behaviors vs per microflow reservations (the latter
being the RSVP and ATM approach to guaranteeing QoS) are used within
the diffserv core.

Next thing you know, this discussion will be moved to
diffserv-interest.

Bert

---

From: George Swallow <[email-masked]>
Date: Thu, 18 Nov 1999 13:14:20 -0500

Albert -

The overall question here is *not* RSVP vs DiffServ.
The question is where do you use IntServ, where do 
you use DiffServ, and how do you glue it all together.

RSVP has defined a tunnel spec.  In this a number of 
RSVP sessions can be aggregated and tunnelled through
another domain.  One such way of doing this is to use DiffServ
on the aggregated stream.

I fully expect to be using RSVP to set up MPLS tunnels across 
DiffServ domains and then aggregating RSVP IntServ requests
into those tunnels.  

As Yoram pointed out RSVP is a signalling protocol.  When it was 
published, all there was to signal was IntServ.  But the two should 
not be so closely associated.  RSVP will certainly be used to signal
the kinds of DiffServ traffic which is flowing on an MPLS tunnel.
See draft-ietf-mpls-diff-ext-02.txt.

...George

---

From: [email-masked] (Goorah Shravan)
Date: Fri, 19 Nov 1999 14:00:25 +0400

Hi,

	at least this is a topic of discussion which I am interested in

> > > well" in very large networks,

	It would clarify things if you could explain "scalability with respect
to what?"

> protocol at the diffserv edge. Or other means could be used instead.

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?

> Not unless we really change the diffserv charter.

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

	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: Venumadhav Josyula <[email-masked]>
Date: Fri, 19 Nov 1999 11:57:05 -0500 (EST)

Hello shravan,

how can rsvp modified to have no state at all. Secondly is'nt the
extensions to RSVP useful in diffserv. But extension to rsvp does deal
with per flow but it deals with per aggregate flow is it not

thanks 
bye
venu

On Fri, 19 Nov
1999, Goorah Shravan wrote:

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

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Josyula Venumadhav

Residnce:					Office:
4303 Apt#L, Ramona Drive			Department of Electrical
Fairfax, Virginia-22030				Engg
						
Phone:
Residence: (703)-359-5419			Office:    (703)-993-1566
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

---

From: "Istvan Cselenyi" <[email-masked]>
Date: Fri, 19 Nov 1999 19:36:02 +0100

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

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: Masataka Ohta <[email-masked]>
Date: Sat, 20 Nov 99 23:19:44 JST

> http://soha.ttt.bme.hu/boomerang/public/decides.zip

FYI, we have proven in our INET '98 paper that multicast
routing table entries can not be aggregated.

It is easy to prove routing table entries with QoS routing can
not either be aggregated.

There also is an easy proof that RSVP scales at the backbone.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 21 Nov 99 11:48:25 JST

> routing table entries can not be aggregated.

To my surprise, I have got a few questions on the location of the paper,
even though INET, the Internet Summit, is an annual conference of ISOC,
which is a legal umbrella of IETF.

The referece information is:

	Manolo Sola, Masataka Ohta, Toshinori Maeno,
	"Scalability of Internet Multicast Protocols",
	Proceedings of INET'98,
	http://www.isoc.org/inet98/proceedings/6d/6d_3.htm,
	July 1998.

> There also is an easy proof that RSVP scales at the backbone.

A brief discription of the easy proof is that a high speed backbone needs
parallel hardware (including parallel routing tables, parallel policers
and parallel schedulers) amount of which is proportional to the speed
of the backbone or the expected number of flows at the backbone.

FYI, I have pointed it out several times in RSVP ML before the silly
attempt of diffserve was proposed.

							Masataka Ohta

---

From: [email-masked] (Goorah Shravan)
Date: Mon, 22 Nov 1999 11:19:40 +0400

Hello Venumadhav,

> how can rsvp modified to have no state at all. Secondly is'nt the

I do hesitate to give you a reference about Intserv in Diffserv/RSVP
mailing list(s)  BUT this paper is of good quality according to me,

Berson S., Vincent S., "Aggregation of Internet Integrated Services
State", IWQoS 98

You will get it somewhere beneath the "RSVP Working Group HomePage"
(Additional RSVP Page -> see Publications)

> with per flow but it deals with per aggregate flow is it not

	I think this question has been clarified/answered to some extent by
others - BUT the draft which I mentioned in my previous mail and which I
quote again, mentions "RSVP state aggregation" and this draft can be
useful as well

Best Regards,
Shravan