Re: [alto] Progress on the unified properties draft and call for comments

Jensen Zhang <jingxuan.n.zhang@gmail.com> Mon, 08 July 2019 16:59 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 9C452120290 for <alto@ietfa.amsl.com>; Mon, 8 Jul 2019 09:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
X-Spam-Status: No, score=-0.702 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2ity_7ZoI61k for <alto@ietfa.amsl.com>; Mon, 8 Jul 2019 09:59:55 -0700 (PDT)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 A2D231202A0 for <alto@ietf.org>; Mon, 8 Jul 2019 09:59:55 -0700 (PDT)
Received: by mail-yb1-xb31.google.com with SMTP id a5so4263488ybo.13 for <alto@ietf.org>; Mon, 08 Jul 2019 09:59:55 -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=YJYQa3rf4cRzyo2zjddZuzeBTbilT475P728Sd9V8EA=; b=jwarvS7OjuEo0GVoobxXoP98z6+8YdAwUBJZ5vFxOnUBPEl5DP7zoxgAhv6oSdO/ow Jol7NiB/y6EHzca0HSxkM35lc/2KR3CXFO3gx5BSiJTmRbU6fZeGRpJdNX1WLC7PL8Mn Yzkr903ztqrT2VdCmDUYC33pycmAx+yD4+Bn2kJCbjiejZS8Alju7D1mgXtmGK7QLDbJ /lYrjXvAzBVsgTC6nfDeAxzoLcgTkpaonWy0AI3/flgRBNzujvVsaZeIMWgxg5lzVKTp cmHHCgm36ioTEa8A/ghwgQhdj8k1EJ2JRf17BAtq+ndAsKbPiicktPTM/qTFJSHHtd9O hcZQ==
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=YJYQa3rf4cRzyo2zjddZuzeBTbilT475P728Sd9V8EA=; b=Mw4swOPcW1bTmghXpUMQMqeFZnUWbk3DPKMjURaFXW+W2Vyr0B0zPbWN0Gaik3RilP h8Je7RnXK4sT4IPBIQYM/SICwHpNj/3cBJn4OVP6nqJ1BgbLpQLgYQdw5OcPshOAgsXf 5iHmOQkqcKqYdzlQMf/J7UA/ptCnDy8zasUT/pBV1cRZQnSf1IHpddR34yDwGDM9t8qU GuZTD+dflrQYOIo7g9KRu8e19Nqxev9p6SpMrfiN9kwN4Ix8CWJD/Z1g4eqzXy6YevJo N4BWOWG/hGjyKx+Op7CY0fbn6/1aH1uro01EHexV8riqDbqXoE2f6jIsjqB1GAVR67GX TMkQ==
X-Gm-Message-State: APjAAAWjCoFHYo2cCnziuwh2GR7UgNXZBFIx6jOQxJVOwm2t5oUM+GmK eiLLaateIN2oEIReXHAo1bHxKm2D5Opp7ssKCsY=
X-Google-Smtp-Source: APXvYqwI7klcfyeZH4mgr30S2kKK2rLIAePTUjDWjAQnI/4uSJxZs/Vdx9NHRC+znIymyLH5Y9mVbtTdC8fe6vzRwEE=
X-Received: by 2002:a5b:b49:: with SMTP id b9mr10788300ybr.167.1562605194534; Mon, 08 Jul 2019 09:59:54 -0700 (PDT)
MIME-Version: 1.0
References: <CAAbpuyrrRv8aAKaR89d2ptvFTourmWCejMp1HWbs_9gpA3XMRA@mail.gmail.com> <CANUuoLrezY74wg8VbrtcCS8yb4veOjy3ZB0HiKVx9iG52u4c1A@mail.gmail.com>
In-Reply-To: <CANUuoLrezY74wg8VbrtcCS8yb4veOjy3ZB0HiKVx9iG52u4c1A@mail.gmail.com>
From: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Date: Mon, 08 Jul 2019 12:59:43 -0400
Message-ID: <CAAbpuypA+iwEn5XLgfQmjr1Q7-4H4M+MkiVP7k=X2ZvW_ShBzg@mail.gmail.com>
To: "Y. Richard Yang" <yry@cs.yale.edu>
Cc: IETF ALTO <alto@ietf.org>, "Randriamasy, Sabine (Nokia - FR)" <sabine.randriamasy@nokia-bell-labs.com>, Gao Kai <godrickk@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000008b6321058d2e5f1e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/x1SK1Ofx-MWHIPD98IQ4u6hGk9w>
Subject: Re: [alto] Progress on the unified properties draft and call for comments
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: Mon, 08 Jul 2019 17:00:07 -0000

Hi Richard,

Thanks for your comments and some clarifications.

On Mon, Jul 8, 2019 at 12:10 PM Y. Richard Yang <yry@cs.yale.edu> wrote:

> Some quick additional comments. Please see inline.
>
> On Fri, Jul 5, 2019 at 6:02 PM Jensen Zhang <jingxuan.n.zhang@gmail.com>
> wrote:
>
>> Hi ALTOers,
>>
>> After some internal discussions, we are happy to update to WG that we are
>> finalizing the unified properties draft. And below are some key design
>> points:
>>
>> ---
>>
>> 1. Consider UP (Unified Property Map) service as a unified ATLO
>> information resources query mechanism
>>
>> ALTO defines different types of information resources, which have
>> different representation formats. But every information resource can map
>> some kinds of entities to some kinds of properties. e.g., a network map can
>> map ipv4 to pid.
>>
>
> Slight clarification. So far it is not every type of information resource.
> For example, cost may cannot yet, unless we introduce flow/connection, but
> we may say some for now.
>
>
Agree. We will clarify it is extensible. The future document can define new
mappings for existing ALTO information resources.


>
>
>> UP provides a query mechanism to allow clients to get different ALTO
>> information resources in the unified representation format.
>>
>>
> We should clarify that UP provides 3 functions, as we did in the quad
> chart: export, extend, and define. The preceding may give others an
> impression that it limits us to only the first.
>
>
It will be clarified in the document.


> 2. Each UP resource declares a set of (resource_i, DT) -> { (resource_ok,
>> Pk) } mappings
>>
>>
> Can we use r_i, d_i -> r_o, p_o?
>
>
>> Here, resource_ok MUST be either resource_i or this (the current UP
>> resource itself).
>>
>> - When resource_ok == resource_i, the mapping means the client can query
>> the property mapping DT -> Pk defined by resource_i. e.g., "ipv4" -> "pid"
>> defined by "networkmap-1".
>> - When resource_ok == this, the mapping means the client can query
>> entities in the entity domain resource_i.DT, and UP will return the
>> property P defined in its own backend database.
>>
>> The semantics of entity domain resource_i.DT MUST be defined in the IANA
>> registry of resource type of resource_i
>> The semantics of mapping DT -> Pk MUST be defined in the IANA registry of
>> resource type of resource_ok.
>>
>> 2.1. Use DT -> { (resource_ok, Pk) } as a shortcut of the aggregation
>>
>> A UP resource can declare "ipv4" -> { ("net1", "pid"), ("net2", "pid") }.
>> It is equivalent to the outer join of ("net1", "ipv4") -> ("net1", "pid")
>> and ("net2", "ipv4") -> ("net2", "pid"). In this UP, "ipv4" indicates the
>> union of entity domain "net1.ipv4" and "net2.ipv4".
>>
>>
> I do not know what the outer join is. A simple rule is a kind of
> *inheritance* rule:
>
> d_i -> (ro1, po1), (ro2, po2), ...,
>
> <=>
>
> (ro1, d_i) -> (ro1, po1);
> (ro2, d_i) -> (ro2, po2),
> ...
>
> In words, the result is to use the output resource.
>
> Thanks for your clarification. *inheritance* may be a better
clarification. the (ro1, po1) of d_i:e_i (an entity in d_i) inherits (ro1,
po1) of ro1.d_i:e_i (the entity in (ro1, d_i) with the same id).


>
>
>> 3. The client sends the UP query based on the declaration
>>
>>
> It helps that we make clear the declare-use consistent design. Hence the
> final format of capability may be:
>
> // design 1
> query-capability:         a list of mapping
> mapping:                    domain -> properties
>
> properties:                  a list of properties
> property:                     resource-prop | this-prop
> resource-prop:           r_o.p_o    // (r_o, p_o)
> this-prop:                   .p_o         // (this, p_o)
>
> domain:                     resource-domain | generic-domain
> resource-domain:     r_i.d_i
> generic-domain:       d_i
>
> Semantics:
> - resource-domain (r_i, d_i) -> properties
>   is equivalent to (r_i, d_i) -> each property in properties
>
> - generic-domain -> properties
>   use the inheritance rule above
>
> Consistency requirements:
> Export consistency, which applies to
>        an individual-mapping (r_i, d_i) -> (r_o, p_o), where r_i == r_o !=
> this
>      1.1 Capability announcement consistency:
>             d_i -> p_o must be supported by resource r_i
>      1.2. Content consistency
>             (r_i, d_i) -> (r_o, p_o) lookup result is the same as one uses
> r_i itself.
> Extend consistency, which applies to
>       an individual-mapping (r_i, d_i) -> (r_o, p_o), where r_o == this
>    The domain (r_i, d_i) must be supported by r_i
>
> Thanks for your clarification again. I agree with the requirements above.
The document will include them.

Jensen


> Make sense?
>
> Richard
>
>
>> The client queries a list of entities in resource_i.DT or DT, and a
>> subset of properties { (resource_ok, Pk) }.
>>
>> ---
>>
>> We will finish the document revision in the next two days. In the
>> meantime, your comments and feedback are highly welcomed.
>>
>> Thanks,
>> Jensen
>>
>
>
> --
> --
>  =====================================
> | Y. Richard Yang <yry@cs.yale.edu>   |
> | Professor of Computer Science       |
> | http://www.cs.yale.edu/~yry/        |
>  =====================================
>