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

[Marc.Mosko at parc.com]

Christian,

Attached is a proposal we were working with to use the ccnx 0.x selector discovery over exact match names.  Basically, all the selectors are TLV encoded into a single name component and the response is encapsulated with a new PayloadType.  We do not have any code around this, it was just an early proposal of ours.

We have not advanced this route because, as you may notice from the other thread on Discovery, is that I think a discovery protocol should do more than what selectors offer.  So, if we are going to run one (or more) discovery protocols over exact match, I think it should be a different protocol than selectors.

That said, to offer compatibility to ccnx 0.x or ndn applications, one could use a scheme like this.

Marc


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ccnx-mosko-selectors-00.txt
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20140922/9bf3d109/attachment.txt>
-------------- next part --------------



On Sep 21, 2014, at 3:21 PM, christian.tschudin at unibas.ch wrote:

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2595 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20140922/9bf3d109/attachment.bin>