Re: [alto] I-D Action: draft-ietf-alto-path-vector-04.txt

Qiao Xiang <xiangq27@gmail.com> Wed, 11 July 2018 01:39 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 B249C130EB2; Tue, 10 Jul 2018 18:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 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] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh1Eiv-M044B; Tue, 10 Jul 2018 18:38:59 -0700 (PDT)
Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) (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 61B94130DD6; Tue, 10 Jul 2018 18:38:58 -0700 (PDT)
Received: by mail-ed1-x543.google.com with SMTP id t2-v6so3313823edr.5; Tue, 10 Jul 2018 18:38:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sia+ryyKYmmDW4lNjwqkWcbdiZ2RLVuQdQH+xtUIHu8=; b=KrjDmFt+Wv0jzYDlqsPBVdXrWpHeWutFoQ48J4Wn8lmeXz4dTCiAWuSRcuJZ9jWsAm BpuDCZC7u/VxEf8gDww4jE+DKnX5aARfBbS35Aw4slJn6KZ+QJ6Sk3NfsbJOFM+RW+eT F03Cq1Yx5UlF+Kj61MbC1LgK2SImynOWCc/964Bq1109EOkGuRTbfyJ7PuW1MtxlpQcu IvZBFm5/SOmPnfW7+kxnEkGc5CvCMGAZ23No5ugv60M78YMMVZ+VdPnQTteMXeCFwi/L 31c4WoRtk1LBI+TvRfoZWtj1T7BE6FAs543umCSGYE4GQwX+hQJgHMfG1rFyH4cGjlgx 4Mjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sia+ryyKYmmDW4lNjwqkWcbdiZ2RLVuQdQH+xtUIHu8=; b=O2B0NH3zeBL0RGWS0EKpt7Fk1Mn2uVXZeKG8DjL/HU+0ZSHoa0wBgkrxsEvUpM/57I A3rqVRkjpbeox4ahfIJ8/96yM97ZNMC5LLNTfirvlnu009dNzzbSxXbmEy7er52kUZsd 67OWJq7P+EDcOY6qsdQBXOpoge6xFrjfiqq9YiGgwwu5rXToPb/1dU/6A0h4z1Xf8j3f ZO4VTHzrcKWz4E05cgGTyeus3BVsyLDkewv2niLqPnawsAaKDdd9v7XjPeprBnw1eQub kEgYnejz2WAsXLbXemJY/OU7hKo05tmjZb270UVdtNeMHFuJ2Org3JukudhtlPS3+Yui n4Yg==
X-Gm-Message-State: APt69E0tnmDitt5v2Q5iKgipk4MTKdHSXpqRkek5L5/7b+iPxBIgEi83 v6QkAmptkGLDEg6oMFZEu29HAiHi+PQ3ks9Wgs8=
X-Google-Smtp-Source: AAOMgpdReCATee8OAXk42+OXcKF6z3XpISFtz1zybwCseC9uIJLuElqw3b2hlxyVhs7oiDFdEZ15cNdzaYN4ybTbidg=
X-Received: by 2002:a50:8a66:: with SMTP id i93-v6mr4877969edi.281.1531273136840; Tue, 10 Jul 2018 18:38:56 -0700 (PDT)
MIME-Version: 1.0
References: <153056076382.16100.4380161360915504373@ietfa.amsl.com> <CAAbpuyre_LqPZOZRzmMt_TniSreLZ_UjnNvcpnsqv34vVooW1A@mail.gmail.com>
In-Reply-To: <CAAbpuyre_LqPZOZRzmMt_TniSreLZ_UjnNvcpnsqv34vVooW1A@mail.gmail.com>
From: Qiao Xiang <xiangq27@gmail.com>
Date: Tue, 10 Jul 2018 21:38:44 -0400
Message-ID: <CAOB1xS_8Z5MyBEutN4uA9tGNsOgy-NaQPKGEAr7HcttNnKuB3g@mail.gmail.com>
To: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Cc: internet-drafts@ietf.org, IETF ALTO <alto@ietf.org>, i-d-announce@ietf.org
Content-Type: multipart/mixed; boundary="0000000000006039f10570af4f66"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/qnIBXzFEiYxMDm9kvHLH53qbn_Y>
Subject: Re: [alto] I-D Action: draft-ietf-alto-path-vector-04.txt
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: Wed, 11 Jul 2018 01:39:05 -0000

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

I finished reviewing the first few sections (abstract and Section 1-4) of
the latest PV draft. The marked documents are attached in this email (with
mark "[qiao]"). More importantly, I want to raise the discussion on the
following design issues in this draft, to seek your feedback:

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
case?

It just occurred to me that 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 MUST be unordered
;
(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").

2. Handling multipath (and potentially multicast).

The current PV design does not handle multipath routing or multicast.
Richard suggested me take 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". For
example, assuming the flow uses 2 paths:

(ANE1 -> ANE2 ->ANE3 ->ANE4) and (ANE1->ANE2->ANE5->ANE4), then the ALTO
server tells the ALTO client that there are 3 route segments:

RS1: [ANE1, ANE2], RS2: [ANE2, ANE3, ANE4], RS3:  [ANE2, ANE5, ANE4];

It also tells the ALTo client 2 property maps. The first one is:

ANE1: { "availbw": 50 },
ANE2: { "availbw": 50 },
ANE3: { "availbw": 50 },
ANE4: { "availbw": 50 },
ANE5: { "availbw": 50 }

The second one is:

RS1: {"trafficloadpercentage": 1},
RS2: {"trafficloadpercentage": 0.6},
RS3: {"trafficloadpercentage": 0.4}.

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? If they reasonable to most of
you, may I suggest integrating this design into the next version of the PV
draft? Thank you very much.


Best
Qiao


On Mon, Jul 2, 2018 at 4:08 PM Jensen Zhang <jingxuan.n.zhang@gmail.com>
wrote:

> Hi all,
>
> In this revision -04, we do the following changes:
>
> - The major change is to decouple the multipart query service from the
> path vector.
>     - Instead, A capability called "allow-compound-response" is introduced
> to make the property map inline.
>     - The multipart query service is moved to a new document and defined
> for the general cases.
> - The examples section is revised to better explain the usage of the path
> vector extension.
> - The compatibility of the path vector extension is better clarified.
> - Some general discussions are raised.
>
> Looking forward to receiving your feedback.
>
> Thanks,
> Jensen
>
> On Tue, Jul 3, 2018 at 3:46 AM <internet-drafts@ietf.org> wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Application-Layer Traffic Optimization
>> WG of the IETF.
>>
>>         Title           : ALTO Extension: Path Vector Cost Type
>>         Authors         : Greg Bernstein
>>                           Shiwei Dawn Chen
>>                           Kai Gao
>>                           Young Lee
>>                           Wendy Roome
>>                           Michael Scharf
>>                           Y. Richard Yang
>>                           Jingxuan Jensen Zhang
>>         Filename        : draft-ietf-alto-path-vector-04.txt
>>         Pages           : 29
>>         Date            : 2018-07-02
>>
>> Abstract:
>>    The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285]
>>    has defined cost maps and endpoint cost maps to provide basic network
>>    information.  However, they provide only scalar (numerical or
>>    ordinal) cost mode values, which are insufficient to satisfy the
>>    demands of solving more complex network optimization problems.  This
>>    document introduces an extension to the base ALTO protocol, namely
>>    the path-vector extension, which allows ALTO clients to query
>>    information such as capacity regions for a given set of flows.  A
>>    non-normative example called multi-flow scheduling is presented to
>>    illustrate the limitations of existing ALTO endpoint cost maps..
>>    After that, details of the extension are defined.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-alto-path-vector-04
>> https://datatracker.ietf.org/doc/html/draft-ietf-alto-path-vector-04
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-path-vector-04
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
>>
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>


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