Re: [alto] Tsvart early review of draft-ietf-alto-performance-metrics-03

Qin Wu <> Sat, 21 April 2018 06:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CC44127775; Fri, 20 Apr 2018 23:14:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OMOUD8wMRS2M; Fri, 20 Apr 2018 23:14:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B47C5124217; Fri, 20 Apr 2018 23:14:52 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 5C3A44D211CC; Sat, 21 Apr 2018 07:14:48 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 21 Apr 2018 07:14:49 +0100
Received: from ([]) by ([]) with mapi id 14.03.0361.001; Sat, 21 Apr 2018 14:14:45 +0800
From: Qin Wu <>
To: Brian Trammell <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Tsvart early review of draft-ietf-alto-performance-metrics-03
Date: Sat, 21 Apr 2018 06:14:45 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [alto] Tsvart early review of draft-ietf-alto-performance-metrics-03
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 21 Apr 2018 06:14:55 -0000

Apologize for late reply. Thanks for valuable review.
发件人: Brian Trammell [] 
发送时间: 2018年4月10日 0:36
主题: Tsvart early review of draft-ietf-alto-performance-metrics-03

Reviewer: Brian Trammell
Review result: On the Right Track

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?

[Qin]: I think measurement method is not limited to using routing technology as source of information, we also allow using other source of information, e.g., active measurement at layer 4, that allow an ALTO Server to retrieve and derive the necessary information to compute the metrics that we describe in this document.
I will make this clear in the text. Thanks.

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?
[Qin]: The reason to express units as seconds is to align with measurement unit defined in e.g.,one way delay metric defined in draft-ietf-ippm-initial-registry, I think you are right, we can redefine more fine granularity measurement unit in this document. For packet loss rate, this is just an example, we can provide an example that more make sense.

The hop count metric is underspecified: are these IP-experienced hops at layer 3, as can be measured by traceroute?
[Qin]: Yes, you are right, traceroute is one mechanism we can leverage to measure hop count, e.g., sending UDP probe message, I can add more detailed text o specify hop count.

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.

[Qin]: Fixed, thanks.

Thanks, cheers,