Re: [icnrg] [EXT] Question on the NIST NDN forwarder

"David R. Oran" <> Wed, 22 April 2020 15:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2B583A0E61 for <>; Wed, 22 Apr 2020 08:11:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id icflRKqCXDHR for <>; Wed, 22 Apr 2020 08:11:00 -0700 (PDT)
Received: from ( [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 257A73A0E5B for <>; Wed, 22 Apr 2020 08:11:00 -0700 (PDT)
Received: from [] ([IPv6:2601:184:407f:80ce:e48f:c74d:12e5:2db4]) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 03MFAsBq027924 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Apr 2020 08:10:57 -0700
From: "David R. Oran" <>
To: Junxiao Shi <>
Cc: "Shi, Junxiao" <>, ICNRG <>
Date: Wed, 22 Apr 2020 11:10:49 -0400
X-Mailer: MailMate (1.13.1r5684)
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_406AB480-BEED-468A-A73A-A61B371BD03E_="
Content-Transfer-Encoding: 8bit
Embedded-HTML: [{"HTML":[1330, 3840], "plain":[844, 3294], "uuid":"CFE380A6-2909-413F-90FA-D652C6FC2FF8"}]
Archived-At: <>
Subject: Re: [icnrg] [EXT] Question on the NIST NDN forwarder
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Apr 2020 15:11:03 -0000

Thanks! This helps a lot. I’m somewhat surprised to see this a bit 
buried in a forwarder API description - is there something in an 
architecture document that explains to applications what the allowable 
semantics are?

One quick followup, since I’m clearly missing something in the 
explanation it says: “When an incoming Data satisfies an Interest with 
a prefix name or a full name…”. I don’t understand how you can 
tell whether the PIT for an interest with a prefix name is satisfied by 
that data without either already having the indirect entry somewhere, or 
doing a full LNPM into the PIT or CS to discover the Data object 
matches. Cluebat please?

Also - we can take this offline if others aren’t interest in this 
narrow question…


> name, the CS inserts two entries

On 22 Apr 2020, at 10:59, Junxiao Shi wrote:

> Hi Dave
> No. In the expected case, the consumers should be using a consistent 
> name
> prefix to perform name discovery. The CS only needs 1 indirect entry 
> in
> this case. Occasionally, a small number of different consumer 
> applications
> could be using several name prefixes to perform name discovery of the 
> same
> Data packet, and the CS supports up to 4 indirect entries per direct 
> entry.
> More information on
> , 
> copied
> below:
> In addition to exact match lookups, CS supports a limited form of 
> non-exact
> match lookups: a cached Data can be found when the new Interest name 
> is
> same as the previous Interest name that retrieved the Data. This 
> allows CS
> matching with a prefix name, under the assumption that a consumer
> application would use a consistent prefix to perform name discovery. 
> It
> also allows matching with a full name including implicit digest.
> When an incoming Data satisfies an Interest with a prefix name or a 
> full
> name, the CS inserts two entries: a direct entry with the Data name as 
> its
> key, contains the Data, and can match future Interests with the same 
> name
> as the Data; an indirect entry with the Interest name as its key, 
> points to
> the direct entry, and can match future Interests with the same name as 
> the
> previous Interest.
> A direct entry keeps track of dependent indirect entries. When CS 
> evicts or
> erases a direct entry, dependent indirect entries are erased 
> automatically.
> Each direct entry can track up to four indirect entries; no more 
> indirect
> entries could be inserted after this limit is reached.
> Yours, Junxiao
> On Wed, Apr 22, 2020 at 10:29 AM David R. Oran <> 
> wrote:
>> External Email
>> 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).
>> But…
>> 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!!
>> DaveO