[Ndn-interest] retrieving named data and layers (was Re: any comments on naming convention?

christian.tschudin at unibas.ch christian.tschudin at unibas.ch
Sun Sep 21 06:21:33 PDT 2014

Hi Marc, Tai-Lin and all

to me, this feasibility-vs-drawback-of-selectors discussion has traits 
of an unproductive binary showdown, while I think it would be more 
interesting to understand and enable heterogeneity (inevitable in an 
evolving protocol world).

Could, for example, ways be found such that selector-carrying interests 
can traverse an exact-match stretch (and work with the caching being 
done there)?

I would see a yes to above question as a desirable specialization: 
simpler forwarding semantics would be deployed in domains with high 
speed, high volume or special technology like optical, richer forwarding 
functions whereever possible, functionally necessary or economically 
justifiable (and to still have some in-network optimization benefits).

Here is a layout of a possible layering where CCNx and NDN live 
side-by-side (layers 3.b and 3.c):

   4.b) numerous applications

----- fancy data access ----

   4.a) many high-level APIs, from prodCons, pubSub, and groupComm to sync

   3.c) a few "discovery+selection APIs", mapping to either or a combination of
        - exact match + selProtocol
        - selectors in various shades (regExp)
        - named functions

   3.b) heterogeneous concatenation of NDN and CCNx stretches

   3.a) virtualization/redirection/fragm layer (common to NDN and CCNx)

   2.b) one common wire format and naming convent. (covering layers up to 3.c)

----- raw media access -------

   2.a) link

In that picture, CCNx would have a top-heavy stack: selection/discovery 
protocol at 3.c, lean forwarding at 3.b.

NDN has priorities inverted: small or empty 3.c layer, but more involved 
forwarding semantics at 3.b.

I added 3.a (which to me relates to the fixed header discussion) because 
I think this is missing so far.

Looking forward to comments. Would the Paris ICNRG interim meeting be a 
place to discuss this picture?

best, christian.

On Sun, 21 Sep 2014, Marc.Mosko at parc.com wrote:

> No matter what the expressiveness of the predicates if the forwarder 
> can send interests different ways you don't have a consistent 
> underlying set to talk about so you would always need non-range 
> exclusions to discover every version.
> Range exclusions only work I believe if you get an authoritative 
> answer.  If different content pieces are scattered between different 
> caches I don't see how range exclusions would work to discover every 
> version.
> I'm sorry to be pointing out problems without offering solutions but 
> we're not ready to publish our discovery protocols.
> Sent from my telephone
>> On Sep 21, 2014, at 8:50, "Tai-Lin Chu" <tailinchu at gmail.com> wrote:
>> I see. Can you briefly describe how ccnx discovery protocol solves the
>> all problems that you mentioned (not just exclude)? a doc will be
>> better.
>> My unserious conjecture( :) ) : exclude is equal to [not]. I will soon
>> expect [and] and [or], so boolean algebra is fully supported.  Regular
>> language or context free language might become part of selector too.

More information about the Ndn-interest mailing list