Early Review of draft-ietf-alto-performance-metrics-03

Request Review of draft-ietf-alto-performance-metrics-03
Requested rev. 03 (document currently at 08)
Type Early Review
Team Transport Area Review Team (tsvart)
Deadline 2018-03-17
Requested 2018-02-17
Requested by Jan Seedorf
Authors Qin Wu, Y. Yang, Young Lee, Dhruv Dhody, Sabine Randriamasy
Draft last updated 2018-04-09
Completed reviews Tsvart Early review of -03 by Brian Trammell (diff)
This document extends the ALTO protocol (RFC7285) with additional costs metrics to be conveyed via an ALTO service. There have been discussions in the ALTO WG whether such performance metrics are reasonable as costs to convey via a service such as ALTO. Potential issues could be (in no particular order): clarity of semantics (e.g. what does it mean if the RTT between two endpoints is x?, is this the average over the last 24h?, last year?, etc.), introduction of feedback loops (e.g. endpoints could select different peers or caches to download from based on metrics that change rather quickly and such a selection could effect the metric result itself in the very near future), privacy considerations (certain metrics might reveal too much about an endpoint, e.g. a high bandwidth Internet connection might reveal something about the endpoint owner's financial situation).

For all the metrics introduced in the document, we would thus appreciate an outside-expert-view: does it make sense to convey such a metric via the ALTO protocol?

Many thanks in advance,
Jan & Vijay (ALTO chairs)
Assignment Reviewer Brian Trammell
State Completed
Review review-ietf-alto-performance-metrics-03-tsvart-early-trammell-2018-04-09
Reviewed rev. 03 (document currently at 08)
Review result On the Right Track
Review completed: 2018-04-09


I've performed a (late, apologies) early TSV-ART review of draft-ietf-alto-performance-metrics-03. 

The set of metrics chosen by the document seem broadly useful and sane, and the integration into ALTO makes sense. However, there are a few issues with the details.

Periodic One Way Delay, RTT, and PDV are defined in terms of section 8, section 4, and section 5, respectively, of draft-ietf-ippm-initial-registry, which specify active measurement test methodologies at layer 4 for one-way and round-trip delay using UDP packets. This does not seem it can be measured directly using the routing  technologies the authors have identified as their source of information. Is the intention that dedicated active measurement hardware be used to measure delay using UDP packets, or should these metrics reference [RFC2679] and [RFC2681] and leave the methodology undefined, instead?

The examples for these don't make much sense: the units are expressed in seconds, but Internet-scale delays are generally millisecond-scale, and the examples given contain only integers. Similarly, packet loss rate is given in percentile, but there are wide variations in usability between a path with 0%, 1%, and 2% packet loss. Is this simply an issue with the examples?

The hop count metric is underspecified: are these IP-experienced hops at layer 3, as can be measured by traceroute? 

Nit: section 2.1 refers to [OSPF-TE], [ISIS-TE], [BGP-LS] and [BGP-PM], but these are not listed as such as references in the references section. Please use consistent reference labels.

Thanks, cheers,