[alto] Comments on the Path-Vector draft during IETF 102

Qiao Xiang <xiangq27@gmail.com> Tue, 07 August 2018 20:49 UTC

Return-Path: <xiangq27@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 056791310D7 for <alto@ietfa.amsl.com>; Tue, 7 Aug 2018 13:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.739
X-Spam-Status: No, score=-1.739 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_NONE=-0.0001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id pPUdra-Lxv_P for <alto@ietfa.amsl.com>; Tue, 7 Aug 2018 13:48:57 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 00D391310D4 for <alto@ietf.org>; Tue, 7 Aug 2018 13:48:55 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id h4-v6so226867edi.6 for <alto@ietf.org>; Tue, 07 Aug 2018 13:48:55 -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=XP1v9td8xdXKXSa+i9iGI33No4H8HEyYxR5AGWkRYlg=; b=t2EuWlyx3OsusFXw6a8YyyFKj9++Q6Av7DSf2MFr+71BWzHTi6OExWL4+I7163YuEJ JQnwdD4RYF3EpWzcbD8eFqtEgYFcwgsj/hPOAZesPbuoG6Be6ftZEDWRlpMBLwi/iUcs /G4yIqDWQdnbz/YWJUdQWUcItSFsXQNtHaA4ZAYLe4XMP0gMNLiJTh8YN5UwXyqnuufr ZBo1asQEdbSbxwC+gWt3jUtGobkImZjp2OcXWiXs9mK4GA6ieRvT5w6LI0nkieS6V4z7 YfoKk0gWqQdznK111pMBbZOmnSeNKij10YpzQLzavnGlxQL/N1XlZcpMKyM7ruPgir5P vEGQ==
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=XP1v9td8xdXKXSa+i9iGI33No4H8HEyYxR5AGWkRYlg=; b=MXvj3eTunHbHL7u2Vsk/N4YH+qbzIVCIJHwJvwqkMxJWYnHQIvuyuUs08MVs+jgiWa P7tcYrMp4LiiKz1h52r++wtQQD3N7NByF81J7FX9nlXrPSyx9SeDUO7xfM1yBkicBlmv /LofwE+KbbFU5QjhxLb8YGKf9Bxy3YWgzLkWwpsuU3Kuxg7l66/v2c1LPd+1YF3xwx0m Jif7oNkTz+SrmhP0hZCz9p8Ny0t64Mn6zoLqE55l43eCH7GhVHHJaDTafg168SrS3qZC RJFI3I8/FhXDd5TYYsCBL8n+27CtsxCtya78S2YtuRzIS7la16LEo3nj27uLk7WkvsK6 JxjA==
X-Gm-Message-State: AOUpUlHYHCL3V470dLHg7GjsJTJ1cxLC6wuVfzqtox0XFLBUCJjZoQCS rFwccF47Rr8T/FB2bH0T9YwwK/qm9AXXJseMLc4H/Mvoz5w=
X-Google-Smtp-Source: AAOMgpduOVRo9fnIi45TD0ZfVBxkJd+98WHhBvgPOPJ6VF+Qr9UYp8f76HPDg10q618FFkX23Mj4kuLiznPOsY4vnqo=
X-Received: by 2002:a50:b2c6:: with SMTP id p64-v6mr24034199edd.293.1533674933251; Tue, 07 Aug 2018 13:48:53 -0700 (PDT)
MIME-Version: 1.0
From: Qiao Xiang <xiangq27@gmail.com>
Date: Tue, 7 Aug 2018 16:48:41 -0400
Message-ID: <CAOB1xS8rD9D4kaNNu+9PLin9Q7R69sx036xjvnwj4wV7Nv=o2Q@mail.gmail.com>
To: IETF ALTO <alto@ietf.org>
Content-Type: multipart/mixed; boundary="0000000000009a18cb0572de8582"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/rt0t_K-PuWcTiIlEn6XuTdpGL48>
Subject: [alto] Comments on the Path-Vector draft during IETF 102
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 07 Aug 2018 20:49:01 -0000

Dear authors of the PV draft and the ALTO WG members,

Before and during IETF 102, I raised a couple of issues about the path
vector draft: (1) why we use a vector of abstract network element (ANE)?
and (2) update the current PV design to support multicast/multicast. It was
suggested during IETF 102 that we move this discussion to the mailing list.
Hence the following are my opinions in detail:

*1. The design choice of using "array/sequence/list of abstract network
elements (ANEs)".*

We all know that the concept "path vector" in this draft was highly
motivated by BGP, a path-vector interdomain routing protocol. In BGP, a
path vector encodes an AS path, which provides the semantics that to reach
a destination IP prefix, which ASes will be traversed in what "order". The
AS-path vector has semantics: (1) the first one in the vector is the
neighbor AS providing this route, (2) the last one is the destination AS
providing the destination IP prefix, (3) The ASes in between help provide
information about inter-AS connectivity. In contrast, a path vector in ALTO
is an ANE-path. What semantics does it have? In order words, why does the
order of ANEs matter? One may argue that it may help provide information
like "a flow will pass through a firewall middlebox before entering a DPI
middlebox", but why would a network operator want to provide such detailed
private information to the application? Is there a strong, reasonable use

In Danny's multi-domain broker draft tries to use the PV extension to
provide the AS-path information for different NFs. This may be a strong
case to use the array of ANEs, instead of a set of ANEs, in the PV draft.
However, such information is already provided by BGP and will be the source
of an ALTO server getting such information, why is ALTO better than BGP at
providing such information?

I see 3 ways that we can proceed:

(1) we keep the current design, and provide strong use cases in the draft
to justify "array of ANEs" is necessary, and explicitly state that the
application MUST recognize that the returned array of ANEs MAY be
(2) we keep the current design, do not provide strong use cases to justify
this design, but explicitly state that the server MAY return the array of
ANEs unordered;
(3) we change the design from "array of ANEs" to "set of ANEs" (i.e., cost
mode changed from "array" to "set"). Given that all specifications in ALTO
are specified using JSON format, which does not have a concept called
"set", this design choice may seem a bit strange. However, I believe that
we should not let the specification language used by the WG affect the
semantics of the design.

*2. Handling multipath (and potentially multicast).*

The current PV design does not handle multipath routing or multicast. Per
suggestion from Richard, I took a look at how BGP handles multipath, given
that PV was highly motivated by BGP. I found RFC7911 ("Advertisement of
Multiple Paths in BGP") provides the solution. And the basic idea is very
simple: in BGP announcement, assigning an ID (path identifier) to the
route. This motivates me to propose the following design to let the PV
extension support multipath.

Consider a source-destination pair (a flow), its route (no matter
single-path route or multipath route) is essentially a set of route
segments. When the ALTO client submits a PV query about this flow to the
ALTO server. Instead of returning an array of ANEs, the ALO server returns
a set of arrays of ANEs, where each array represents a route segment in the
route of this flow and is assigned a unique ID. These IDs are also sent to
the ALTO client. In addition to the property map of all ANEs used in these
route segments, the ALTO server also sends another property map of all
route segments, where the property is "traffic load percentage".

I intended to talk about this design during the IETF 102 meeting, however,
given my unstable internet connection, I had to omit this part. Slide 4-6
in the attached presentation illustrates this design with an example. I
believe this design perfectly provides accurate, compact information of
resource sharing in multipath routing. It can also handle the resource
sharing defined by TE policies, and can potentially provide such
information in multicast, provided that the query format supports a query
on multicast flow.

What do you think about these two issues? It would be great to hear the
opinion from not only the authors, but also other WG members. If they are
reasonable to most of you, may I suggest integrating them into the next
version of the PV draft? Thank you very much.

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