Re: [Tsvwg] Comments on: draft-ietf-tsvwg-rsvp-bw-reduction-01.txt

Fred Baker <fred@cisco.com> Fri, 09 September 2005 17:13 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDmRi-0004FI-FX; Fri, 09 Sep 2005 13:13:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDmRg-0004Ey-U5 for tsvwg@megatron.ietf.org; Fri, 09 Sep 2005 13:13:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16153 for <tsvwg@ietf.org>; Fri, 9 Sep 2005 13:13:46 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDmVH-0008J9-Jz for tsvwg@ietf.org; Fri, 09 Sep 2005 13:17:33 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 09 Sep 2005 13:13:14 -0400
X-IronPort-AV: i="3.96,182,1122868800"; d="scan'208"; a="69642162:sNHT66653942504"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j89HCXRP024877; Fri, 9 Sep 2005 13:13:11 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Sep 2005 13:13:02 -0400
Received: from [192.168.0.106] ([10.82.224.54]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Sep 2005 13:13:00 -0400
In-Reply-To: <200509082250.PAA10049@gra.isi.edu>
References: <200509082250.PAA10049@gra.isi.edu>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <6C6D7973-CA2F-4A58-BD5C-7CEDD62D7BC4@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Subject: Re: [Tsvwg] Comments on: draft-ietf-tsvwg-rsvp-bw-reduction-01.txt
Date: Fri, 09 Sep 2005 10:12:59 -0700
To: Bob Braden <braden@ISI.EDU>
X-Mailer: Apple Mail (2.734)
X-OriginalArrivalTime: 09 Sep 2005 17:13:02.0251 (UTC) FILETIME=[BC1EAFB0:01C5B561]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Sender: tsvwg-bounces@ietf.org
Errors-To: tsvwg-bounces@ietf.org

I agree and I disagree.

As you say, RSVP applies no intrinsic policy to reservations - not  
even "is there enough bandwidth". It is a means by which a policy can  
be parameterized along a path and the policy applied.

What 3181 describes is the policy element that might be carried in  
the POLICY_DATA object (which is described in various sections of RFC  
2205 but left as a placeholder for future definition and was further  
described in RFCs 2750-2753 and further updated by 3181/3182) that  
assigns a reservation and a hold priority for a reservation, and  
which in turn be implemented under a policy that might include  
prioritization and preemption of reservations.

So, no, RSVP does not intrinsically describe policy. However, the  
information elements it carries have the capability of parameterizing  
a policy that a policy manager might then apply. And if the policy  
involves treating some reservations as more equal than others, those  
capabilities exist.

On Sep 8, 2005, at 3:50 PM, Bob Braden wrote:

>
> Hi.  I would like to comment on:
>
>      Title        : A Resource Reservation Protocol Extension for
>                           the Reduction of Bandwidth of a  
> Reservation Flow
>     Author(s)    : J. Polk, S. Dhesikan
>     Filename    : draft-ietf-tsvwg-rsvp-bw-reduction-01.txt
>
> Since it has a TSVWG file name, I assume it is a work item of TSVWG.
>
> I suspect that this proposal is fundamentally flawed, at least in its
> description of the problem.  It concerns the "priority" of RSVP
> microflows, and cites Shai Herzog's RFC 3181.  However, note that 3181
> does NOT talk about RSVP, and that there is no concept of flow
> "priority" in RSVP itself.  Deliberately.  The priority of flows is a
> higher-level notion that has no place in RSVP itself.  Thus, Herzog's
> notion of priority is part of the policy mechanism, not part of TCP.
>
> Layering and modularity in protocols matters.
>
> Bob Braden
>
> _______________________________________________
> tsvwg mailing list
> tsvwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/tsvwg
>

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