Re: [alto] Here is a review of draft-ietf-alto-performance-metrics-01

Qin Wu <> Thu, 29 June 2017 09:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1C1312ECCE; Thu, 29 Jun 2017 02:44:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0fKMvXcyiEwm; Thu, 29 Jun 2017 02:44:02 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 37FB512ECBC; Thu, 29 Jun 2017 02:44:01 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DQA74692; Thu, 29 Jun 2017 09:43:59 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 29 Jun 2017 10:43:58 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Thu, 29 Jun 2017 17:43:52 +0800
From: Qin Wu <>
To: xin wang <>, "" <>
Thread-Topic: Here is a review of draft-ietf-alto-performance-metrics-01
Thread-Index: AQHS77KHjlFF1/I4VEOSeLJnKnux4aI7lZ+w
Date: Thu, 29 Jun 2017 09:43:51 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9A98C73Cnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5954CBDF.014B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: af2ec23c730ef40819d9c5ea70052ec3
Archived-At: <>
Subject: Re: [alto] Here is a review of draft-ietf-alto-performance-metrics-01
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: Thu, 29 Jun 2017 09:44:05 -0000

Thanks Xin, see reply inline below.
发件人: xin wang []
发送时间: 2017年6月28日 10:06
主题: Here is a review of draft-ietf-alto-performance-metrics-01

Dear authors of "ALTO Performance Cost Metrics”,

Your draft about extending cost metrics of ALTO looks very useful, especially for varieties of applications with different criteria to make decisions for traffic engineering. The following is a review of your draft:

a. Link Maximum Reservable Bandwidth and Link Residue Bandwidth

These three cost metrics look very similar but have different meanings according to your draft. In my understanding, based on the concept of bandwidth oversubscription, a reserved bandwidth could be larger than current remaining bandwidth (equals to max bandwidth subtract the sum of all reserved bandwidth). Then, Link Maximum Reservable Bandwidth should be slightly larger than Link Residue Bandwidth. Is this right?

[Qin]: Short answer is Yes. Long answer is:

Residbw = maxbw -  tunnel reservation bw

Maxresbw can be larger than maxbw if the link is oversubscirbed

Therefore Maxresbw could be larger than Residbw.

b. Unitless performance scores

In section 2.1, the draft suggests providing unitless performance scores for privacy issues. In ALTO cost mode, it defines “ordinal” which indicates the ranking of the cost values instead of actual costs. Do you suggest to add more intelligent abstraction of cost values besides of ranking?

[Qin]: I think adding more intelligent abstraction of cost values besides of ranking useful, but we need to identify use case to show deficiency of ranking before introducing new intelligent abstraction.

c. Packet Delay Variation

The draft uses the minimum delay observed as the definition of packet delay variation. I am not sure it is a good solution. There are some other approaches you may consider, such as standard deviation.

[Qin]: The minimum delay  observed is just used as reference delay, see the complete definition as follows:

   Metric name:
      Packet Delay Variation
   Metric Description:
      To specify spatial and temporal aggregated jitter (packet delay
      variation) with respect to the minimum delay observed on the

      stream over the specified source and destination.


You are right, standard deviation will be used.

d. The unit of Periodic One Way Delay

The draft uses seconds as the unit of Periodic One Way Delay. I am not sure it is typos or not since the example shows the powdelay cost values are 10, 20, and 30.

[Qin]: It is not typo, it is intended. See section 7.4.3 of draft-ietf-ippm-initial-registry-03.

We don’t define any new metric with new measurement unit here.

Also there are some typos you may fix:

Abstraction: add space between "BGP-LS,OSPF-TE";

Page 2: “delay sensitive” -> “delay-sensitive”;

Page 2: “a set new” -> “a set of new”;

Page 2: “ explicitely” -> “ explicitly”

Page 4: “ invlove” -> “ involve"

[Qin]: Fixed, thanks.