Re: [alto] Path Vector final touch

"Gao Kai" <> Mon, 19 March 2018 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1C46129C56 for <>; Mon, 19 Mar 2018 08:28:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id he36Zh6LbfnD for <>; Mon, 19 Mar 2018 08:28:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 62E74127871 for <>; Mon, 19 Mar 2018 08:28:48 -0700 (PDT)
Received: by ajax-webmail-app-1 (Coremail) ; Mon, 19 Mar 2018 23:28:45 +0800 (GMT+08:00)
X-Originating-IP: []
Date: Mon, 19 Mar 2018 23:28:45 +0800 (GMT+08:00)
X-CM-HeaderCharset: UTF-8
From: "Gao Kai" <>
To: "Y. Richard Yang" <>
Cc: "IETF ALTO" <>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version 5.0.4 dev build 20171117(fcd8b4ed) Copyright (c) 2002-2018 tsinghua
In-Reply-To: <>
References: <>
Content-Type: multipart/alternative; boundary="----=_Part_145104_237452996.1521473325800"
MIME-Version: 1.0
Message-ID: <>
X-Coremail-Locale: en_US
X-CM-SenderInfo: 5jdryi2s6ptxtovo32xlqjx3vdohv3gofq/1tbiAgEJCFEw9TGr4A ABst
X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU=
Archived-At: <>
Subject: Re: [alto] Path Vector final touch
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: Mon, 19 Mar 2018 15:28:52 -0000

Hi Richard and WG,

On Issue 1:

My personal opinions on Issue 1 are:

1. Both work in a single query and Approach 2 may look simpler.
2. However, Approach 1 eliminates the need to "name" the property map. Thus, it may work with the current SSE extension much more easily: Issue 2 will not even be raised.

On Issue 2:

The anonymous functions (at least in JVM-based languages) are not really "anonymous" -- the compilers name the functions internally. Applying the similar method in ALTO, anonymous resources should be those temporarily generated by a query and should be automatically named by the ALTO server.

There are three approaches.

1. Use "resource-id" in "vtag".
The easiest way seems to force a "vtag" field be included in ALL responses and the ALTO Server fills in the "resource-id" field for each "anonymous resource". However, it does not work with Filtered Network Map.

2. Use the combination of "resource-id" and "tag".
Might be tricky when using SSE, such as for a combination of Network Map and its corresponding Filtered Network Map together.

3. Add a new field.
Seems like the most clean way.


One concern is that the benefits of anonymous resources are not that obvious at the moment. If we ever choose to introduce anonymous resources, my preference would be 3, 1, 2. And only in that case should we prefer Approach 2 in Issue 1.

Best Regards,

-----Original Messages-----
From:"Y. Richard Yang" <>
Sent Time:2018-03-19 21:35:25 (Monday)
To: "IETF ALTO" <>
Subject: [alto] Path Vector final touch

Dear members of WG,

This is a friendly update from the authors of the path vector draft. To be up front, we are wrapping up nicely on defining the new cost type (cost-mode: array, cost-metric: ane) and the  new domain. These, however, are only two of the three building blocks. The third building block, on integrating the cost map and the property map, however, still needs final touch. During the design, the LHC/esnet use case and the software defined coalition use case provide strong support for the benefit of the path vector capability. On the other hand, they result in more diversity in the supported scenarios.

In a nut shell, the key issues are two:

1. How to handle compound data: cost map, endpoint cost map, and property map are all already defined. What PV needs is an integration. There are two approaches: (1) absorption reuse, in that we define a specific new type and import the existing types to build a new, single top-level object; (2) independent reuse, in that we allow the existing objects to remain independent and hence the system now consists of multiple top-level objects. The current design, using multipart, is (2), but some authors have a strong preference on (1).

2.. How to (Do we) handle “anonymous” resources? In several use cases, the property map is specific to the cost map. Hence, it should not be considered as an independent resource. Just as Java and some other languages support anonymous functions (e.g., some event handler), we can benefit from such a support. The authors are discussing the final wording.

Any expert opinions will be greatly appreciated, as we wrap this draft to finish all chartered items sooner.