[alto] Review for draft-ietf-alto-path-vector-11
Qiao Xiang <xiangq27@gmail.com> Sun, 11 October 2020 09:32 UTC
Return-Path: <xiangq27@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA7C3A00F7 for <alto@ietfa.amsl.com>; Sun, 11 Oct 2020 02:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBa-_jKlbaqI for <alto@ietfa.amsl.com>; Sun, 11 Oct 2020 02:32:18 -0700 (PDT)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 857D23A00E5 for <alto@ietf.org>; Sun, 11 Oct 2020 02:32:18 -0700 (PDT)
Received: by mail-ot1-x334.google.com with SMTP id m13so13054083otl.9 for <alto@ietf.org>; Sun, 11 Oct 2020 02:32:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0QJSp5yujoPZ2OQURfuzNkgAPqwYqUXKbyW4Eh/PLUI=; b=FS0aGOgsMozZINg20JvnvknF1oymXfzznPI6+yoC0v2TJC8WyIzNvSliL4zvpCBeOx z9ReEsrlLU0BUAeOLC4U0X6sayRWOtU0Jm+JZ12lR/2OFEYiKl90hHtVdoVy1EoW2yI5 wGojoghOMz6PR5sDILImoIrL0YqmTdCkST+Aupo0a8HQ5hgFdxnnNDY9IvMRS3U2aEZV Xq6xsvdGjvfiaJBs3KRVPTtIRBSGZ98V5JrtzgvSbYE0KuruZ1HOxpUP4iO/I+D777qJ Ob/Qs+5doSIA1L2g5vbFkdGIOckuUHt3BBP1rbnVaulSXkjUIYI+IOwZdJ6MEku54GTB 4Tdg==
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=0QJSp5yujoPZ2OQURfuzNkgAPqwYqUXKbyW4Eh/PLUI=; b=Snmco6bA6DgWceyBaEzrXzUtkL73o4wIe0HPhcoXBwA+PlpaDe7dM5iJP0sW36o18F gSFUjSSQN1938DplUHQBBfmWE0UHC6UGRBIA4BEn40eSG/r0kZn6H0/ts01n+IUQwuWG 9ocamcfLZ0nbEJE/svXlMq4TDQHgamHdnl8dY38rml2dnmOSit00ty1Ek8cegTT7PNx9 5ljE7pUQHMcyJq6Ff9kFDOp3dhWJAGblWo9guxb8DwlUTNXg4P85YMSLls0ocbStrE+W KldzIEpp4Fs/6Z2ogWSmlRzCP4PLQ0Ks429MtpA8kPOkCs0pOSN9r4B1AW9RhH80G8TK EhPQ==
X-Gm-Message-State: AOAM531woWfMdbYHNvezzrDeBl4A9FcPZRgPnh8pbxHbOiOqJYPiu0Q/ mS/Yj9xlEKwmkyQOvxwqA0Q25bbKkX5899BaIf/SDDcs/HPXtrvq
X-Google-Smtp-Source: ABdhPJwHhW/U7pBo5HZ4w7mxyr2ccGkpcYMurXICMoFkqvzhVp3gth2y7QHPcXYrN66ZtiwHh4QExyheLUK/zKGgq5g=
X-Received: by 2002:a9d:4e8f:: with SMTP id v15mr13870180otk.121.1602408737274; Sun, 11 Oct 2020 02:32:17 -0700 (PDT)
MIME-Version: 1.0
From: Qiao Xiang <xiangq27@gmail.com>
Date: Sun, 11 Oct 2020 17:32:06 +0800
Message-ID: <CAOB1xS-s-FrWBhN_hLTcP-GWd8quFoD2M14SHgVtUDDrZb6wyg@mail.gmail.com>
To: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000091ffb505b161dbde"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/uwFNjekGcc3zMdSKleHU7eIdsW4>
Subject: [alto] Review for draft-ietf-alto-path-vector-11
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 11 Oct 2020 09:32:21 -0000
Dear all, The following is my review of the current version of the path vector draft. I do not have major objection about the design. The review consists of two parts: presentation and clarity of the draft, and design issues. Hope it helps. *Presentation and clarity of the draft*: 1. In Abstract: "on particular network components or elements", it looks like the word element is no longer used in the remaining of the draft, hence should be removed. 2. What is network component? The draft did not give a clear definition. In Abstract, it says "Examples of such abstracted components are networks, data centers or links.", and later in Section 3, it says "An Abstract Network Element is a representation of network components. It can be a link, a middlebox, a virtualized network function (VNF), etc., or their aggregations." I would suggest a clear definition about network component in Section 3. 3. Mixed use of "network component" and "intermediate network component". For example, in Section 3, it says "An Abstract Network Element is a representation of network components.", but in Section 5, it says "introduces Abstract Network Element (ANE) as the abstraction of intermediate network components". There are a couple of more spots of this mixed use throughout the draft. 4. In Abstract: "Each ANE is defined by a set of properties.", but in Section 3: "In a response, each ANE is represented by a unique ANE Name." Which one is the intended definition? My understanding is that the one in Section 3 seems more appropriate. 5. In the example in Section 4.1, eh3 does not seem to be used anywhere. I would suggest removing it to make things simple and clean. *Design issues*: The first two issues I have are the questions I asked previously in the mailing list under the thread "[alto] Comments on the Path-Vector draft during IETF 102" in August, 2018 ( https://mailarchive.ietf.org/arch/msg/alto/rt0t_K-PuWcTiIlEn6XuTdpGL48/). I did not see these two comments appropriately addressed/discussed in the current draft: 6. The semantics of "array of ANEs". In particular, in Section 3, it says "(The path vector) conveys the information that the path between a source and a destination traverses the ANEs in the same order as they appear in the Path Vector." Must we require this traversal order in the response? Taking the maximal bandwidth example we have always been using, does the user need the traversal order of ANEs? Would enforcing such an order increase the implementation complexity of the PV extension? In a response email from Jensen in the same thread, he said we may add strong use cases to motivate the necessity of "array" semantics, but it does not seem to be added in this draft. 7. Handle multipath (and potentially multicast). In my previous email, I give a proposal to address this issue in PV, which is motivated by RFC7911 ("Advertisement of Multiple Paths in BGP"). Jensen replied that it may be better to consider handling multipath in a separate document, but I want to use this review opportunity to ask the opinion of all WG members about this issue. Next, in Section 11 (security consideration), I have two more comments. 8. For the measures to mitigate the risk of exposing fine-grained internal network structure, in some earlier papers by our WG members [1, 2, 3, 4], we already proposed certain mechanisms to mitigate this risk, i.e., a minimal-feasible region compression algorithm [1, 2] and a feasible-region obfuscation protocol. I would suggest the draft adding these references. 9. for the discussion on the availability of ALTO services, I disagree with the sentence "It is known that the computation of Path Vectors is unlikely to be cacheable, in that the results will depend on the particular requests (e.g., where the flows are distributed)." In [3, 4], we already proposed a precomputation-and-projection mechanism to improve the scalability and availability of the PV service. As such, I feel this issue is not introduced by PV, but rather an inherent issue of the ATLO protocol. [1] Kai Gao, Qiao Xiang, Xin Wang, Yang Richard Yang, Jun Bi: NOVA: Towards on-demand equivalent network view abstraction for network optimization. IWQoS 2017: 1-10 [2] Kai Gao, Qiao Xiang, Xin Wang, Yang Richard Yang, Jun Bi: An Objective-Driven On-Demand Network Abstraction for Adaptive Applications. IEEE/ACM Trans. Netw. 27(2): 805-818 (2019) [3] Qiao Xiang, J. Jensen Zhang, X. Tony Wang, Y. Jace Liu, Chin Guok, Franck Le, John MacAuley, Harvey Newman, Yang Richard Yang: Fine-grained, multi-domain network resource abstraction as a fundamental primitive to enable high-performance, collaborative data sciences. SC 2018: 5:1-5:13 [4] Qiao Xiang, Jingxuan Jensen Zhang, Xin Tony Wang, Yang Jace Liu, Chin Guok, Franck Le, John MacAuley, Harvey Newman, Yang Richard Yang: Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Domain Network Resource Discovery. IEEE J. Sel. Areas Commun. 37(8): 1924-1940 (2019) Best Qiao -- Qiao Xiang Associate Research Scientist, Department of Computer Science, Yale University