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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36A223A0EF1 for <>; Wed, 22 Apr 2020 08:44:36 -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 vVR8TpZsCMep for <>; Wed, 22 Apr 2020 08:44:34 -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 139063A0F94 for <>; Wed, 22 Apr 2020 08:44:25 -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 03MFiKV0028547 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Apr 2020 08:44:22 -0700
From: "David R. Oran" <>
To: Junxiao Shi <>
Cc: "Shi, Junxiao" <>, ICNRG <>
Date: Wed, 22 Apr 2020 11:44:14 -0400
X-Mailer: MailMate (1.13.1r5684)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_88EF4455-34C2-4DD7-A514-128C7CD56563_="
Embedded-HTML: [{"HTML":[588, 4894], "plain":[257, 3423], "uuid":"BA0120E0-94D2-4174-8981-A19133154DC9"}]
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:44:36 -0000

Ah, that clears things up. Many thanks.

I assume the L2 (or whatever tunneling protocol used) is 
cryptographically protected or of course all hell can break loose by 
believing crafted hop-by-hop PIT tokens.

On 22 Apr 2020, at 11:38, Junxiao Shi wrote:

> Hi Dave
> 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?
> The NDN forwarding behavior in Chapter 2 and 3 of NDN in Local Area 
> Networks
> <> says the following for the 
> Content
> Store:
> When an Interest arrives, the node queries the CS to see if there is a
> cached Data that can satisfy the Interest. Given an Interest, the CS 
> is
> expected to return a Data that satisfy the Interest, i.e. the Data 
> name
> must start with the Interest name, and the Data must not violate any
> selectors in the Interest. If the CS finds a Data that satisfies
> the Interest, the Data is returned to the downstream, and the Interest 
> is
> not forwarded further. This saves upstream bandwidth, and shortens 
> data
> retrieval delay.
> Note: this was written in 2017 so some terminology is outdated. 
> "selectors"
> has been replaced by "CanBePrefix and MustBeFresh".
> While the CS is "expected" to return a Data that satisfies the 
> Interest, it
> is not required to do so.
> The network as a whole would still be functional even if the CS on 
> some or
> all nodes are reporting MISS when the Data actually exists.
> 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?
> NDN-DPDK inserts a PIT token on the hop-by-hop header of every 
> outgoing
> Interest. The upstream node MUST put the same PIT token when they send 
> back
> Data/Nack in reply to the Interest. The PIT token not only indicates 
> which
> forwarding thread processed the Interest, but also contains an index 
> of the
> PIT entry.
> For an incoming Data, the forwarder knows exactly which PIT entry is 
> being
> satisfied. It does not need to perform any name matching in the PIT.
> NDN-DPDK design is influenced by Network Algorithmics
> <>.
> Chapter 3.3 gives some implementation principles. The relevant ones 
> are:
> P3 relax system requirements - P3c shift computation in time
> The CS cannot find cached Data if an Interest is using a prefix name 
> that
> has not been used before. This improves forwarding speed, at the cost 
> of
> shifting the computation of such name discovery to the producer node 
> or an
> edge forwarder (note that NDN-DPDK is not an edge forwarder).
> P7 avoid unnecessary generality
> Although consumers may use any prefix name to perform name discovery, 
> this
> is a rarely used feature. A well-designed application would use a
> consistent prefix name to perform name discovery.
> P10 pass hints in protocol headers
> PIT token is passed in the hop-by-hop header, so that PIT lookup can 
> be
> greatly simplified.
> P11 optimize the expected case
> The expected case is that the application is using a consistent prefix 
> name
> to perform name discovery. The network as a whole optimizes for this
> expected case.
> Yours, Junxiao