Re: [Gen-art] Gen-art LC Review of draft-ietf-alto-performance-metrics-17

[Qin Wu <[e-mail]>]

Thank Elwyn for valuable comments.
Authors, please follow up and address Elwyn’s comments.

-Qin (with chair hat on)
发件人: elwynd [mailto:[e-mail]]
发送时间: 2021年9月12日 22:19
收件人: General Area Review Team <[e-mail]>; [e-mail]
主题: Gen-art LC Review of draft-ietf-alto-performance-metrics-17

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-alto-performance-metrics-17.txt
Reviewer: Elwyn Davies
Review Date: 2021/09/09
IETF LC End Date: 2021/08/02
IESG Telechat date: (if known) -

Summary: Not ready.  My major concern with the document is the lack of precision in various aspects that would be needed to ensure an automated system could interpret the requests and responses that are  added to the basic ALTO protocol by this document.

Major issues:
The various examples of 'link' parameters:  It is unclear whether these links would be useful in an automated ALTO system.  Would it be expected that an ALTO server would read the contents of the link pointed
to by the URL?  If so what structure would be expected?  This is particularly relevant in the 'estimation' cases where without a machine interpretable or set of standard mchanisms, the estimation option seems of minimal  use.  Do the authors anticipate that estimation methodologies might be standardized in the foreseeable future?   Similarly,  machine interpretable versions of SLA specifications are not something that sre conventionally available.

Minor issues:
s2.1, defininition of CostContext:  Given the name, I would expect that there could be more then one parameter specified.  For convenience and to make the information more machne readable, I would have expected the parameters to be passed over in a JSON object rather than an unspecified JSONvalue. [I observe that RFC 7285 does not define JSONobject.]   This particularly applies to the 'link' parameter case where the name and value need to be encoded.

s7, ALTO Cost Source Registry:  The specification for this new registry is incomplete.  The review mechanism for new assgnments plus the definitions of the two fields are needed.   It may also be worth considering whether this field really nedes a registry.  Can the authors think of any other possibilities that might arise?

Nits/editorial comments:

General:  An RFC is not an academic paper and the form 'We xxxx' is not used.  A depersonalised form such as 'In this document...' needs to b used instead.  There are three instances that need fixing
 (s2, para 2;  s5, para 2; and s8. )

Abstract:  I suggest here a number of minor wording chages to improve the abstract:
OLD:

   Cost metric is a basic concept in Application-Layer Traffic

   Optimization (ALTO), and different applications may use different

   cost metrics.  Since the ALTO base protocol (RFC 7285) defines only a

   single cost metric (i.e., the generic "routingcost" metric), if an

   application wants to issue a cost map or an endpoint cost request to

   determine the resource provider that offers better delay performance,

   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.



   There are multiple sources (e.g., estimation based on measurements or

   service-level agreement) to derive a performance metric.  This

   document introduces an additional "cost-context" field to the ALTO

   "cost-type" field to convey the source of a performance metric.
NEW:

   The cost metric is a basic concept in Application-Layer Traffic

   Optimization (ALTO), and different applications may use different types of

   cost metric.  Since the ALTO base protocol (RFC 7285) defines only a

   single cost metric (namely, the generic "routingcost" metric), if an

   application wants to issue a cost map or an endpoint cost request in order to

   identify a resource provider that offers a better delay performance,

   the base protocol does not define the cost metric to be used.



   This document addresses this issue by extending the specification to provide a variety  network performance

   metrics, including network delay, jitter, packet loss rate, hop

   count, and bandwidth.



   There are multiple sources (e.g., estimation based on measurements or

   service-level agreement) to derive a performance metric.  This

   document introduces an additional "cost-context" field to the ALTO

   "cost-type" field to convey the source of a performance metric.
END

s1, para 1: s/Cost metric/The cost metric/

s1, para 5 (first on page 5): s/related with bandwith/related to bandwidth/

s1, para 6: A refererence to RFC 7285 Section 9.2 should be given when the IRD is introduced.

s1:  Some pieces of terminology are carried over from RFC 7285, notably JSONxxxx and PID.  These, together with the various media types defined in RFC 7285 and used in examples, should be documented in s1.

s2.1, next to last para (above Figure 1): s/A potential architecture on estimating these metrics/A outline of potential information flows used for estimating these metrics/


Figure 1 title: s/A framework to compute estimation to performance metrics/A framework for computing estimations of performance metrics/


s3.1.3, para 1 and s3.3.3, para 1: A reference to RFC 7285 Section 5.1 should be given when introducing PIDs.


s4.3.4, last para: s/estimtation/estimation/

Sent from my Galaxy