Subject: RSVP vs DiffServ

From: [email-masked]
Date: Tue, 16 Nov 1999 09:50:13 -0500

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

---

From: Bob Quinn <[email-masked]>
Date: Wed, 17 Nov 1999 11:46:37 -0500

Hello Patrick,

The iBAND3 showcase was created by a design team whose focus was 
to demonstrate interoperability of QoS technologies--RSVP, DiffServ, 
802.1p, SBM--along with policy management, to provide end-to-end QoS. 
As you mention, RSVP has been stable and shipping in products to 
enable Integrated Services (IntServ) for some time now, so RSVP 
interoperability among vendors is largely a non-issue. 

DiffServ and these other QoS technologies, on the other hand, are 
relatively new. They are complements to RSVP, not replacements 
by any stretch. Hence, when DiffServ is used it doesn't preclude 
or eclipse the use of RSVP. They are both important parts of the 
QoS machinery designed to satisfy the needs of the full spectrum 
of QoS application and network requirements.

QoS requires traffic handling mechanisms and the ability to 
dynamically affect these mechanisms across multiple network 
devices between a sender/receiver pair. Diffserv, IntServ, 
802.1p or even ATM are all examples of traffic handling 
mechanisms and RSVP is a signaling protocol used to (dynamically) 
configure them. Hence, among other things, the iBAND3 showcase 
was designed to demonstrate RSVP in action in a combination 
DiffServ and IntServ enabled network.

So, bottom line, you mustn't read too much into the fact that 
DiffServ may have been emphasized in the descriptions of the 
showcase. It doesn't mean what you think.
Hope that helps, 
-- 
Bob Quinn 
[email-masked]

At 09:50 AM 11/16/99 , [email-masked] wrote:
>_______________________________________________
>diffserv mailing list
>[email-masked]
>http://www.ietf.org/mailman/listinfo/diffserv
>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>

---

From: "Albert Manfredi" <[email-masked]>
Date: Wed, 17 Nov 1999 15:41:10 -0500

Bob Quinn wrote:

[ ... ]

> Diffserv, IntServ,
> configure them.

Dunno about you (plural, or y'all), but I find this confusing.

My description would be that RSVP is thought by some not to "scale
well" in very large networks, and that therefore diffserv is being
developed to provide QoS within the network core. RSVP is instead
used at the edges, 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.

Bert
[email-masked]