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 >> >>
- [alto] Some considerations about path vector desi… Jensen Zhang
- Re: [alto] Some considerations about path vector … Dawn Chan
- Re: [alto] Some considerations about path vector … Jensen Zhang
- Re: [alto] Some considerations about path vector … Jensen Zhang