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

[Junxiao Shi <[e-mail]>]

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
>
>