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

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

Return-Path: <daveoran@orandom.net>
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 36A223A0EF1 for <icnrg@ietfa.amsl.com>; Wed, 22 Apr 2020 08:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVR8TpZsCMep for <icnrg@ietfa.amsl.com>; Wed, 22 Apr 2020 08:44:34 -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 139063A0F94 for <icnrg@irtf.org>; Wed, 22 Apr 2020 08:44:25 -0700 (PDT)
Received: from [174.63.85.102] ([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 03MFiKV0028547 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Apr 2020 08:44:22 -0700
From: "David R. Oran" <daveoran@orandom.net>
To: Junxiao Shi <shijunxiao@email.arizona.edu>
Cc: "Shi, Junxiao" <junxiao.shi@nist.gov>, ICNRG <icnrg@irtf.org>
Date: Wed, 22 Apr 2020 11:44:14 -0400
X-Mailer: MailMate (1.13.1r5684)
Message-ID: <ED69CEE8-2079-4F2C-AAFC-832513EC21EF@orandom.net>
In-Reply-To: <CAOFH+OYfnfaNvpWJM7v7PQ=kQgPV8UgxOHukf=U-T4rbBpMCTQ@mail.gmail.com>
References: <060E1A5C-4B55-4850-900A-6A29C8596861@orandom.net> <CAOFH+Ob2WnjDueHDftfJJ+_DWyH64gd9An7TDMKrNk8h45EbLg@mail.gmail.com> <9CAE2FCA-658A-4032-BDDE-7326BB1C151F@orandom.net> <CAOFH+OYfnfaNvpWJM7v7PQ=kQgPV8UgxOHukf=U-T4rbBpMCTQ@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/icnrg/HRflE8C01bv7C9_wgj8g-4EV_8w>
Subject: Re: [icnrg] [EXT] 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 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
> <https://hdl.handle.net/10150/625652> 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
> <https://books.google.com/books/about/Network_Algorithmics.html?id=fnZ9WWpVK7oC>.
> 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



DaveO