[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