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? > > > > > > > > > > > > > > >
- [icnrg] FLIC Interest Construction Marc Mosko
- Re: [icnrg] FLIC Interest Construction christian.tschudin
- Re: [icnrg] FLIC Interest Construction David R. Oran