Re: [CCAMP] Warren Kumari's No Objection on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with COMMENT)

Warren Kumari <warren@kumari.net> Thu, 11 April 2019 20:08 UTC

Return-Path: <warren@kumari.net>
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 9508A120319 for <ccamp@ietfa.amsl.com>; Thu, 11 Apr 2019 13:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 OOXpXBioddLA for <ccamp@ietfa.amsl.com>; Thu, 11 Apr 2019 13:08:36 -0700 (PDT)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFA3120307 for <ccamp@ietf.org>; Thu, 11 Apr 2019 13:08:33 -0700 (PDT)
Received: by mail-qk1-x72f.google.com with SMTP id w20so4283912qka.7 for <ccamp@ietf.org>; Thu, 11 Apr 2019 13:08:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wRVgLf3jIYXbyzQE2yw2JXfGoTB3YdgQPfBY69i7sGY=; b=023mApk8V+NL4QjG2ryBVL2skq2oR1px7yGSurvhT9JZMxkKW4xvfqqhjiKi3/z0Rl eYOwYd2f83MhbpSGuzzIC1rEMVdyKPoz+Ct29dDmPSu4U9KgM9SFD9FfzK5zRaf77yfv 2aScZ7jLP8ecj33z6+B+anvTlQNuUUgndlpsdvV/EKrdRVlOUBWeTIuPtKJa14yTxV0m L541IH5167BKsgPPfQgEBBBX6bosp/++43rgHeDgztiBI+DxYYY7fgDildTkdcxTUYOF u4DckbZrG6+uoMIzbFfg8BC89EurSx8mEa+y1vZEHU8MHYCeVdYBAKLU+bDy0738ctFC xBhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wRVgLf3jIYXbyzQE2yw2JXfGoTB3YdgQPfBY69i7sGY=; b=r+ipcsfvr7+xuARJAUvSZMimDghXS4K/M4ZsBuruYSrpj+VilfMF10VUQKcX+Z5EuM 4GWWivRCTBwDm7Wu0qfrNGzUiqAzEi3vpZwgw4Eb2LKw8fflCyjO0/Y3qzRiElvDJxnL EdHPPDa3wI6mQRIBHQYyjT6ONPDAHO74AmBSFBLvcIsTIzCjT4mmGjMY9Jcwl1QEDKKb 9j0uLXa7gTJAwb+SojAathOZC1L7mky9sbNnlcksAVbF5bWx70lOm2/5ap5ED3Eg/AV2 hP4Uswz/iUWvf0fF+cpFhYE4KM7FjjXG3E4Mg1erSTlu0SL7ZsYZ4R36wmWjAYV3Oda2 qFmQ==
X-Gm-Message-State: APjAAAV/WrkUruOe8XdPsxEI5xzadM4RHxVQ0QEZ98gCaXZ8Re03sYha 627BPaJX95pIse9s+BRMnTl+jZ9Cwz83rwNxOd3Nlg==
X-Google-Smtp-Source: APXvYqxH7XGQBdbdpeZHDAwdNsQRsDgkXBjcRYj9y1lL2pVsYLjvNFXtulasx6QMpi6nf6hEZu7TQear/cW89LkrV6A=
X-Received: by 2002:a37:a546:: with SMTP id o67mr40685210qke.134.1555013311518; Thu, 11 Apr 2019 13:08:31 -0700 (PDT)
MIME-Version: 1.0
References: <155485344540.19678.965634240652575034.idtracker@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFBDC1BD@DGGEMM528-MBX.china.huawei.com> <20190411190224.GP18549@kduck.mit.edu>
In-Reply-To: <20190411190224.GP18549@kduck.mit.edu>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 11 Apr 2019 16:07:55 -0400
Message-ID: <CAHw9_iJ=jY7kB7Dh_QP9Spb4t__Bp=YiYkv_U2N-s+sKwwF6zw@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: "Yemin (Amy)" <amy.yemin@huawei.com>, 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>
Content-Type: multipart/alternative; boundary="0000000000000df5c6058646c029"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/jzDXbuxA7G7QZnp7Rsi08onRKLo>
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 20:08:38 -0000

On Thu, Apr 11, 2019 at 3:02 PM Benjamin Kaduk <kaduk@mit.edu>; wrote:

> 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:
>

Perhaps just copy and paste the below under the original table then?

W



>
> 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
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf