[alto] Path Vector final touch

"Y. Richard Yang" <yry@cs.yale.edu> Mon, 19 March 2018 13:35 UTC

Return-Path: <yang.r.yang@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B6F251242F5 for <alto@ietfa.amsl.com>; Mon, 19 Mar 2018 06:35:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.42
X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id iqEI-Mp0UeMg for <alto@ietfa.amsl.com>; Mon, 19 Mar 2018 06:35:39 -0700 (PDT)
Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9FB124BFA for <alto@ietf.org>; Mon, 19 Mar 2018 06:35:39 -0700 (PDT)
Received: by mail-lf0-f51.google.com with SMTP id p142-v6so2768594lfd.6 for <alto@ietf.org>; Mon, 19 Mar 2018 06:35:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xzrFzB5yerpQGkfim6Duzl7ZOIUmUhEOQ8u3dITVXvA=; b=tKdpxMKFw0rDi4+C4zPv+W0PybKCs81MdLMp91gS8sYKIMmaB1nwpTxe3qPrBbEC1Q r3krmkH8v1BmF1CEGrKnvaaJQbDRoOBXElxLYHSaSOfHNOzwoVpyOzKu58d5eR89Zdom p7YaL/+6Oc8d55orx75bUe2ckHPHCdVw5d/71fRLUyDE8MTtoRSOMEspJmrIULMbJpsE UVg46e+9mywkZKdrFZ2Olr2ZHTzgDezVKnenXPWfCRHxJNU7a1fzeqGgoFV8Snp8W8MO zf0td6MVe81imi5S0moBOxqd2EacRzy90JvFyjn24mfskrbCcx6CdNh1HYs5ccEc/XDx k2kg==
X-Gm-Message-State: AElRT7E4dIZMqqA4bopb+ECLVifLWsgJFRb5dirXq03clSMUSMWfU/72 rhtMmhUnsQYfbuNv0K/7QtoNvLXG7ENt2GthDNg=
X-Google-Smtp-Source: AG47ELthBE1apBI7ZPkAWftF6I3mzJzSvnRThe2RVmkTjM+Vc4fq/255HgKx8c4z91pp4J7MY5MbKIxLHXHf4sPVMVo=
X-Received: by with SMTP id a21mr8417467ljf.138.1521466537151; Mon, 19 Mar 2018 06:35:37 -0700 (PDT)
MIME-Version: 1.0
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Mon, 19 Mar 2018 13:35:25 +0000
Message-ID: <CANUuoLoGYw013gLsFL=bmZ_t+FMrzByugaouWmZu+i4U86YK5w@mail.gmail.com>
To: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1ab6767c13010567c408aa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/-GJX1y0cl-qm_RctUdle52zqEUA>
Subject: [alto] Path Vector final touch
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Mar 2018 13:35:42 -0000

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.