Re: [alto] Progress on the unified properties draft and call for comments
"Y. Richard Yang" <yry@cs.yale.edu> Mon, 08 July 2019 16:10 UTC
Return-Path: <yang.r.yang@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 CC2F6120343 for <alto@ietfa.amsl.com>; Mon, 8 Jul 2019 09:10:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.106
X-Spam-Level:
X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.247, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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
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 juRosMh_DUtx for <alto@ietfa.amsl.com>; Mon, 8 Jul 2019 09:10:33 -0700 (PDT)
Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) (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 33E9612031A for <alto@ietf.org>; Mon, 8 Jul 2019 09:10:25 -0700 (PDT)
Received: by mail-vk1-f182.google.com with SMTP id s16so2562727vke.7 for <alto@ietf.org>; Mon, 08 Jul 2019 09:10:25 -0700 (PDT)
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=Elm7uVVCJx8OLc79u74u3OtbH63BBXf2EUJ/Z9kF/YI=; b=E+3K75TP9AqT5NlexOhq6D0k0S3NAcjByftArofbvAXtFIW6E39PzNCB5jbX6y+GPE fTqeystVXtYeZLi22EE9nhSLpehNEOBiqAI41niunYNGA8xGpLeF1XG0n4C+9HdEkrhb /x3B2wjqiQrSrATjLG4NxYlG2+lFRhCR/SHoIrjOLCFBfWvjI0QgfB9II7CL964Q8d2w T0Dkjv1lM91i3Ba5+3rwygAX4NGtVqc7Ei8fHorpAUeSGvQ+bIv0Bz6xTD2iCN9+Zn+g Chptt1GTF52sqbC9akBpTOrMSNim1yE3E0giNamXqbcLGE8bxgRHa6FPG4ZVi89anbs1 V/OQ==
X-Gm-Message-State: APjAAAVt+s9HiFVleStBu7e8J+g9kCs0Tt8wk6p04qMSqTnJ20XR618S juxFEssCmjNujAzhJJyBaj9Vax0WNruYmkdPYbBjHWAc
X-Google-Smtp-Source: APXvYqypYpaEx36Q5N5aMXaYBJVegC0s1yggjmSCENamfIZUIj0Fii0jjsPQu+9MXIL+m4bcdeCWNjjtAgU/X+DjbeE=
X-Received: by 2002:a1f:be51:: with SMTP id o78mr5518058vkf.66.1562602223808; Mon, 08 Jul 2019 09:10:23 -0700 (PDT)
MIME-Version: 1.0
References: <CAAbpuyrrRv8aAKaR89d2ptvFTourmWCejMp1HWbs_9gpA3XMRA@mail.gmail.com>
In-Reply-To: <CAAbpuyrrRv8aAKaR89d2ptvFTourmWCejMp1HWbs_9gpA3XMRA@mail.gmail.com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Mon, 08 Jul 2019 12:10:12 -0400
Message-ID: <CANUuoLrezY74wg8VbrtcCS8yb4veOjy3ZB0HiKVx9iG52u4c1A@mail.gmail.com>
To: Jensen Zhang <jingxuan.n.zhang@gmail.com>
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="00000000000079b5d6058d2daecf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/4QI7A3z94z6QNkeTKrxC41Y_EgM>
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 16:10:44 -0000
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. > 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. > 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. > 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 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/ | =====================================
- [alto] Progress on the unified properties draft a… Jensen Zhang
- Re: [alto] Progress on the unified properties dra… Y. Richard Yang
- Re: [alto] Progress on the unified properties dra… Jensen Zhang