Re: [icnrg] FLIC Interest Construction

christian.tschudin@unibas.ch Thu, 06 August 2020 06:06 UTC

Return-Path: <christian.tschudin@unibas.ch>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6593A0EF0 for <icnrg@ietfa.amsl.com>; Wed, 5 Aug 2020 23:06:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 DjeU-PVWgE1m for <icnrg@ietfa.amsl.com>; Wed, 5 Aug 2020 23:06:16 -0700 (PDT)
Received: from smtp11-priv.unibas.ch (smtp11-priv.unibas.ch [131.152.226.208]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BD23A0EEF for <icnrg@irtf.org>; Wed, 5 Aug 2020 23:06:15 -0700 (PDT)
IronPort-PHdr: 9a23:MZdzIRZQTT4Tmk6kjFxhR+z/LSx+4OfEezUN459isYplN5qZrsizbnLW6fgltlLVR4KTs6sC17OI9f+xEjNQqb+681k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRoLerpBIHSk9631+ev8JHPfglEnjWwba5zIRmsrwjcssYajIlhJ60s1hbHv3xEdvhMy2h1P1yThRH85smx/J5n7Stdvu8q+tBDX6vnYak2VKRUAzs6PW874s3rrgTDQhCU5nQASGUWkwFHDBbD4RrnQ5r+qCr6tu562CmHIc37SK0/VDq+46t3ThLjlTwKPCAl/m7JlsNwjbpboBO/qBx5347Ue5yeOP5ncq/AYd8WWW9NU8BMXCJDH4y8dZMCAeQBM+hGsofypVgArRWwCgajGOzi0TpIimPs0Kw6z+gsCwPL0Qo9FNwOqnTUq9D1Ob8OXuC11qnIzC7Db+9X2Tjn7ojEaAwhoeqQUrJwbMre1EgvFwXeg1WNr4zlPiia2f4Ws2SB8+VgVeSigHMopA9tuDag3NssipXXiYIPzFDJ7Sd0zYkoKdCkSEB2bsCoHYVRui2EOYV4QsIvTm5ptSs5xbALpJq2cTQFxZkl2hPSauKKfoeI7xztUOufLzV1inxjdbmiiRiy9k2gxff9VsmyyFtKqzdFkt3QtnAM2RzT7dKHSv5n8Ue9wjaDzQHT6uZcLUA7lKrbN54hwqMrmZYJrUvDGSr2lUPrh6GVbkUp4vWk5uX6brn8u5OQKYt5hhvgPqgwlcGzG+s1PhQIUmOG4+qzzqfj8lf8QLhSi/02lbTWv47CKMQAo665HxdV0oE+6xajFzum0MoXnX0ALF9dfB2LkozkN0/ULPzlDPqygE6gnCpxy/zYILHuBI3BLnnFkLj/YbZw81NQxQsuwdxF+p5YFLUMLOjtVkPvu9HUFBA0PxCsz+biEtp914ceWWyVAq+eNaPfqUOH5uI1I+mNf48VpDf9JOIj5/L0kX85gkMSfam03ZQKaXC4GO9rI1ifYXrtmdgOC3wKshAiQ+zqkFGCSyJcZ26uX6Ig4TE2EIemDYLERoC2g7yB2zy2HoVMaWBcFl+AC2vnd4KBW/0UciKdPtdhkiAYVbimU4Ih1A2htAngy7poNefU+zcYtY7t1NRv4O3Tjx4ypnRICJG42nuGB0RzhWAPD2sz2adkoktV0l6Z2u5zhPkORvJJ4PYcWQcgNIXAzuV8TczpUQLcctaPYEugQ9+vGnc6ToFii+QSalpwTo3xxivI2DCnVvpMz+SG
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2GsAQCJnCtf/yjggaENU4VshWmDSY0uJYECjkyEGoNfgl2BLD0LAQEBAQEBAQEBCCMMBAEBAoEDgwNEAoIqJTgTAhABAQYBAQEBAQYEAQEChkWCQykBEWGBAgEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBARICDVQmQwEBAQIBI1YFCwsONAICVwaDOoJcL7MXdoEyhAOFPIEjBoE4ikeEYYERM4FfSTU+glwCgSoBEgGDOIJgBJANiXCBJkOZL4EGB4tGgnCOXg+fcpsAgV+CUIETjEWEdYFqgQtwhCpPJo4qAReDToJkiBKBCwIGAQcBAQMJkAgBAQ
X-IPAS-Result: A2GsAQCJnCtf/yjggaENU4VshWmDSY0uJYECjkyEGoNfgl2BLD0LAQEBAQEBAQEBCCMMBAEBAoEDgwNEAoIqJTgTAhABAQYBAQEBAQYEAQEChkWCQykBEWGBAgEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBARICDVQmQwEBAQIBI1YFCwsONAICVwaDOoJcL7MXdoEyhAOFPIEjBoE4ikeEYYERM4FfSTU+glwCgSoBEgGDOIJgBJANiXCBJkOZL4EGB4tGgnCOXg+fcpsAgV+CUIETjEWEdYFqgQtwhCpPJo4qAReDToJkiBKBCwIGAQcBAQMJkAgBAQ
X-IronPort-AV: E=Sophos;i="5.75,440,1589234400"; d="scan'208";a="93900152"
Received: from robinwoodap.surfnetc.com (HELO [192.168.1.22]) ([161.129.224.40]) by smtp11-ext.unibas.ch with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Aug 2020 08:06:11 +0200
Date: Wed, 05 Aug 2020 23:06:00 -0700
From: christian.tschudin@unibas.ch
X-X-Sender: tschudin@uusi
To: Marc Mosko <mmosko@parc.com>
cc: "icnrg@irtf.org" <icnrg@irtf.org>
In-Reply-To: <4B61F894-DAAF-4800-A323-C69A02CBF2C9@parc.com>
Message-ID: <alpine.OSX.2.21.2008052131030.11593@uusi>
References: <4B61F894-DAAF-4800-A323-C69A02CBF2C9@parc.com>
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-2052821761-1596693972=:11593"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/jM4d3RThlK-FDG9eLh5fS8P6ANM>
Subject: Re: [icnrg] FLIC Interest Construction
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Aug 2020 06:06:19 -0000

> There are two main reasons to have Name Constructors specified in a 
> manifest. One is to help bridge the NDN and CCN worlds, so one could 
> use a namespace preferred by the protocol (e.g. distinct names per 
> data or nameless objects). The other is to make a Manifest 
> application-independent. If a FLIC manifest is to be like a universal 
> data organization mechanism, it needs to be explicit about how to 
> fetch the data. I do not think one can make a general purpose manifest 
> that allows the sharing of content if the name construction mechanism 
> is implicit.

great wake-up call!

"general purpose = explicit name construction" - fully agreed. We should 
add IPFS, Secure Scuttlebutt and Hypercore to the mentioned worlds.

Since the time when NDN and CCNx did not talk to each other, CCN-lite 
had to auto-detect the "packet's world" by guessing it from the first 
few bits of a packet. CCN-lite also had a shim to encapsulate the 
datagram types, separate CCNx and NDN from pure NFN. Finally a chance to 
overcome this.

IPFS uses "multihash encoding" for hash agility i.e., they call it 
"self-describing hash values", see https://multiformats.io/multihash/ 
There is also the multiformats project to cover other planets/worlds, 
see https://multiformats.io/

When it comes to assigned numbers for hash functions, see the end of 
page https://github.com/multiformats/multihash/issues/49 by which I 
mean: let's not redo this with a nth multihash encoding.

If NDN and CCNx would move in that "multi-" direction, above guesswork 
would not be necessary anymore. For example you could use a single UDP 
port for all your p2p ICN overlays, which also means that you could 
reuse other (multi-) project's p2p libraries and inject NDN or CCNx or 
DAT names found in "our" manifests. I should note that the 
self-describing packet network subproject -called multigram- has not 
even started, probably because others only consider http so far - a 
great opportunity to fill that void and align it with Name Constructors.

Best, c


On Mon, 3 Aug 2020, Marc Mosko wrote:

> 
> This is one of a couple of emails on FLIC topics from today’s call.  This email focuses
> on how a consumer reading a FLIC manifest constructs Interest packets for each entry it
> wants to retrieve.
>
> 
> 
> In the -02 draft, this knowledge was called Namespaces, but we will rename that to
> something like NameConstructor or NameTemplate.  I’ll run with NameConstructor (NC). 
> It is a mechanism by which a Manifest can tell a reader what structure an interest
> should take.  The examples in the draft are hash naming (mostly a ccnx mode), segmented
> naming (which I think ndn would likely use) and single prefix naming (middle ground).
>
> 
> 
> There are two main reasons to have Name Constructors specified in a manifest.  One is
> to help bridge the NDN and CCN worlds, so one could use a namespace preferred by the
> protocol (e.g. distinct names per data or nameless objects).  The other is to make a
> Manifest application-independent.  If a FLIC manifest is to be like a universal data
> organization mechanism, it needs to be explicit about how to fetch the data.  I do not
> think one can make a general purpose manifest that allows the sharing of content if the
> name construction mechanism is implicit.  Different publishers or different
> applications even within a publisher might use different conventions.  There needs to
> be a way for an application reading the FLIC manifest to know how to make the Interest
> names.
>
> 
> 
> Note that independent of the NC, a Manifest supports specifying Locators.  The locators
> are used as the routing hints in NDN or in the Interest names in CCN nameless objects.
>   For NDN, NC vs locators is a somewhat orthogonal issue.  For CCNx, Locators are more
> interwoven, as one could only use Locators with Hash naming (i.e. nameless objects).
>
> 
> 
> Option 1: Multiple Name Constructors assigned by HashGroup (This is the option in the
> draft)
>
> 
> 
> A manifest can define a NC specification that has a NameConsturctor ID (NCID) and the
> rule to construct names, along with needed data like the actual name prefix.  Each
> hashgroup says which NCID it uses. 
>
> 
> 
> NC are not inherited from parent manifests.  Each manifest must be explicit about how
> the names are constructed.
>
> 
> 
> The method explicitly supports multiple naming conventions within one Manifest object. 
> The main usecase is to allow one HashGroup to point to other Manifest objects that
> might be in one naming convention (e.g. segmented naming) and another HashGroup to
> point to data objects that might use another naming convetion (e.g. hash-based naming).
>
> 
> 
> Option 2: A single NC per Manifest object
>
> 
> 
> Each manifest object only uses one NC.  It would be essential Option #1, but without
> HashGroups getting to pick which NC they use, there would be only one NC for the whole
> Manifest Object.  Each manifest object must specify its NC.
>
> 
> 
> Option 2a: Allow inheritance of NC
>
> 
> 
> A parent manifest could specify the NC that is used by children.   The NC could change
> as one reads down a tree.
>
> 
> 
> This option would make pre-fetching difficult.  If the top-level manifest with the NC
> went via one path and internal manifests via another path, the second set of routers
> for the internal nodes would have no way to pre-fetch or do other things because they
> would not understand how to construct the Interest names.
>
> 
> 
> Option 3: Implicit NC
>
> 
> 
> The way to construct an Interest name is implicit by the application.   If someone
> gives you a FLIC manifest out of the blue, you do not know what convention to use and
> must be able to associate the manifest with a specific application or domain to fetch
> its contents.
>
> 
> 
> Routers could not prefetch these, unless they assume some likely naming schemes.   Or
> the routers would need to guess or apply ML to the interests they see to deduce the
> possible name construction.
>
> 
> 
> Option N: Others?
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
> 
> 
>