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

From: Warren Kumari via Datatracker <[email-masked]>
Date: Tue, 09 Apr 2019 16:44:05 -0700

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?

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?

I also support the DISCUSS on the floating-point issue -- perhaps this could be
much more simply encoded with a table and some bits? E.G: 25%, 50%, 75%, 80%,
90%, 91%, 92%.. 99%. If > 99%, then the remaining gets used to encode the
"number of nines" availability (5 == 5 nines).

---

From: "Yemin (Amy)" <[email-masked]>
Date: Thu, 11 Apr 2019 12:26:54 +0000

Hi Warren, 

Thanks for the comments, please see reply inline below. 

BR,
Amy
________________________________________
发件人: Warren Kumari via Datatracker [[email-masked]]
发送时间: 2019年4月10日 7:44
收件人: The IESG
抄送: [email-masked]; Daniele Ceccarelli; [email-masked]; [email-masked]; [email-masked]
主题: Warren Kumari's No Objection on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with 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. 

Is there an error here?
[Amy] The table will be modified as following:
   400                    99.99%
   200                    99.995%
   100                    99.999%

I also support the DISCUSS on the floating-point issue -- perhaps this could be
much more simply encoded with a table and some bits? E.G: 25%, 50%, 75%, 80%,
90%, 91%, 92%.. 99%. If > 99%, then the remaining gets used to encode the
"number of nines" availability (5 == 5 nines).
[Amy] Since the OSPF extension RFC8330 use the floating-point number, here we would like to continue using it. 
Reference to IEEE754 will be added.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 11 Apr 2019 09:11:31 -0400

On Thu, Apr 11, 2019 at 8:27 AM Yemin (Amy) <[email-masked]> wrote:

> 抄送: [email-masked]; Daniele
> Ceccarelli; [email-masked]; [email-masked];
> [email-masked]
> 主题: Warren Kumari's No Objection on
> draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with COMMENT)
>
> This draft defines the signaling, how much bandwidth and corresponding
> availability level a flow would like to have.
>
Cool, thanks.

> we would like to continue using it.

Ah, ok, fair enough.

Thanks,
W

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 Apr 2019 14:02:24 -0500

> Thanks for the comments, please see reply inline below. 

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

---

From: Warren Kumari <[email-masked]>
Date: Thu, 11 Apr 2019 16:07:55 -0400

On Thu, Apr 11, 2019 at 3:02 PM Benjamin Kaduk <[email-masked]> wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

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

W