[icnrg] FLIC Interest Construction

Marc Mosko <mmosko@parc.com> Mon, 03 August 2020 18:29 UTC

Return-Path: <mmosko@parc.com>
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 70E023A0980 for <icnrg@ietfa.amsl.com>; Mon, 3 Aug 2020 11:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=parc.onmicrosoft.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 r7X4AXDlwM9t for <icnrg@ietfa.amsl.com>; Mon, 3 Aug 2020 11:29:56 -0700 (PDT)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2079.outbound.protection.outlook.com [40.107.237.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091333A105E for <icnrg@irtf.org>; Mon, 3 Aug 2020 11:29:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ITa57uhR1cca9R6SKJn/UBGOJo+pX50wfjHZnX8TruSnk1kliovvBM9tkMYDVtC6G7BIjiRl6ZX0i+FuBI/ERxJCKHg4CyWBBrKL4OU5QReYKk8XKl9Qja22l8eG5a7ngv0/24/EIxLyD5tfKQHxrfCInG8Alzz05Bd8ujUQ6kJw/jsLO3XGKxNBLno7zZGJt/2QfVdTnSn4/yMAXfggqFVEARFDqpqpED6P7smvrQnSvIyIKaqnidLSrBmUUVWkgZg+kp25c+q317CYH6dzEYyA13bV7VipJ7a4jUq7Eq2SSWOqhnY1S68SS7xc/9PO6c7jONby7On7BrQwune/KQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vl+MCQz+Io5GEH8xS6WeKPzLYaCcGpF/gvu20FPL3V4=; b=iLMLjHip+VgAabVfBNJ6qyirpn7YNJtXPtN4S8m98zKtdE3bknY6UBCQzXOn7iSnt6bHxyg9ywHlSmvxlaQMkGapb98hP/eZ33EVii7wHJRx9tyqMrQg5MOoswujNuGXEyBbbFOrKCjAKoReTquzjQBD6ab+H8pOLdwShuCx9wIlP0uTIAK3VLsQH0Tn6exTFEDtAf+y9a5OLLr1vfbfWDc8Gi0ngbJ/ivMTOzFrD6f/e4TnzzAs5mtRnyxQyneY8drHicSuslqYn5Hg4eT+nUafoI3AxZpa93gDHCw/RK1pi6s8DHfr0In9E7omGDQ01dG7l2TN1IRgVT7wbkjzNQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=parc.com; dmarc=pass action=none header.from=parc.com; dkim=pass header.d=parc.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parc.onmicrosoft.com; s=selector2-parc-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vl+MCQz+Io5GEH8xS6WeKPzLYaCcGpF/gvu20FPL3V4=; b=0lvrTGah7LkNRrQD7H6XDf65W1pyNiRHgA5NVewZ+W1MsZbBAQ5HdkWLmxxVY7D/KmoJ/Ilc0il4yjRkM+g8b/QGDXj3Gyg2BnjmcuDlU9Y+f7PEizcxgKTqApR0UZuP8pn0OhGWXvXph/DND3qxJcZXpF2JqvatzbvOInmAXkE=
Received: from BYAPR15MB3238.namprd15.prod.outlook.com (2603:10b6:a03:106::29) by BYAPR15MB2421.namprd15.prod.outlook.com (2603:10b6:a02:8a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20; Mon, 3 Aug 2020 18:29:53 +0000
Received: from BYAPR15MB3238.namprd15.prod.outlook.com ([fe80::1045:4aad:16d6:c0e6]) by BYAPR15MB3238.namprd15.prod.outlook.com ([fe80::1045:4aad:16d6:c0e6%7]) with mapi id 15.20.3239.021; Mon, 3 Aug 2020 18:29:53 +0000
From: Marc Mosko <mmosko@parc.com>
To: "icnrg@irtf.org" <icnrg@irtf.org>
Thread-Topic: FLIC Interest Construction
Thread-Index: AQHWacQU8GxPAuS1v025+6uzB/w5Ig==
Date: Mon, 3 Aug 2020 18:29:52 +0000
Message-ID: <4B61F894-DAAF-4800-A323-C69A02CBF2C9@parc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.39.20071300
authentication-results: irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=parc.com;
x-originating-ip: [50.0.67.90]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a5633f55-6fa9-4e41-f327-08d837db36d3
x-ms-traffictypediagnostic: BYAPR15MB2421:
x-microsoft-antispam-prvs: <BYAPR15MB2421B6BF5DD09205C8C6682EAD4D0@BYAPR15MB2421.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ZJOOICmvwIcAnNLO19Fz8yUesalwq3e4TLJC9OObJ1I6KxpHSoqtfbctP02MiMY1rwW9+pBE8ZxOwOFf7EDHTN/6MfNc6JHE7fSIL6P3yUqWY52xRtAiAGNGNE3cbq+EKeyu+FKilhNG25L+rtpDhU3Hv8lW5yS0qxVCE8A62qbK7tGuC2agBT/ye9xzrjfNysutR5DTeanBfZ7d6sUPtuBTBx/A+NdK2dguFRuYhpoa/4ePpfLjSblFbDxCoO7hyYxT/Y4ZmSLovvkRvprXE4cu4iakeCrA7upNXQmdZUMxnlBTxq1uted/2fmDereVrlko1RLRZkY8iNXNJIe7fQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR15MB3238.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(376002)(136003)(39840400004)(366004)(71200400001)(3480700007)(186003)(8676002)(7116003)(6506007)(86362001)(2906002)(478600001)(6916009)(6486002)(91956017)(66446008)(6512007)(33656002)(66946007)(66556008)(66476007)(64756008)(316002)(26005)(8936002)(76116006)(36756003)(5660300002)(2616005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 3sXXYQAKlkBqphHQSIkfrOAEzgPtMWvC2+ooWymTWi1GJmDyjmfmflnfkf20u1HA9ZlpAx8aUfo61eSVrpmxSuUzflXibLTohJtKjP42tcu4FJnbvgHCEFrnfbvz3Xhituc1qv99lvspP8ZuOkzk/77wt/EpR4BxE8Vy2wQrdNQAjxgyd24kOL7tdsay/xj58BRXnEtHmZvMTeykIviEuBIIi//kba/oRvjWsaLGKtF4d5F8qbuXLd6ACmni6xP+tsRto1PmXG6xeJwJDactvKBC3gMzgAeWcs824Tw2sdjOSVrqjj99i9NW6AdPWSATaFnriLA7FtzGNDD9NjtBUtLT2KalcDWLouCAjztQMpf1wg+CHEZ/h2tVjz7Sus9ya3wjECkRZPIOtmV+WfPbJbtM5Uao2eCc5D2h0NsW6T5duIYcpruz3f2EGhluZ8dG8UQM7+6nrNLOvRzRRld3RjskNhZZ5tBdEZX7pAeCWmhfUxh+gs1P2fVUFMwkgvLC5WsYylIdD+CJKadrBOQSceNOUJjwm6GVdSrqyHVZHl6lmn9SbK31211fyTqKTDZgEdZLNJ7Gk6ugrFuGJV8iPtC9FRLQXyA/SrdXQ36y+0Nj0jdfL8EKnkWu25mTcXgNIWk8T1H2/jWT1kIFeynoxw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_4B61F894DAAF4800A323C69A02CBF2C9parccom_"
MIME-Version: 1.0
X-OriginatorOrg: parc.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR15MB3238.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a5633f55-6fa9-4e41-f327-08d837db36d3
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2020 18:29:52.9061 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 733d6903-c9f1-4a0f-b05b-d75eddb52d0d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bBdY2no7YmYDZcMGitev7wIqKAk1j8bsePA99MtUxcAKLCTLRfdLTvAPD/MiMaV7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2421
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/NY_vtnZqzGTXYgSGp9vJBQlXXhY>
Subject: [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: Mon, 03 Aug 2020 18:29:58 -0000

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?