Re: Question about use of RSVP in Production Networks

Dan Wing <dwing@cisco.com> Fri, 13 August 2004 14:52 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20387; Fri, 13 Aug 2004 10:52:36 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvdVI-00081h-8j; Fri, 13 Aug 2004 10:58:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvdFy-0003uv-Ak; Fri, 13 Aug 2004 10:42:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvLLv-0002km-1I for ietf@megatron.ietf.org; Thu, 12 Aug 2004 15:35:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26195 for <ietf@ietf.org>; Thu, 12 Aug 2004 15:35:05 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvLQw-0002Xz-9p for ietf@ietf.org; Thu, 12 Aug 2004 15:40:18 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 12 Aug 2004 12:37:09 -0700
Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7CJYXD2014087; Thu, 12 Aug 2004 12:34:33 -0700 (PDT)
Received: from [192.168.1.100] (sjc-vpn3-891.cisco.com [10.21.67.123]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA14856; Thu, 12 Aug 2004 12:34:32 -0700 (PDT)
Message-ID: <411BC646.2070605@cisco.com>
Date: Thu, 12 Aug 2004 12:34:30 -0700
From: Dan Wing <dwing@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dean Anderson <dean@av8.com>, ietf@ietf.org
References: <DCxSc.1330792$%F1.349469@rtp-news.cisco.com>
In-Reply-To: <DCxSc.1330792$%F1.349469@rtp-news.cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 13 Aug 2004 10:42:07 -0400
Subject: Re: Question about use of RSVP in Production Networks
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Content-Transfer-Encoding: 7bit

Dean Anderson wrote:
> RSVP is a idea that doesn't cut the mustard in the real world. There are
> several show-stopper problems with RSVP.
> 
> 1) somewhat like multicast, anyone using RSVP is vulnerable to others
> mis-using or mis-configuring RSVP. ISPs several AS's away can really screw
> up things for other ISPs. Because of this, it is unwise to deploy it
> because it requires too much trust in other ISPs.

That isn't a fault of RSVP, the protocol.  Rather, it's a fault of
insufficient authorization for a requested flow.

> That relegates RSVP to the enterprise Lan, where it usually isn't needed.
> Remember, RSVP is only useful if you have a congestion problem and need to
> choose which packets to discard.  If you have no congestion problem, then
> you have no need of RSVP.

Enterprises have WANs (ATM, FR, MPLS) which do have congestion problems.
Even within a LAN it's possible to have congestion problems (PC backups,
database replication).

 > However, having a congestion problem also opens
> the question of the nature of the congestion and what is the best way to
> deal that problem.  I was involved in a study done by Genuity and Cisco in
> which the congestion problem was found to most often involve the tail
> circuit--the link between the customer and the ISP.  The best solution for
> this problem was found to be low latency queuing, not RSVP.
> 
> 2) Unlike multicast, every hop end-to-end must use RSVP for it to be
> useful.

RSVP only needs to be enabled on the links that might become congested,
such as an enterprise's WAN links.  It usually doesn't need to be
enabled on a non-bandwidth-constrained LAN.

-d

 > An RSVP tunnel is useless.
 >
> 3) RSVP doesn't detect certain kinds of problems that are important. For
> example, a mid-span failure is not visible to RSVP.
> 
> While RSVP is important research, it is not a widely deployable
> technology.
> 
> What I-D's are you encountering that depend on RSVP?
> 
> 		--Dean
> 
> On Tue, 10 Aug 2004, Fleischman, Eric wrote:
> 
> 
>>I am aware of some use of RSVP in labs but I am not aware of any use of
>>RSVP in production networks (i.e., real life networks people connect to
>>the Internet with). Simultaneously, I am encountering I-Ds and other
>>work planning to use RSVP. This possible disconnect concerns me.
>>Therefore, I would appreciate being educated by anybody using RSVP in
>>production settings. Would you please let me know how many devices, what
>>applications, and how successful these deployments (if any) are? Thank
>>you.
>>
>>
>>_______________________________________________
>>Ietf mailing list
>>Ietf@ietf.org
>>https://www1.ietf.org/mailman/listinfo/ietf
>>
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf