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 <stat> (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
> network hops that the packet traverses (pkt.hopcount); and whether
> the packet is dropped before reaching destination (pkt.dropped). The
destination -> the destination
> semantics of the performance metrics defined in this section is that
> they are statistics (percentiles) 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.
Section 3.1.3., paragraph 1:
> Intended Semantics: To specify spatial and temporal aggregated delay
spatial -> the spatial
> of a stream of packets from the specified source and the specified
> destination. The spatial aggregation level is specified in the query
> context (e.g., PID to PID, or endpoint to endpoint).
Section 3.1.4., paragraph 2:
> "sla": Many networks provide delay in their application-level service
> level agreements. It is RECOMMENDED that the "parameters" field of
> an "sla" one-way delay metric provides a link ("link") to the SLA
I assume that the second link (the one surrounding with ") means a
field called "link", and the first link (the one without ") means
the value of this field is a URI. Please make it clear. Adding an
example could be better.
> definition.
Section 5.3., paragraph 2:
> To address this issue, the only defined "routingcost" metric can be
> ONLY "estimation".
"ONLY" is not an RFC 2119 key word, doesn't have to be uppercase.
Section 7., paragraph 3:
> Since he This document requests the creation of the "ALTO Cost Source
> Registry" with the following currently defined values:
This paragraph seems to be incomplete and repeated to the next one.
==============================================
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
