[alto] Some considerations about the unified property

Jensen Zhang <jingxuan.n.zhang@gmail.com> Mon, 27 March 2017 12:01 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 6B9C71294ED; Mon, 27 Mar 2017 05:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 iHL3_jQUXf4C; Mon, 27 Mar 2017 05:01:48 -0700 (PDT)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 BD55E129665; Mon, 27 Mar 2017 05:01:46 -0700 (PDT)
Received: by mail-ot0-x232.google.com with SMTP id y88so28622266ota.2; Mon, 27 Mar 2017 05:01:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=ogbXwBJ0NS/VPAnZ1LFUuppSNdVbWcbH/hWAz5ox2Qw=; b=hd90XlyJVHWghTQlPgZNr6Ay+jlaO/EnVMqit2YxrFLpLo38KZSNGr0h7qYJZiItFw I/EZd1Woy636rFy7MApOPFsyRgCIKtK5Cz5/v9hodN0ycELMxgG8Rv3sCzGV/HXlHYKA quoxOb1PfS0Hqbtt+ipoy/Gx8XoLjkSiHpJvJ9xgTizGtRqgvhnyDm1HRZQQ+GIxDC03 jJvph+7MRgjBMIBkv0GJCKQ0XTIeG+Hx8rwXskTZ4WOjJWk+ihyH9CAYSF9UhXFIG4Yf LG1hL0sSTysCD+ad4MPfPNCR6SsScZE7qhB2sZFiEwArC+qZTXuYxf0+87MFcMu7HxeB F+eQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ogbXwBJ0NS/VPAnZ1LFUuppSNdVbWcbH/hWAz5ox2Qw=; b=IviAaRoQ7e3GCDfd6WtIcX7aOPCl7bdqzOzZ1exBhFESmHyIcbDgbfs3UlCgp5955v L8Z2ZhCFR2mUzcLYwfJcyMM2YTdPkyu7jOC4P1z4QZmJgcUEDMXeBbxTZ/GNiV68BiAO xN97GbXoplRIiFVjBNxGrK4gKrAssWCNBQc+ikmz/C+ig78Lw6cbXwT0oJ36CMn6dBIK JZF6pHmM1iF8oRED0MRmiTSNs/O52L7lpNvrEKVIrmy/1eKgq/mkJ7WQP7MsPRUkoltY R6dO85F49KnEqlUKci6i7b5c0AxPcPzSCMG/lE286fchtiA2tbLy+rSJGrOH1T/8+fm/ +6AQ==
X-Gm-Message-State: AFeK/H0xIzRUcrtccqZaSrczWpl55I5jt76tpGCobmhTGFtCFhmPa+hEQ0Flag+dHNDZ3BDQCjl+pnsOTW8yOg==
X-Received: by 10.157.9.147 with SMTP id q19mr4876971otd.98.1490616106019; Mon, 27 Mar 2017 05:01:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.67.157 with HTTP; Mon, 27 Mar 2017 05:01:45 -0700 (PDT)
From: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Date: Mon, 27 Mar 2017 20:01:45 +0800
Message-ID: <CAAbpuyr8eTpmzvapmfcd=B_EarNZ1YbzqSYKeht20wGmHB04Tw@mail.gmail.com>
To: IETF ALTO <alto@ietf.org>, draft-roome-alto-unified-props-new@ietf.org
Content-Type: multipart/alternative; boundary="001a113e2c167ef0ef054bb51b3f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/fneuI0BaLjG7f2UdH_z5zA852SY>
Subject: [alto] Some considerations about the unified property
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: Mon, 27 Mar 2017 12:01:50 -0000

Hi all,

I'd like to resume the discussion about the unified property. From the
discussion [0] between Wendy and Richard, the argument is about: 1) the
hierarchy and inheritance issue. 2) the consistency of the same property
across domains. Here I have some more considerations about this topic.

1. The hierarchical data scheme. The current data scheme is like {Entity ->
{PropertyType -> PropertyValue}}. I'm thinking about if it is possible to
define a more general scheme. Wendy proposed a new approach about unified
cost scheme [1]. And the main argument I remembered is that this approach
is not downward compatible. I do not also want to deprecate the legacy ALTO
services. But why not propose this approach as an extension of the property
map?

2. More general query filter. The unified-prop draft proposes the filtered
property service whose filter is a set of entities. Why not allow the
client to query the property map by setting the constraints of property
values (like constraints in filtered cost map)? Furthermore, we can
introduce an SQL-like feature for the filtered property map service. The
following gives a potential example:

Request:

{
  "entities": [ "flow:1", "flow:2", "flow:3" ],
  "propertyies": [ "ip_src", "ip_dst", "tcp_src" ],
  "constraints": [ "[2] eq 80" ] // Means only selecting the flows whose
tcp_src is equal to 80
}

Welcome to give any comments or propose some new points to discuss.

Best,
Jensen

[0] https://mailarchive.ietf.org/arch/msg/alto/aSg36442jx4-Qtz7mBvfxDsqGSE
[1] https://mailarchive.ietf.org/arch/msg/alto/2l31OYpqzREMe2vBMApZmdhrR80