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

Junxiao Shi <> Wed, 22 April 2020 14:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB9323A0E73 for <>; Wed, 22 Apr 2020 07:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xGJ4XpSMOM5e for <>; Wed, 22 Apr 2020 07:59:53 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E0A0D3A0E54 for <>; Wed, 22 Apr 2020 07:59:52 -0700 (PDT)
Received: by with SMTP id i9so575950ool.5 for <>; Wed, 22 Apr 2020 07:59:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VVXpt0iPuMBwHYxci7LhbELCGY+1EcHtgVNS6pjyiOk=; b=hBn0cs7Oo4AOB7iwMxqEeYjLQfh7CiQ/bg+gE+y0ltDkfPxbhJJTuo7SDfnt2SvVyK SIO/b0/dpsYwInChYQCeDPqA+bUf0Ht7v6taOsQJki24VnYhkPeche8smZPVpHnbbINT X6MK27jzneOOf5NrlLqdFkhove9/3/3h/lZ3JK+2vb0gP8PfdclPMKskNzlrA4hCCkJT O1BAjxnyeqlcTQVsRIJbwDZgH2If5ccTIGmxIq86bipygSPZs80U74Kf7MsKW9ZcFdTD bJsFDPCpNob+aUVIxRp/eI96qfW03kkji0NEdCbfUxkAhVVLdTYzUIRv4PEOPq9vTpiH SmKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VVXpt0iPuMBwHYxci7LhbELCGY+1EcHtgVNS6pjyiOk=; b=cEhIOQUacDclKIYdM/cOdR81D4IIui4AFa+GZrle2exJMnX79K0xFiZKpskHNisK34 a6GDPHSHIhPc5QBemImF5tF7EJ+9RwQlR6u8CS6lVTXXMRic+ZcGLOwKqntSgQwve/ln LMuErX6lYKaHfqbqDrkEgPkCpZ/zCv0DCG1gE9NCNlJsZFgwcblv72jAwrSgA6mMpBZP FY7vtFnwFnl88tC/z6Mv1TSHyWAeuWBo3qaEeROjE+zneUc8g3TZrJspabmEW2el++iQ N7cGkUo119P9xUR0w2U3RTYTqXO5u21Pl7l+ZILXWXz1q0hkJUpL14+5KobRXSKRIb5q HPsw==
X-Gm-Message-State: AGi0PuZwf94FEY1L4ulqbMMNbFRTRoMaBMOW2rLut69+BOFkL9fR1geP sph4OqoRB+eKU3o+9IoX66WGnC28mFsFkiJPqZY0jhc5mi7+28mLTpLzfzw9yrvXLUgke/LJAVp 7p3hSWWv08Cc=
X-Google-Smtp-Source: APiQypK1DLa8rFqrRVcQ/cbkqs8jDK1/xChi7M1JXw1Mg2mXzIFoRtZlSPpjvvKCt0Tsv8U/oe9PdCFOPhTbRoQz5kY=
X-Received: by 2002:a4a:4187:: with SMTP id x129mr10093226ooa.34.1587567591843; Wed, 22 Apr 2020 07:59:51 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Junxiao Shi <>
Date: Wed, 22 Apr 2020 10:59:16 -0400
Message-ID: <>
To: "David R. Oran" <>
Cc: "Shi, Junxiao" <>, ICNRG <>
Content-Type: multipart/alternative; boundary="0000000000005e8ec205a3e262ee"
X-ua-ms: gsuite
Archived-At: <>
Subject: Re: [icnrg] [EXT] Question on the NIST NDN forwarder
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Apr 2020 15:00:02 -0000

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

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