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

"David R. Oran" <daveoran@orandom.net> Wed, 22 April 2020 15:11 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 E2B583A0E61 for <icnrg@ietfa.amsl.com>; Wed, 22 Apr 2020 08:11:02 -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 icflRKqCXDHR for <icnrg@ietfa.amsl.com>; Wed, 22 Apr 2020 08:11:00 -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 257A73A0E5B for <icnrg@irtf.org>; Wed, 22 Apr 2020 08:11:00 -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 03MFAsBq027924 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Apr 2020 08:10:57 -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:10:49 -0400
X-Mailer: MailMate (1.13.1r5684)
Message-ID: <9CAE2FCA-658A-4032-BDDE-7326BB1C151F@orandom.net>
In-Reply-To: <CAOFH+Ob2WnjDueHDftfJJ+_DWyH64gd9An7TDMKrNk8h45EbLg@mail.gmail.com>
References: <060E1A5C-4B55-4850-900A-6A29C8596861@orandom.net> <CAOFH+Ob2WnjDueHDftfJJ+_DWyH64gd9An7TDMKrNk8h45EbLg@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/icnrg/ylf8rJNWbvDK0ukBM-y7JgRoOXQ>
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: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…

DaveO.

> 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
> https://github.com/usnistgov/ndn-dpdk/tree/master/container/cs , 
> 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 <daveoran@orandom.net> 
> 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
>>
>>



DaveO