[alto] Considerations about More Flexible ALTO Query/Filter

Jensen Zhang <jingxuan.n.zhang@gmail.com> Fri, 27 March 2020 02:28 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 []) by ietfa.amsl.com (Postfix) with ESMTP id E27113A07BB for <alto@ietfa.amsl.com>; Thu, 26 Mar 2020 19:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3AFQcshKgMPl for <alto@ietfa.amsl.com>; Thu, 26 Mar 2020 19:28:30 -0700 (PDT)
Received: from mail-yb1-xb41.google.com (mail-yb1-xb41.google.com [IPv6:2607:f8b0:4864:20::b41]) (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 87C3A3A0496 for <alto@ietf.org>; Thu, 26 Mar 2020 19:28:30 -0700 (PDT)
Received: by mail-yb1-xb41.google.com with SMTP id c13so521840ybp.9 for <alto@ietf.org>; Thu, 26 Mar 2020 19:28:30 -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; bh=tjGCIil6HmwnLt3T44cDpmkfOshcw0RQent/t8uFR9c=; b=ulFiSs2dCc2BIJ2Kzr6WPCA2KZZLpZHYvt64wxCrTNJ0/b5j8gUdtGYzVfr+GECWx/ S9Esjq76lrozxD23em3Pz7gA6+ptbhbEXyZXF42/pUdGroTUCBuFwnEvvJQjCvCf2Aoy tfiF9x3urSIGKglX/0N+YkDxj7YWWtU/gh1gx4ImjZ5qmbMab37XfmTQyUs+vItLBMTJ tGT+3e7fELCzzzF4OA3Az59V1M0NzPK5YHyhBAFn02O7kbpcdSQXt425yb/2js5Kg4Ru NiveOGWsoBXHRMrQlqjV9VJXNXgD3K1wbZa5Ymv1r0KR3X/Q2Zg5goKfvEj1Ts2qc+lv fg3A==
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; bh=tjGCIil6HmwnLt3T44cDpmkfOshcw0RQent/t8uFR9c=; b=gNsyikevHaKRaIMvFiuvcopyAPbOE1/YbrImWRpN/WoU4WTlPFqIoiPxKI/dWvrqK+ DEXXzGKc+TrjUtRxI8zsIW0h6Gec/nV4rqjdoYjxDkWJlgePFJMDUzWehj0IPWteEkKR GIlvflvdk86ljUYyaASry8mpDSZp3C9veNypb0G7s/Eds+oOwSBfImZkWwIKrASPvR1i 4l2CSjTYSRBK0Wh1OKQj0MLwYfGkxGrhRScwzXhpuBLxLaWe9YBWi5O01TGUK5M9+qYi K/S54kslwBWgWu60DBQr4u2NbTT68sjUqdp6FWlxfE1CGdaVvYYW8q2NK4/QUXFgmPfQ p3tg==
X-Gm-Message-State: ANhLgQ0mGrpz/aYq/43La0hqkJhhQ1dddb8oXCojnGnUiMmK2JzAnIbJ 150aRX+Fy0O7DRwrE0+RLi833ZOFokRjqaA/f86mwh4Z
X-Google-Smtp-Source: ADFU+vu5gw0W3se5i6Bsd0FWjyfTnVoEwIZDbpEIoM/zon/78qaE57veHEVM/ZtVC/yThuIWieXWs10mJNvr6XpskX4=
X-Received: by 2002:a25:868e:: with SMTP id z14mr1823671ybk.35.1585276109284; Thu, 26 Mar 2020 19:28:29 -0700 (PDT)
MIME-Version: 1.0
From: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Date: Thu, 26 Mar 2020 22:28:18 -0400
Message-ID: <CAAbpuyqu0K+ZA8WWM39PRnW-ghNMPpE7qTbfZ7sTziv=qeSX0w@mail.gmail.com>
To: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005d694b05a1ccdbce"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/2_lAFpED1ic9h851FGpTVO8Slso>
Subject: [alto] Considerations about More Flexible ALTO Query/Filter
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: Fri, 27 Mar 2020 02:28:35 -0000

Hi all,

I'm considering the extension to the current ALTO information resource

Currently, ALTO can only support the very simple query (e.g., Filtered
Network Map, Filtered Cost Map). Although Filtered Cost Map supports the
test constraint, it is very limited and cannot be applied to some new ALTO
extensions (e.g., path vector and unified properties).

So far, as I know, most of NoSQLs or document-oriented databases (e.g.,
MongoDB [1], PostgreSQL [2], ElasticSearch [3]) have JSON query support. I
think we can leverage them to query ALTO information resources. However,
all of them have a clear limitation when applied to ALTO: the query
statement must specify the concrete field names. But all of ALTO
information resources use non-fixed fields (e.g., PIDName in Network Map,
src and dst TypedEndpointAddr in ECS).

To extend the current ALTO query, I can think about two options:

Option 1: we define a conversation between the ALTO JSON schema and some
other schema using fixed fields (e.g., the JSON schema defined by YANG
model [4]). Then the client can use the JSON query languages in existing
database systems to query the later schema, but the ALTO server transfers
the result to the former (ALTO) schema and returns it. In the backend, most
of the ALTO implementations should be based on those database systems. So
this option can be acceptable in practice.

Option 2: we use some more flexible JSON query language (e.g., JSONiq [5]),
or define a new query language for ALTO specific. This option can be more
valuable if we want to design a new database system for ALTO.

Looking forward to seeing more comments and discussions from WG.

[1] https://docs.mongodb.com/manual/tutorial/query-documents/
[2] https://www.postgresqltutorial.com/postgresql-json/
[4] https://tools.ietf.org/html/draft-shi-alto-yang-model-03
[5] http://jsoniq.org/

Best regards,