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
- [icnrg] Question on the NIST NDN forwarder David R. Oran
- Re: [icnrg] [EXT] Question on the NIST NDN forwar… Junxiao Shi
- Re: [icnrg] [EXT] Question on the NIST NDN forwar… David R. Oran
- Re: [icnrg] [EXT] Question on the NIST NDN forwar… Junxiao Shi
- Re: [icnrg] [EXT] Question on the NIST NDN forwar… David R. Oran
- Re: [icnrg] [EXT] Question on the NIST NDN forwar… Junxiao Shi