[alto] Review for draft-ietf-alto-performance-metrics-12
Dear ALTOers and authors of draft-ietf-alto-performance-metrics-12,
Below is my review for draft-ietf-alto-performance-metrics-12.
Best regards,
Jensen
==
General issue:
The document is well written. I only have one question about the design
part:
the base ALTO protocol only uses the cost-mode to infer the value format,
e.g., "numerical" infers the cost value MUST be a floating-point value; but
this document requires different value formats for different cost-metrics,
e.g., "delay-ow" requires the non-negative floating-point value, and
"hopcount" requires the non-negative integer value. But based on
Sec 11.3.2.3 of RFC7285, in the "constraints" field, "ALTO servers SHOULD
use at least IEEE 754 double-precision floating point [IEEE.754.2008] to
store the cost value". I wonder if a test constraint expression like "eq
3.1" for the cost-metric "hopcount" is valid. Should the ALTO server reject
such a request? According to RFC7285, it should be valid. But according to
this document, it is clearly always false.
==
Nits and writing suggestions:
Section 1., paragraph 5:
>The purpose of this document is to ensure proper usage of the
>performance metrics defined in Table 1; it does not claim novelty of
>the metrics. The Origin column of Table 1 gives the RFC which
>defines each metric.
Origin -> Origin Example (to be consistent with the table)
>We can rough classify the performance metrics into two categories:
>those derived from the performance of individual packets (i.e., one-
>way delay, round-trip delay, delay variation, hop count, and loss
>rate), and those related with bandwidth (TCP throughput, residue
>bandwidth and max reservable bandwidth). These two categories are
>defined in Section 3 and Section 4 respectively. Note that all
>metrics except round trip delay are unidirectional. Hence, a client
>will need to query both directions if needed.
Section 2., paragraph 1:
>When defining the metrics in Table 1, this document considers the
>guidelines specified in [RFC6390], which requires fine-grained
>specification of (i) Metric Name, (ii) Metric Description, (iii)
>Method of Measurement or Calculation, (iv) Units of Measurement, (v)
>Measurement Points, and (vi) Measurement Timing. In particular, for
>each metric, this document defines (i) Metric Name, (ii) Metric
>Description, and (iv) Units of Measurement. The Measurement Points
>are always specified by the specific ALTO services; for example,
>endpoint cost service is between the two end points.
end points -> endpoints
Section 2.1., paragraph 11:
>A particular type of "estimation is direct "import", which indicates
>that the value of the metric is imported directly from a specific
>existing protocol or system. Specifying "import" as source instead
source -> the source
>of the more generic "estimation" may allow better tracing of
>information flow. For an "import" metric, it is RECOMMENDED that the
>"parameters" field provides details to the system from which raw data
>is imported. In particular, one may notice that the set of end-to-
>end metrics defined in Table 1 has large overlap with the set defined
>in [RFC8571], in the setting of IGP traffic engineering performance
>metrics for each link (i.e., unidirectional link delay, min/max
>unidirectional link delay, unidirectional delay variation,
>unidirectional link loss, unidirectional residual bandwidth,
>unidirectional available bandwidth, unidirectional utilized
>bandwidth). Hence, an ALTO server may use "import" to indicate that
>its end-to-end metrics are computed from link metrics imported from
>[RFC8571].
Section 2.2., paragraph 2:
>percentile, with letter p followed by a number p:
a number p -> a number
Section 2.2., paragraph 16:
>If a metric has no (and hence no - as well), the metric MUST
recommend adding " surrounding -, or using dash character instead;
if possible, giving the precise BNF grammar will be better, as I
see some metrics names also include the dash character ("-").
>be considered as the 50 percentile (median). Since this scheme is
>common for all metrics defined in this document, below we only
>specify the base identifier.
Section 3., paragraph 1:
>This section introduces ALTO network performance metrics including
>one way delay, round trip delay, delay variation, hop count, and
>packet loss rate. They measure the "quality of experience" of the
>stream of packets sent from a resource provider to a resource
>consumer. The measures of each individual packet (pkt) can include
>the delay from the time that the packet enters the network to the
>time that the packet leaves the network (pkt.delay); the number of
the time that -> the time when
>
[alto] Review for draft-ietf-alto-unified-props-new-12
Dear all, Please, find here below the review for the Unified Properties draft. /* General comments */ .- Section 2 - Requirements language - as general comment, the usage of words such as MUST, MAY, etc should be reviewed in all of the occurrences in the text. In some of them they do not appear in capital letters, so not clear if this statements apply or not. Examples of this are: "must" in 2nd paragraph of section 3.2; "must" in 2nd paragraph of section 4.1; "may" in 1st paragraph of section 4.3; etc. .- References to the need of registering some items at IANA - it is not clear to me if this can be left as it is or if some values have to be proposed in the draft, or at least marked in the text with the idea of substituting such marks by values once IANA register the items. If that is the case, it would be advisable to include (maybe as an annex) a summary table compiling all the items that are expected to be registered. Would it not be part of section 12? .- Along the text it is frequent to find references to other sections before or afterwards. Acknowledging that this could be necessary, it would help the reader to have some summary table (or any other way, like a figure) where the different aspects could be listed beforehand, in such a way that the reader can use it as a kind of map for navigating through the document. I understand it is not easy, so take it as a suggestion for making the document more readable. For instance, some way of showing the relationship among terms in the Terminology section. .- Section 3 presents the basic features of the unified properties while the advanced ones are in section 4. How these extensions co-exist? Are they incremental? What is the reason from presenting them in separate sections? Is it possible to have the basic ones without the advanced features? .- Both Section 10 and Appendix A present examples. Would not make sense to move all he examples either to one place or the other? /* Particular comments */ .- Section 1 - Introduction, page 4, 2nd paragraph - "... recent ALTO use cases show ..." -> it would be good to be more explicit by listing the use cases that are being referred to. .- Section 1 - Introduction, page 5, 1st bullet - fix reference for [REF path-vector] .- Section 1 - Introduction, page 5, 3rd bullet - "... POST-mode... that returns ..." -> would not be "sets" instead of "returns"? .- Section 1 - Introduction, page 5, 1st paragraph - "extensible" -> "augmentable" ?? .- Section 1.1 - Terminology - fix the text marked as TBC .- Section 2 - Requirements language, 1st paragraph - fix the text marked as TODO. .- Section 3, 1st paragraph - The reference to the assumption of familiarity with ALTO protocol is redundant with the last sentence of section 1 (just before section 1.1 title) .- Section 3, 1st paragraph - "... ALTO Entities, entities for short" -> "... ALTO Entities, or entities for short" .- Section 3.2.2, 1st paragraph - the sentence "An entity domain name ..." is hard to understand. Please, revisit and simplify (maybe shortening or dividing it). .- Section 3.3, 1st paragraph - "Simularly" -> "Similarly" .- Section 3.3, bullets in page 9 - is there any inventory of registered types? Are only those provided here as examples? .- Section 4.2, penultimate paragraph - "Example resource specific..." -> "Example of resource specific..." .- Section 4.4, 2nd paragraph - it would be interesting to perform queries and marking properties that could exclude or filter the entities. For instance to get a list of entities compliant with some property but excluding those that are compliant with another one. .- Section 4.4.3, 1st paragraph - "... inherits no more than one property ..." <- why not more than one? .- Section 4.4.3, 1st paragraph, last sentence - how is it applied? It would be interesting to add some example. .- Section 4.5, 1st paragraph - "Therefore an ALTO server ... specifies the properties ..." <- how this advertisement is made? .- Section 4.5, 2nd paragraph - expand IRD as first occurrence in the text. .- Section 4.5, 2nd bullet - "... a list of the names ..." <- names or types? .- Section 4.6, 1st paragraph - "To this end, he ..." -> "To this end, the ..." .- Section 4.6, 1st paragraph - "The syntax of the entity domain identifier ... allows the client to infer ..." -> would it not be better to follow some rule instead of inferring if it is resource specific or not? .- Section 4.6, last paragraph - is it necessary to have always a Defining Information Resource for each entity domain? .- Section 4.6.1, page 16, paragraph "A fundamental attribute ..."- I don't understand the paragraph .- Section 4.7, 1st paragraph -- "The PID value for an IPv4 ..."- I would suggest to rephrase, hard to understand. .- Section 4.7, 2nd paragraph - "... needs to be aware of aware of appropriate ..." -> "... needs to be aware of appropriate ..." .- Section 5, title - "... Basic Data Type ..." -> here it is mentioned
[alto] Review for draft-ietf-alto-performance-metrics-12
Dear ALTO WG I have done a review of the Performance Metrics draft (-12). No major problems regarding the technical part, Other comments related to consistency and clarity are in the attached file (marked with [DANNY]) Best regards, Danny Lachos ALTO Working Group Q. Wu Internet-DraftHuawei Intended status: Standards Track Y. Yang Expires: January 13, 2021Yale University Y. Lee Samsung D. Dhody Huawei S. Randriamasy Nokia Bell Labs L. Contreras Telefonica July 12, 2020 ALTO Performance Cost Metrics draft-ietf-alto-performance-metrics-12 Abstract [DANNY] Consider reducing the number of lines (https://www.ietf.org/standards/ids/guidelines/#6) Cost metric is a basic concept in Application-Layer Traffic Optimization (ALTO), and is used in basic ALTO services including both the cost map service and the endpoint cost service. Different applications may use different cost metrics, but the ALTO base protocol [RFC7285] defines only a single cost metric, i.e., the generic "routingcost" metric; see Sec. 14.2 of [RFC7285]. Hence, if the ALTO client of an application wants to issue a cost map or an endpoint cost request to determine the resource provider that offers better delay performance (i.e., low-delay) to a resource consumer, the base protocol does not define the cost metric to be used. This document addresses the issue by introducing network performance metrics, including network delay, jitter, packet loss rate, hop count, and bandwidth. The ALTO server may derive and aggregate such performance metrics from routing protocols such as BGP-LS, OSPF-TE and ISIS-TE, or from end-to-end traffic management tools, and then expose the information to allow applications to determine "where" to connect based on network performance criteria. There are multiple sources to derive the performance metrics. For example, whether the metric reported is an estimation based on measurements or it is a service-level agreement (SLA) can define the [DANNY] Consider adding a comma: "measurements, or it is a " meaning of the performance metric. Hence, an application may need additional contextual information beyond the metric value. This document introduces an additional "cost-context" field to the ALTO "cost-type" field to convey such information. Wu, et al. Expires January 13, 2021[Page 1] Internet-DraftALTO Performance Cost MetricsJuly 2020 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 13, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
[alto] Meeting info for Oct 13, 2020
Hello everyone, IMPORTANT: According to the doodle poll, our weekly meeting will be moved to 9:00 am US EST, Tuesday. The agenda of this week is as follows: 1. Status of the WG documents 2. Rechartering discussion If anyone wants to present or lead another discussion in the weekly meeting, please let me know. Bridge: https://yale.zoom.us/my/yryang Best, Kai___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
