Re: [alto] Some considerations about path vector design

Jensen Zhang <jingxuan.n.zhang@gmail.com> Tue, 27 June 2017 09:10 UTC

Return-Path: <jingxuan.n.zhang@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 D182E12EC03; Tue, 27 Jun 2017 02:10:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 yUI91zN6XCtD; Tue, 27 Jun 2017 02:10:58 -0700 (PDT)
Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 E2D72127275; Tue, 27 Jun 2017 02:10:57 -0700 (PDT)
Received: by mail-ua0-x22e.google.com with SMTP id j53so14779628uaa.2; Tue, 27 Jun 2017 02:10:57 -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=RxKIJj3LevfjrMRN/wHrnXu/BSvPUGTXyCZoAx6AIPQ=; b=HGaOP6kkuhbQ+RUhwARhb3+xtNIvSXhXOYGiCKnSgdEjC+/MyB2Kh94iZhRAJpGWpP MkZoyd6xHA6poujW9JoOJxVT55qoea+ZBgZ3ZSZBbL9jN529/wz+tzQvZVBYglyu/gfI vwyEKr0Z1gtZgGyMRwtEhyokB73SD36qk947lH/t8GHVANCJE8AzgtCcfHGmLjyy4ZUG 70UOhmqpFHyLlfklF+pXDzZP0hZzqKgoFdma99s1DRMBMvY/fW+0bqb+TLvhT3DPo43I NGlEbbg9mRKF/ptaVqN9mQV1N18M8W7S7Yv3UNOa67M+VUJZA3DMGsMwztd0BdcCPq+p xJgQ==
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=RxKIJj3LevfjrMRN/wHrnXu/BSvPUGTXyCZoAx6AIPQ=; b=TQog8UKUF5NXjdj5//9rD9Ekq+FmwgLL6D7bHFFP5dCX0J1rjUgOw3BkShGLb5Mk/n NLl/+aYD1UYC4GqjnKMsHH4kJEIP5CBc0njQg4ymQre7HThWcdLjgaZBf6qJ8cZGoLRP W3o96xuZCm2FUwYC3kuHRPeoYuJ2DDMy2KtPbhp4NZJG7a2rrl+ebAqRLJ8AgAH72SN2 uhMAsI0SBKLCYZpMrA7pL+478aN+80C9tkoKJHBaTy0fD1+La125GMI9xEzmYTGSisZD KeDCvR1vCUVPCBl4G3Y2FSaV+2PerMfrwgLMTlsCFhE0Th4Fd46zHm3nOFxmOfwtOKtu 7DrA==
X-Gm-Message-State: AKS2vOwiMuq5VoyxynGV3C2unEIKR4zkqu1bmq/STGKlLrIaWV6bnW4Y +AOaE/T/AspxVGkXwCh3oiAEm+Ieiw==
X-Received: by 10.176.6.104 with SMTP id f95mr2582916uaf.15.1498554657097; Tue, 27 Jun 2017 02:10:57 -0700 (PDT)
MIME-Version: 1.0
References: <CAAbpuyomorgNdjm3MAAgUTwawis1g8s9ANF2RVhZMXruwohXbw@mail.gmail.com> <HK2PR0401MB1588257A93D04368D9CC18EAB5DF0@HK2PR0401MB1588.apcprd04.prod.outlook.com> <CAAbpuyqbZYOHbg+FO9z13nv-ieatUOtMWGxGTNrRzAUjWuF6TA@mail.gmail.com>
In-Reply-To: <CAAbpuyqbZYOHbg+FO9z13nv-ieatUOtMWGxGTNrRzAUjWuF6TA@mail.gmail.com>
From: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Date: Tue, 27 Jun 2017 09:10:46 +0000
Message-ID: <CAAbpuyqyYdwha12Vp8XcS5EDJCc8z2n8tVqjg-DbmvYieQzs_Q@mail.gmail.com>
To: Dawn Chan <dawn_chen_f@hotmail.com>
Cc: "alto@ietf.org" <alto@ietf.org>, "draft-ietf-alto-path-vector@ietf.org" <draft-ietf-alto-path-vector@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c122e3a034e5f0552ed72ed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/LE7I-FROSfOvs2dcboG4qsyJV2g>
Subject: Re: [alto] Some considerations about path vector design
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: Tue, 27 Jun 2017 09:11:00 -0000

I just realized that the example I took to explain how to
query pv-cost-map + ane-prop-map may make people confused.

Ideally, I hope to provide a general query service to handle some batch
query or some resource combination query. I want to know how many people
are interested in this idea or think it is useful. To make the discussion
more efficiently, I will post an initial draft to define the formal grammar
asap.

Best,
Jensen

On Mon, Jun 26, 2017 at 10:04 PM Jensen Zhang <jingxuan.n.zhang@gmail.com>
wrote:

> Hi Dawn,
>
> Thanks for your reply. Comment inline.
>
> Thanks,
> Jensen
>
> On Mon, Jun 26, 2017 at 5:08 PM Dawn Chan <dawn_chen_f@hotmail.com> wrote:
>
>> Hi Jensen and all,
>> Sorry for the late reply. Please see my comments inline.
>>
>> On 7 Jun 2017, at 4:52 PM, Jensen Zhang <jingxuan.n.zhang@gmail.com>
>> wrote:
>>
>> Hi all,
>>
>> I am going to resume the discussion about graph representation and path
>> vector. After some attempts to adopt the path-vector extension, I have the
>> following considerations:
>>
>> 1. The current design is inefficient. Since IETF 98, we have agreed on
>> the design of a two-stage protocol extension (path-vector cost map +
>> unified property map) for graph representation. It is extensible enough
>> because we can customize the element (ane) properties. But the two-stage
>> protocol will conduct the long delay and increase the complexity of state
>> maintenance.
>>
>> 2. The resource dependencies are not clear. The "Dependent Resources"
>> attribute in ALTO protocol is defined to claim the one-way resource
>> dependencies. But many resource dependencies should be bidirectional. e.g.
>> In path vector design, the cost map and the corresponding property map are
>> bound to the same query.
>>
>> For 1, my personal idea is to deliver a service to accept a sequence of
>> queries. In this way, the client can query both cost map and property map
>> in a single request. And the server will handle the two-stage protocol
>> efficiently.
>>
>> Here is a rough example:
>>
>> request:
>> - resource: /alto/pv-costmap
>>   pids:
>>   - srcs: [xxx]
>>   - dsts: [yyy]
>> - resource: /alto/ane-prop-map
>>   query-id: $resource[0].$response.meta.queryId
>>   entities: $resource[0].$response.costmap.values.reduce(
>>             (x,y) => x.values.concat(y.values))
>>
>> This design idea is a one-step service to get the cost map response and
>> the property map response together in one request, which means it will
>> return all the abstract network elements generated by one query. The effect
>> of this design is probably same as the inline-mode that will directly
>> return the properties of anes in the cost map, right?
>>
>>
> Not exact. The inline-mode pv design just provides one resource. This idea
> proposes a complete grammar of a query language. The response contains
> multiple resources. The PV query is just a special example. The design can
> also be used in other query combinition, e.g. Network Map + Cost Map. And
> the client can offload some computation on the server part.
>
>
>>
>> For 2, I have not found a good solution to handle the generic case.
>>
>> Looking forward to any feedback.
>>
>> Best regards,
>> Jensen
>>
>>