Re: [alto] Path Vector final touch

Qiao Xiang <> Mon, 19 March 2018 15:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67F9A12DA46 for <>; Mon, 19 Mar 2018 08:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vYGMhKcpXSzV for <>; Mon, 19 Mar 2018 08:02:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E5B412D9FE for <>; Mon, 19 Mar 2018 08:02:17 -0700 (PDT)
Received: by with SMTP id 139so16424994wmn.2 for <>; Mon, 19 Mar 2018 08:02:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rrLxEPNYD6NJdzGWcYNSKYuhBwq63iGTk8pc5nP+I3A=; b=oBk0vCEaEvZwKIR/SStr56dpgUPOFZ0sc/NYbxsO12lApSu0PEeNJRRQ+dIuXP1vF4 /ralXYIeXXJA2NpcND6ElCExIKVh3QSZ7p+KYogPPvW+NlVgujUR1F7/zz1QdbIoehgA gDomu1DLjy+q4QPHhSlHCQuM8LLjTMXh+nW1Vlw45aPZkf23BhtL0/DZUd3j8tU6MgdA xtNPvDhSwaOeZniYrHAaar5EJh2Unbryir1IcyxULxBEs2XozsniNEHjzCxMHpwEs46E +RMGzpMrkslM2DAx7Fb6oX58Ebk60DWpQ80YYewn67xXVdmtORga4lnedqP+2f+T0H3k 2wlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rrLxEPNYD6NJdzGWcYNSKYuhBwq63iGTk8pc5nP+I3A=; b=r3JINx4x3lv4SAVYB7pA5vly10R05LHM17qhRzl7xfNMMIGlA9pfZKCopR3IQXhuvn wMzl5LMEAW6lMXyAupgqh1wE0fo4wCXXZWWT/x1cHk4OPIoQZWK6yw/3tE5A+6hkmqSr fnr8KfKI0h9gvsODJrKTTd3BGk8wEzFpfZEzPyKQLS3U29/wPT9g7osp9kooNu9iKdof hP2myxNqSgHp3BEsz2evRooy5SBwiqgVtz3fLI/xAVUC6Ai8G7qlCeK8V6KW8VVBfr/O HZbTodtqwVxMaTtHV7KpMshn+7Nv8VuAPFAy0PObdQ2yygxU+0iC+RziUGMgzKt4GkXB UBvA==
X-Gm-Message-State: AElRT7GX56I51Tu1awG6g/Q0Tpml96YMlyai4FQWYlCZxEXikhkpkXKg 8z8UjHseEX/DERzpvnmzqpadQEMEezUfSxbLBXGlXw==
X-Google-Smtp-Source: AG47ELsv+iHBFoMQ7m5Ms/I429LF6ieh1gtsociAZDdzSen519SGPna+3ou4oTXAWaP3oW4ZJ35ROGe73EoyvV0tU34=
X-Received: by with SMTP id v4mr13464579edf.293.1521471735632; Mon, 19 Mar 2018 08:02:15 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 19 Mar 2018 08:01:55 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Qiao Xiang <>
Date: Mon, 19 Mar 2018 23:01:55 +0800
Message-ID: <>
To: "Y. Richard Yang" <>
Content-Type: multipart/alternative; boundary="94eb2c1c5b1c5698630567c53e39"
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:02:22 -0000

Hi Richard,

I also want to add a side note on the PV draft. I see that in Section 10.1
the privacy concern of PV is discussed and the network is suggested to
provide protection mechanisms when application and network are not in the
same trust domain. I wonder if the draft should be more specific on what
mechanisms can be used and the corresponding trade-offs? One strawman is to
let the network return a slightly smaller capacity region in the cost and
property map.

I'm not sure how important such privacy concerns can be for wrapping up the
draft, or the simple discussion in the current write-up is already
sufficient, just trying to throw in my two-cent. :-)


On Mon, Mar 19, 2018 at 9:35 PM, Y. Richard Yang <> wrote:

> 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.
> Cheers,
> Richard
> --
> Richard
> _______________________________________________
> alto mailing list

Qiao Xiang
Postdoctoral Fellow,
Department of Computer Science,
Yale University