Re: [CCAMP] Warren Kumari's No Objection on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Thu, 11 April 2019 19:02 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95D5120689; Thu, 11 Apr 2019 12:02:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8_EShcTCzw3; Thu, 11 Apr 2019 12:02:37 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9BB1206D3; Thu, 11 Apr 2019 12:02:35 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3BJ2Ojf021246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Apr 2019 15:02:27 -0400
Date: Thu, 11 Apr 2019 14:02:24 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Yemin (Amy)" <amy.yemin@huawei.com>
Cc: Warren Kumari <warren@kumari.net>, The IESG <iesg@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>, "ccamp-chairs@ietf.org" <ccamp-chairs@ietf.org>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "draft-ietf-ccamp-rsvp-te-bandwidth-availability@ietf.org" <draft-ietf-ccamp-rsvp-te-bandwidth-availability@ietf.org>
Message-ID: <20190411190224.GP18549@kduck.mit.edu>
References: <155485344540.19678.965634240652575034.idtracker@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFBDC1BD@DGGEMM528-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9C5FD3EFA72E1740A3D41BADDE0B461FCFBDC1BD@DGGEMM528-MBX.china.huawei.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/LUT1Wd4IaPiqkHyTMpPtv-sB0QE>
Subject: Re: [CCAMP] Warren Kumari's No Objection on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with COMMENT)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2019 19:02:43 -0000
On Thu, Apr 11, 2019 at 12:26:54PM +0000, Yemin (Amy) wrote: > Hi Warren, > > Thanks for the comments, please see reply inline below. > > BR, > Amy > ________________________________________ > 发件人: Warren Kumari via Datatracker [noreply@ietf.org] > 发送时间: 2019年4月10日 7:44 > 收件人: The IESG > 抄送: draft-ietf-ccamp-rsvp-te-bandwidth-availability@ietf.org; Daniele Ceccarelli; ccamp-chairs@ietf.org; daniele.ceccarelli@ericsson.com; ccamp@ietf.org > 主题: Warren Kumari's No Objection on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with COMMENT) > > Warren Kumari has entered the following ballot position for > draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-availability/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I must admit that I'm having a hard time understanding the utility of this, and > how exactly systems are supposed to make a reasonable decision based upon the > information -- I don't **really** care that the probability of the link being > at 100Mbps is 99.995%, what I care about is what the available bandwidth is > *now*. When my device has a 123Mbps flow, it needs to decide what to do with it > -- I get that this document describes how the bandwidth probability can be > transmitted, but how should my device use this information? > [Amy] The OSPF extension RFC8330 defines how the information is distributed by OSPF. > This draft defines the signaling, how much bandwidth and corresponding availability level a flow would like to have. > > I'm also confused by the table: > Sub-bandwidth (Mbps) Availability > ------------------ ------------ > 200 99.99% > 100 99.995% > 100 99.999% > > Is there an error here? > [Amy] The table will be modified as following: > 400 99.99% > 200 99.995% > 100 99.999% > Hmm, this change would leave me more confused than the original text did. I was reading the original as saying that: under the worst weather conditions, I only have 100 Mbps capacity, and that's 99.999% available. We'll treat that as effectively "always available" since we can't do any better. If the weather is bad but not the worst weather, I can use modulation level 2, which gets me an *additional* 100 Mbps bandwidth (i.e., 200 Mbps total), so I have 100 Mbps in the 99.999% bucket and 100 Mbps in the 99.995% bucket. In clear weather, I can modulate to get 400 Mbps total, but that's only 200 Mbps more than at modulation level 2, so my 99.99% bucket has that "extra" 200 Mbps, and the other two buckets still have their 100 Mbps each. This matches up (at least in my head) with the text elsewhere in the document about "a higher availability bandwidth can be allocateed to lower availability request when the lower availability bandwidth cannot satisfy the request", which seems to only make sense when there are discrete buckets per availability level. (This model seems particularly poorly aligned for the floating-point representation of availability level, as opposed to an enumeration, but that's orthogonal to this question.) -Ben
- [CCAMP] Warren Kumari's No Objection on draft-iet… Warren Kumari via Datatracker
- Re: [CCAMP] Warren Kumari's No Objection on draft… Yemin (Amy)
- Re: [CCAMP] Warren Kumari's No Objection on draft… Warren Kumari
- Re: [CCAMP] Warren Kumari's No Objection on draft… Benjamin Kaduk
- Re: [CCAMP] Warren Kumari's No Objection on draft… Warren Kumari