Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-alto-performance-metrics-28> for your review
Qin Wu <bill.wu@huawei.com> Tue, 04 July 2023 13:42 UTC
Return-Path: <bill.wu@huawei.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87621C14CE54; Tue, 4 Jul 2023 06:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0fcBDM4X8_c; Tue, 4 Jul 2023 06:42:32 -0700 (PDT)
Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D60C14CEFF; Tue, 4 Jul 2023 06:42:31 -0700 (PDT)
Received: from canpemm500008.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4QwP8P6V5BzTlyd; Tue, 4 Jul 2023 21:41:25 +0800 (CST)
Received: from canpemm500005.china.huawei.com (7.192.104.229) by canpemm500008.china.huawei.com (7.192.105.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Tue, 4 Jul 2023 21:42:27 +0800
Received: from canpemm500005.china.huawei.com ([7.192.104.229]) by canpemm500005.china.huawei.com ([7.192.104.229]) with mapi id 15.01.2507.027; Tue, 4 Jul 2023 21:42:26 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "yry@cs.yale.edu" <yry@cs.yale.edu>, "young.lee@gmail.com" <young.lee@gmail.com>, "dhruv.ietf@gmail.com" <dhruv.ietf@gmail.com>, "sabine.randriamasy@nokia-bell-labs.com" <sabine.randriamasy@nokia-bell-labs.com>, "luismiguel.contrerasmurillo@telefonica.com" <luismiguel.contrerasmurillo@telefonica.com>
CC: "alto-ads@ietf.org" <alto-ads@ietf.org>, "alto-chairs@ietf.org" <alto-chairs@ietf.org>, "ietf@j-f-s.de" <ietf@j-f-s.de>, "martin.h.duke@gmail.com" <martin.h.duke@gmail.com>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Thread-Topic: AUTH48: RFC-to-be 9439 <draft-ietf-alto-performance-metrics-28> for your review
Thread-Index: AdmuOuboTFDQPyoYRAKQ5FqSFtgaWA==
Date: Tue, 04 Jul 2023 13:42:26 +0000
Message-ID: <8bb05f666f6f4aa1aec3c0de71c77ba3@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.118.68]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/I-6NF-LVUmc7avGDWTEMt4XzgM0>
Subject: Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-alto-performance-metrics-28> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jul 2023 13:42:36 -0000
Hi, RFC Editors: Sorry for late followup, please see my reply inline below on behalf of all other authors. -----邮件原件----- 发件人: rfc-editor@rfc-editor.org [mailto:rfc-editor@rfc-editor.org] 发送时间: 2023年6月24日 7:53 收件人: Qin Wu <bill.wu@huawei.com>; yry@cs.yale.edu; young.lee@gmail.com; dhruv.ietf@gmail.com; sabine.randriamasy@nokia-bell-labs.com; luismiguel.contrerasmurillo@telefonica.com 抄送: rfc-editor@rfc-editor.org; alto-ads@ietf.org; alto-chairs@ietf.org; ietf@j-f-s.de; martin.h.duke@gmail.com; auth48archive@rfc-editor.org 主题: Re: AUTH48: RFC-to-be 9439 <draft-ietf-alto-performance-metrics-28> for your review Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file. 1) <!-- [rfced] Please note that we expanded "ALTO" in the document title, per Section 3.6 of RFC 7322 ("RFC Style Guide") (https://www.rfc-editor.org/info/rfc7322). Please review. Original: ALTO Performance Cost Metrics Currently: Application-Layer Traffic Optimization (ALTO) Performance Cost Metrics --> [Qin Wu] Sounds good to me. 2) <!-- [rfced] Authors' Addresses: Please advise regarding the listed zip code for Y. Richard Yang. We see "06520" here, but please note that RFCs 7285, 9240, 9241, and 9275 use 06511 but RFC 8896 uses 06520. Which is correct? Original: Y. Richard Yang Yale University 51 Prospect St New Haven, CT 06520 United States of America Email: yry@cs.yale.edu --> [Qin Wu] I google address of Yale University, I believe '06520' is correct one. 3) <!-- [rfced] Sections 1 and 3.1: Are the quotes around the words "where" and "how" necessary? Original: This document registers a set of new cost metrics (Table 1) to allow applications to determine "where" to connect based on network performance criteria including delay and bandwidth related metrics. ... The core additional details of a performance metric specify "how" the metric is obtained. --> [Qin Wu] I think the quotes can be deleted. What it does is just to put emphasize on the key words. 4) <!-- [rfced] Table 1: a) Should "sum Unidirectional Delay" be "sum of Unidirectional Delays"? It appears that one or more words are missing. [Qin Wu] Yes, For space limit in the table, the "of" is omitted but I believe we should make it complete, I agree to make the change, for the first word, we should use Capital letter, i.e., s/sum Unidirectional Delay/Sum of Unidirectional Delay of links along the path b) To what does "from above" refer? [Qin Wu] "from above" is referred to one way delay in direction or Unidirectional Delay c) Should "sum of Unidirectional Delay Variation" be "sum of Unidirectional Delay Variations"? [Qin Wu] No, sum of Unidirectional Delay Variation is referred to Sum of Unidirectional Delay Variation of links along the path Original: sum Unidirectional Delay ... Base: Sum of two directions from above ... sum of Unidirectional Delay Variation --> [Qin Wu] Here is the proposed changes: OLD TEXT: " sum Unidirectional Delay ... Base: Sum of two directions from above ... sum of Unidirectional Delay Variation --> " NEW TEXT: " Sum of Unidirectional Delay of links along the path Base: Sum of two directions of unidirectional delay Sum of Unidirectional Delay Variation of links along the path " 5) <!-- [rfced] Section 1: This sentence is difficult to interpret. Please clarify "... metrics, to expose to application-layer traffic optimization, can be a typical mechanism by network operators". Original: Deriving ALTO cost performance metrics from existing network-layer traffic engineering performance metrics, to expose to application-layer traffic optimization, can be a typical mechanism by network operators to deploy ALTO [RFC7971], [FlowDirector]. --> [Qin Wu] Here is the proposed change: OLD TEXT: " Deriving ALTO cost performance metrics from existing network-layer traffic engineering performance metrics, and making it exposed to application-layer traffic optimization, can be a typical mechanism by network operators to deploy ALTO [RFC7971], [FlowDirector]. " 6) <!-- [rfced] Section 1: Because the capitalization of the terms in this paragraph indicates that these are proper terms but we could not find these specific terms in the RFCs cited here, may we update as suggested? If not, please provide clarifying text. Original: The common metrics Min/Max Unidirectional Delay defined in [RFC8570][RFC8571] and Max Link Bandwidth defined in [RFC3630,RFC5305] are not listed in Table 1 because they can be handled by applying the statistical operators defined in this document. The metrics related with utilized bandwidth and reservable bandwidth (i.e., Max Reservable BW and Unreserved BW defined in [RFC3630,RFC5305]) are outside the scope of this document. Suggested: The Min/Max Unidirectional Link Delay metric as defined in [RFC8570] and [RFC8571], and Maximum (Link) Bandwidth as defined in [RFC3630] and [RFC5305], are not listed in Table 1 because they can be handled by applying the statistical operators defined in this document. The metrics related to utilized bandwidth and reservable bandwidth (i.e., Maximum Reservable (Link) Bandwidth and Unreserved Bandwidth as defined in [RFC3630] and [RFC5305]) are outside the scope of this document. --> [Qin Wu] The proposed changes sound good to me. 7) <!-- [rfced] Section 3: As this list indicated five items but only contained four (i, ii, iv, and v), we renumbered it. If a fifth item is missing here, please let us know what it is. Original: To address the issue and realize ALTO use cases, for metrics in Table 1, this document defines performance metric identifiers which can be used in the ALTO protocol with well-defined (i) Metric Name, (ii) Metric Description, (iv) Units of Measurement, and (v) Measurement Points, which are always specified by the specific ALTO services; for example, endpoint cost service is between the two endpoints. Currently: To address the issue and realize ALTO use cases for the metrics listed in Table 1, this document defines performance metric identifiers that can be used in the ALTO protocol with the following well-defined items: (1) Metric Name, (2) Metric Description, (3) Units of Measurement, and (4) Measurement Points, which are always specified by the specific ALTO services; for example, the endpoint cost service is between the two endpoints. Hence, the ALTO performance metric identifiers provide basic metric attributes. --> [Qin Wu] The proposed change looks good, thanks. 8) <!-- [rfced] Please review each artwork element in this document. Should any of the artwork elements be tagged as sourcecode (e.g., perhaps "http-message" or "json") or another type of element? Please see <https://www.rfc-editor.org/materials/sourcecode-types.txt; if the list on that page does not contain an applicable type, please let us know. --> [Qin Wu] Yes, most of artwork elements are json examples, but table 1,2,3 are not. 9) <!-- [rfced] Figure 1: Please clarify the meaning of "estimation to". Does it mean "estimation of" or something else? Original: Figure 1. A framework to compute estimation to performance metrics --> [Qin Wu] Yes, s/estimation to/estimation of 10) <!-- [rfced] Section 3.2: "99% percentile" and "99.9% percentile" read oddly, because they read as "99 percent percentile" and "99.9 percent percentile". Should these be "99th percentile" and "99.9th percentile", per "95th percentile" as used in Section 4? [Qin Wu] Your understanding is correct. Original: For example, delay- ow:p99 gives the 99% percentile of observed one-way delay; delay- ow:p99.9 gives the 99.9% percentile. --> [Qin Wu] s/99% percentile/99th percentile, s/99.9% percentile/99.9th percentile 11) <!-- [rfced] Section 3.2: Please note that because we did not see any mention of "32", "character", or "metric" in RFC 7258 ("Pervasive Monitoring Is an Attack"), we did a search and found the relevant text in Section 10.6 of RFC 7285. We updated the number accordingly. Please let us know any concerns. Original: Note that RFC 7258 limits the overall cost metric identifier to 32 characters. Currently: Note that [RFC7285] limits the overall cost metric identifier to 32 characters. --> [Qin Wu] Sounds good, thanks. 12) <!-- [rfced] Section 4: Should "set of delays {pkt.delay}" be "set of (pkt.delay) entries" per "(pkt.delay)", "(pkt.dropped)", and "(pkt.hopcount)" earlier in this paragraph? We ask because we do not see curly brackets used around "pkt." items anywhere else in this document. [Qin Wu] I want other authors to confirm this. My understanding is YES. Original (the previous sentence is included for context): The measures of each individual packet (pkt) can include the delay from the time when the packet enters the network to the time when the packet leaves the network (pkt.delay); whether the packet is dropped before reaching the destination (pkt.dropped); the number of network hops that the packet traverses (pkt.hopcount). The semantics of the performance metrics defined in this section are that they are statistics computed from these measures; for example, the x-percentile of the one-way delay is the x-percentile of the set of delays {pkt.delay} for the packets in the stream. --> [Qin Wu] I prefer to keep as it does. 13) <!-- [rfced] Sections 4.1.3, 4.2.3, and 4.3.3: We had trouble following the meaning of these sentences. If the suggested text is not correct, please provide clarifying text. Original: A non-normative reference definition of end-to-end one-way delay is [RFC7679]. ... A non-normative reference definition of end-to-end round-trip delay is [RFC2681]. ... A non-normative reference definition of end-to-end one-way delay variation is [RFC3393]. Suggested: A non-normative definition of the end-to-end one-way delay metric is provided in [RFC7679]. ... A non-normative definition of the end-to-end round-trip delay metric is provided in [RFC2681]. ... A non-normative definition of the one-way delay variation metric is provided in [RFC3393]. --> [Qin Wu] I believe it is correct, thanks. 14) <!-- [rfced] Examples 1 through 8 (Sections 4.1.3 and subsequent): a) We moved the "Example" information (e.g., "Example 1") from the body of the <artwork> elements to figure titles. Please let us know any concerns. b) As the numbering scheme for the examples was misordered (... 3, 5, 4, 5, 7, 8), we also ordered the numbering. c) We found "value on" a bit confusing. Does it mean "value for", "value of", or something else? Original numbering scheme: Example 1: Delay value on source-destination endpoint pairs ... Example 1a: Delay value on source-destination endpoint pairs for IPv6 ... Example 2: Round-trip Delay of source-destination endpoint pairs ... Example 3: Delay variation value on source-destination endpoint pairs ... Example 5: Loss rate value on source-destination endpoint pairs ... Example 4: hopcount value on source-destination endpoint pairs ... Example 5: TCP throughput value on source-destination endpoint pairs ... Example 7: bw-residual value on source-destination endpoint pairs ... Example 8: bw-available value on source-destination endpoint pairs Currently: Figure 2: Delay Value on Source-Destination Endpoint Pairs (Example 1) ... Figure 3: Delay Value on Source-Destination Endpoint Pairs for IPv6 (Example 1a) ... Figure 4: Round-Trip Delay of Source-Destination Endpoint Pairs (Example 2) ... Figure 5: Delay Variation Value on Source-Destination Endpoint Pairs (Example 3) ... Figure 6: Loss Rate Value on Source-Destination Endpoint Pairs (Example 4) ... Figure 7: Hop Count Value on Source-Destination Endpoint Pairs (Example 5) ... Figure 8: TCP Throughput Value on Source-Destination Endpoint Pairs (Example 6) ... Figure 9: Residual Bandwidth Value on Source-Destination Endpoint Pairs (Example 7) ... Figure 10: Available Bandwidth Value on Source-Destination Endpoint Pairs (Example 8) --> [Qin Wu] Sounds good to me. 15) <!-- [rfced] Section 4.1.4: Please clarify the meaning of "the URI to the URI field" in this sentence. Original ("RECOMMEDED" has been fixed): If the estimation is from the IPPM measurement framework, it is RECOMMEDED that the "parameters" field of an "estimation" one-way delay metric includes the following information: the URI to the URI field of the IPPM metric defined in the IPPM performance metric [IANA-IPPM] registry (e.g., https://www.iana.org/assignments/ performance-metrics/OWDelay_Active_IP-UDP-Poisson- Payload250B_RFC8912sec7_Seconds_95Percentile). Possibly (as we see that all other field names are quoted): If the estimation is from the IPPM measurement framework, it is RECOMMENDED that the "parameters" field of an "estimation" one-way delay metric include the URI in the "URI" field of the IPPM metric defined in the IPPM "Performance Metrics" registry [IANA-IPPM] (e.g., <https://www.iana.org/assignments/performance-metrics/ OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_ 95Percentile>). --> [Qin Wu] your proposed change seems more clear than the original one, thanks! 16) <!-- [rfced] Section 4.3.3: To what does "the one" refer in this sentence? If the suggested text is not correct, please provide clarifying text. Original: This document defines the specific case that F selects as the "first" packet the one with the smallest one-way delay. Suggested: This document defines the specific case where F selects the packet with the smallest one-way delay as the "first" packet. --> [Qin Wu] I believe the original and suggested text is equivalent, your suggested change works for me. 17) <!-- [rfced] Section 4.3.3: To what does "it" refer in this sentence - the mean, or something else? Original (the previous sentence is included for context): Note that in statistics, variations are typically evaluated by the distance from samples relative to the mean. In networking context, it is more commonly defined from samples relative to the min. --> [Qin Wu] It is referred to variation. To avoid confusion, suggested to make change to the previous sentence OLD TEXT: " variations are typically evaluated by the distance from samples relative to the mean. " NEW TEXT: " variation is typically evaluated by the distance from samples relative to the mean. " 18) <!-- [rfced] Section 4.4.4: Does "of the average of loss rate" mean "of the average loss rate" or something else? Original ("link link" has been fixed): For estimation by aggregation of routing protocol link metrics, the default aggregation of the average of loss rate is the sum of the link link loss rates. --> [Qin Wu] Here is the proposed change: NEW TEXT: " For estimation by aggregation of routing protocol link metrics, the default aggregation of the average loss rate is the sum of the link loss rates. " 19) <!-- [rfced] Section 4.5.4: Does "hop count" in these sentences mean "the hop count", "the hop count metric", or something else? Also, we see "estimating hopcounts" a couple lines later; does that mean "hopcount values", "hop counts", or something else? Original: "nominal": Typically hop count does not have a nominal value. ... [Qin Wu] I believe "the" is needed before "hop count does not". "sla": Typically hop count does not have an SLA value. [Qin Wu] same as above, s/ hop count does not have/ the hop count does not have "estimation": The exact estimation method is out of the scope of this document. An example of estimating hopcounts is by importing from IGP routing protocols. --> [Qin Wu] s/ An example of estimating hopcounts/ An example of estimating hop count values 20) <!-- [rfced] Section 5: We could only find three metrics related to throughput and bandwidth: "tput", "bw-residual", and "bw-available". What is the fourth metric? Original: This section introduces four throughput/bandwidth related metrics. --> [Qin Wu] s/ This section introduces four throughput/bandwidth related metrics./ This section introduces three throughput/bandwidth related metrics. 21) <!-- [rfced] Section 5.1.3: "a TCP congestion-control conforming flow" reads a bit oddly. Does it mean "a conformant TCP congestion control flow" or something else? [Qin Wu] Maybe we should change "a TCP congestion-control conforming flow" into "a congestion-control conforming TCP flow" or ""a TCP flow"". Original: Intended Semantics: To give the throughput of a TCP congestion- control conforming flow from the specified source to the specified destination. --> 22) <!-- [rfced] Section 5.1.4: This sentence does not parse. Please clarify "provide estimation to", "set to [I-D.ietf-tcpm-rfc8312bis]", and "for an ongoing congestion control algorithm such as BBR, a a link to its specification". Also, should "Cubic" be "CUBIC" per [I-D.ietf-tcpm-rfc8312bis]? Original ("a a" has been fixed): To specify (1), it is RECOMMENDED that the "parameters" field (object) include a field named "congestion-control-algorithm", which provides a URI for the specification of the algorithm; for example, for an ALTO server to provide estimation to the throughput of a Cubic Congestion control flow, [Qin Wu] s/ provide estimation to the throughput of a Cubic Congestion control flow,/ provide estimation of the throughput for a CUBIC Congestion control flow, its "parameters" includes a field "congestion-control-algorithm", with value being set to [I-D.ietf-tcpm-rfc8312bis]; for an ongoing congestion control algorithm such as BBR, a a link to its specification. --> [Qin Wu] s/ with value being set to [I-D.ietf-tcpm-rfc8312bis]/ with value being set to the URI for [I-D.ietf-tcpm-rfc8312bis] [Qin Wu] s/ for an ongoing congestion control algorithm such as BBR, a a link to its specification. / for an ongoing congestion control algorithm such as BBR, a link to its specification can be added. 23) <!-- [rfced] Section 5.2.3: Should "residual bandwidth from the specified source and the specified destination" be "residual bandwidth from the specified source to the specified destination"? We ask because we see "available bandwidth from the specified source to the specified destination" in Section 5.3.3. [Qin Wu] Correct. Also, we could not find the word "capacity" or the string "max" used in the context of maximum bandwidth in RFC 8571. Will this particular citation be clear to readers? (We see "Maximum Bandwidth (i.e., the link capacity)" and "maximum bandwidth (i.e., the link capacity)" in RFCs 7471 and 8570, respectively, but nothing similar in RFC 8571.) [Qin Wu] I think it has explained the relation between " residual bandwidth " and " link capacity ". I think it is clear. Original: Intended Semantics: To specify temporal and spatial residual bandwidth from the specified source and the specified destination. ...[Qin Wu] s/ from the specified source and the specified destination./ from the specified source to the specified destination. When the max statistical operator is defined for the metric, it typically provides the minimum of the link capacities along the path, as the default value of the residual bandwidth of a link is its link capacity [RFC8571,8570,7471]. --> 24) <!-- [rfced] Sections 5.2.4 and 5.3.4: "entry in Section 4.1.4 on aggregation of routing protocol link metrics" in these two sentences reads oddly and doesn't seem necessary. If the suggested text is not correct, please clarify. Original: "estimation": See the "estimation" entry in Section 4.1.4 on aggregation of routing protocol link metrics. ... "estimation": See the "estimation" entry in Section 4.1.4 on aggregation of routing protocol link metrics. Suggested: "estimation": See the "estimation" entry in Section 4.1.4. ... "estimation": See the "estimation" entry in Section 4.1.4. --> [Qin Wu] Sounds good to me. 25) <!-- [rfced] Section 6: This sentence is not clear as written. If the suggested text is not correct, please clarify the meaning of "this document specifies common issues unless one metric has its unique challenges". Original (the previous sentence is included for context): Also, the performance metrics specified in this document are similar, in that they may use similar data sources and have similar issues in their calculation. Hence, this document specifies common issues unless one metric has its unique challenges. Suggested: Hence, this document specifies issues that the performance metrics might have in common and also discusses challenges regarding the computation of ALTO performance metrics (Section 6.4). --> [Qin Wu] Sounds good to me. 26) <!-- [rfced] Section 7: Please review the following. In the case of item c), please let us know how this document should be updated. a) We changed "ALTO Server" and "ALTO Client" to "ALTO server" and "ALTO client" per usage in RFC 7285. b) We removed the quotes in the second sentence, as the comparable sentence in Section 8.3.5 of RFC 7285 cites RFCs 2818 and 5246, both of which are obsolete. From Section 8.3.5 of RFC 7285: ALTO server implementations as well as ALTO client implementations MUST support the "https" URI scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246]. c) RFC 7230 has been obsoleted by RFCs 9110 and 9112. In the case of this document, it is not clear whether we should cite RFC 9110 and/or RFC 9112. Please let us know which RFC should be cited. Original (this document): As specified in "Protection Strategies" (Section 15.3.2 of [RFC7285]), the ALTO Server should authenticate ALTO Clients when transmitting an ALTO information resource containing sensitive TE performance metrics. "Authentication and Encryption" (Section 8.3.5 of [RFC7285]) specifies that "ALTO Server implementations as well as ALTO Client implementations MUST support the "https" URI scheme of [RFC7230] and Transport Layer Security (TLS) of [RFC8446]". Currently (still cites obsoleted RFC 7230): As specified in Section 15.3.2 ("Protection Strategies") of [RFC7285], the ALTO server should authenticate ALTO clients when transmitting an ALTO information resource containing sensitive TE performance metrics. Section 8.3.5 ("Authentication and Encryption") of [RFC7285] specifies that ALTO server implementations as well as ALTO client implementations MUST support the "https" URI scheme [RFC7230] and Transport Layer Security (TLS) [RFC8446]. --> [Qin Wu] The proposed change looks good, I believe RFC7230 should be replaced by RFC9110 since https URI scheme is defined in RFC9110. 27) <!-- [rfced] We have included some specific questions about the IANA text below. In addition to responding to those questions, please review all of the IANA-related updates carefully and let us know if any further updates are needed. a) FYI - For clarity, we created subsections within Section 8. Currently: 8.1 ALTO Cost Metric Registry 8.2 ALTO Cost Source Registry b) Section 8.2. May we change '"ALTO Cost Source" registry' here and in Section 3.1 to '"ALTO Cost Source Types" registry', to match the plural style used for all other registries listed on <https://www.iana.org/assignments/alto-protocol/>? If you agree to this change, we will ask IANA to update their page accordingly. Original (Section 3.1 and this section): The "cost-source" field of the "cost-context" field MUST be one registered in "ALTO Cost Source" registry (Section 8). ... This document requests the creation of the "ALTO Cost Source" registry. Suggested: The "cost-source" field of the "cost-context" field MUST be one that is registered in the "ALTO Cost Source Types" registry (Section 8). ... This document has created the "ALTO Cost Source Types" registry. [Qin Wu] Sounds good to me. c) Section 8.2. The last column in Table 3 does not match the last column in the "ALTO Cost Source" registry at <https://www.iana.org/assignments/alto-protocol/>. In Table 3, the column is named "Security Considerations" and points to Section 7 of this document whereas the column in the IANA registry is named "References" and points to this document. Should the IANA registry be updated to match Table 3? --> [Qin Wu] I can see inconsistency issue but to align with other registries at <https://www.iana.org/assignments/alto-protocol/> , I prefer to keep as it does. Security consideration doesn't need to be reflected in the IANA registry in my understanding. 28) <!-- [rfced] References: We could not find a URL or DOI for [Prophet]. Also, we couldn't locate it via ACM/IEEE Transactions on Networking 2020. Is this article available online somewhere and not behind a paywall? Original: [Prophet] Gao, K., Zhang, J., and YR. Yang, "Prophet: Fast, Accurate Throughput Prediction with Reactive Flows", ACM/IEEE Transactions on Networking July, 2020. --> [Qin Wu] The Prophet paper can be found at the following URL: https://dl.acm.org/doi/10.1109/TNET.2020.3016838 29) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, and let us know if any changes are needed. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> [Qin Wu] No, thanks. 30) <!-- [rfced] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. an "sla" value (Sections 5.2.4 and 5.3.4) / an SLA value (Sections 4.5.4 and 5.1.4) Available Bandwidth / available bandwidth (used generally in running text) Delay Variation / delay variation (in running text)* Hop Count / hop count (in running text)* Loss Rate / loss rate (in running text)* method of measurement or calculation / Method of Measurement or Calculation (e.g., "about the method of measurement or calculation", "such as Method of Measurement or Calculation") One-way Delay / one-way delay (in running text)* Residual Bandwidth / Residual bandwidth (metric) (in running text) (We also see "residual bandwidth".) Round-trip Delay / round-trip delay (in running text)* * For example, compare the sentence just after Table 1, the "These eight performance metrics can be classified" sentence, and the first sentence of Section 4. --> [Qin Wu] Here is the proposed change to section 1: OLD TEXT: " The first six metrics listed in Table 1 (i.e., One-way Delay, Round- trip Delay, Delay Variation, Loss Rate, Residual Bandwidth, and Available Bandwidth) " NEW TEXT: " The first six metrics listed in Table 1 (i.e., one-way delay, round- trip delay, delay variation, loss rate, residual bandwidth, and available bandwidth) " OLD TEXT: " These eight performance metrics can be classified into two categories: those derived from the performance of individual packets (i.e., One-way Delay, Round-trip Delay, Delay Variation, Loss Rate, and Hop Count) and those related to bandwidth/throughput (Residual bandwidth, Available Bandwidth, and TCP throughput). " NEW TEXT: " These eight performance metrics can be classified into two categories: those derived from the performance of individual packets (i.e., one-way delay, round-trip delay, delay variation, loss rate, and hop count) and those related to bandwidth/throughput (residual bandwidth, available bandwidth, and TCP throughput). " Thank you. RFC Editor/lb/kc On Jun 23, 2023, at 4:50 PM, rfc-editor@rfc-editor.org wrote: *****IMPORTANT***** Updated 2023/06/23 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info/). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-editor@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9439.xml https://www.rfc-editor.org/authors/rfc9439.html https://www.rfc-editor.org/authors/rfc9439.pdf https://www.rfc-editor.org/authors/rfc9439.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9439-diff.html https://www.rfc-editor.org/authors/rfc9439-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9439-xmldiff1.html The following files are provided to facilitate creation of your own diff files of the XML. Initial XMLv3 created using XMLv2 as input: https://www.rfc-editor.org/authors/rfc9439.original.v2v3.xml XMLv3 file that is a best effort to capture v3-related format updates only: https://www.rfc-editor.org/authors/rfc9439.form.xml Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9439 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9439 (draft-ietf-alto-performance-metrics-28) Title : ALTO Performance Cost Metrics Author(s) : Q. Wu, Y. Yang, Y. Lee, D. Dhody, S. Randriamasy, L. Contreras WG Chair(s) : Jan Seedorf, Mohamed Boucadair, Qin Wu Area Director(s) : Martin Duke, Zaheduzzaman Sarker
- [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-alto-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Qin Wu
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Qin Wu
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Y. Richard Yang
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Dhruv Dhody
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Sabine Randriamasy (Nokia)
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Sabine Randriamasy (Nokia)
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Dhruv Dhody
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Dhruv Dhody
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Dhruv Dhody
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Sabine Randriamasy (Nokia)
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Qin Wu
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Young Lee
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… LUIS MIGUEL CONTRERAS MURILLO
- Re: [auth48] AUTH48: RFC-to-be 9439 <draft-ietf-a… Lynne Bartholomew
- [auth48] [IANA] Re: AUTH48: RFC-to-be 9439 <draft… Lynne Bartholomew
- Re: [auth48] [IANA] Re: AUTH48: RFC-to-be 9439 <d… Lynne Bartholomew
- [auth48] [IANA #1278074] [IANA] Re: AUTH48: RFC-t… Sabrina Tanamal via RT
- Re: [auth48] [IANA #1278074] [IANA] Re: AUTH48: R… Lynne Bartholomew
- [auth48] [IANA #1278074] [IANA] Re: AUTH48: RFC-t… Sabrina Tanamal via RT
- Re: [auth48] [IANA #1278074] [IANA] Re: AUTH48: R… Lynne Bartholomew