[icnrg] Question on the NIST NDN forwarder

"David R. Oran" <daveoran@orandom.net> Wed, 22 April 2020 14:29 UTC

Return-Path: <daveoran@orandom.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0BD563A0CEA for <icnrg@ietfa.amsl.com>; Wed, 22 Apr 2020 07:29:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6yaZPPXTcljy for <icnrg@ietfa.amsl.com>; Wed, 22 Apr 2020 07:29:47 -0700 (PDT)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (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 988033A0CDB for <icnrg@irtf.org>; Wed, 22 Apr 2020 07:29:47 -0700 (PDT)
Received: from [] ([IPv6:2601:184:407f:80ce:e48f:c74d:12e5:2db4]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 03METf5C027262 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Apr 2020 07:29:44 -0700
From: "David R. Oran" <daveoran@orandom.net>
To: "Shi, Junxiao" <junxiao.shi@nist.gov>, ICNRG <icnrg@irtf.org>
Date: Wed, 22 Apr 2020 10:29:35 -0400
X-Mailer: MailMate (1.13.1r5684)
Message-ID: <060E1A5C-4B55-4850-900A-6A29C8596861@orandom.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"; markup="markdown"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/d6f0ZgvzpLIpWFTPTOeWoZZufNw>
Subject: [icnrg] Question on the NIST NDN forwarder
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: Wed, 22 Apr 2020 14:29:49 -0000

This may be a misunderstanding, or an NDN architecture question rather 
than a forwarder question. My knowledge of the current state of the NDN 
architecture is somewhat weak, so please excuse the noise if this is 
flat out wrong.

It relates to the CS prefix matching shown on slide 9.

I thought that NDN semantics said that an Interest with prefix match 
would match the CS entry with the longest prefix match, independent of 
how many name components the CS name entry had, or how many name 
components were expressed in the Interest. Your example shows just a 
single level of prefix indirection in the CS (which is of course fine 
for an example to illustrate the design).


What if I have a named object of, for example, /a/b/c/d/e.
In order to match any interest asking for prefix match, e.g. /a/, would 
I not have to create indirect entries for /a/, /a/b/, and /a/b/c/ as 
well as the indirect entry for /a/b/c/d/ ?

If true, this seems a really sub-optimal situation for objects with long 
multi-component names, as the number of CS entries and consequent writes 
would multiply rapidly. A secondary effect might also require both a 
“real” CS entry and an indirect CS entry if an application actually 
has an object, like /a/b/c as well as one named /a/b/c/d/e.

Did something change in the NDN architecture to explicitly restrict the 
number of up-levels that are allowed in prefix matching?

Thanks for enlightening me!!