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

["David R. Oran" <[e-mail]>]

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 <[e-mail]> 
> 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