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
- [Tsvwg] Comments on: draft-ietf-tsvwg-rsvp-bw-red… Bob Braden
- Re: [Tsvwg] Comments on: draft-ietf-tsvwg-rsvp-bw… Antonio De Simone
- Re: [Tsvwg] Comments on: draft-ietf-tsvwg-rsvp-bw… Fred Baker
- RE: [Tsvwg] Comments on: draft-ietf-tsvwg-rsvp-bw… Dhesikan, Subha