[Ndn-interest] NDN Application with CanBePrefix flag

[christian.tschudin at unibas.ch]

On Fri, 26 Apr 2019, David R. Oran wrote:

>> 2. I wonder if you have any plans to remove CanBePrefix flag in the 
>> near future.
>>
> I can’t speak for the NDN team, obviously (I’m not part of the 
> project and work primarily on CCNx, not NDN), but since discovery is an 
> important/necessary function in any ICN system, if CanBePrefix ever gets 
> removed it would be because it’s replaced with something more powerful 
> and/or efficient, like an explicit discovery protocol on top of 
> exact-match in the basic forwarders.

named functions, perhaps? Many possible candidates come to mind 
(selectors were function calls, after all):

   ndn0.3_interest("/some/path", canBePrefix=True) -->
      what programmers really would like to do:

      /nfn/ndn0.1/rightmost("/some/path")
      /nfn/unix/ls("/some/path")
      /nfn/unix/find("/some/path")
      /nfn/glob(/nfn/unix/ls("/some/path"), "*.pdf")
      /nfn/newest() -> /nfn/tail(/nfn/sort(/nfn/unix/ls("/some/path")),1)

But: the functions will be complex I think, and I doubt that they can be 
pushed into/down the basic forwarder, even not for exact match.

An example of a simple but challenging case would be a RIB pointing to 
two repos, both having registered for the same prefix. A 'LS' request 
must be sent to both repos, and on the return path the results be 
merged. Easier to do this with manifests, but then the merging "basic 
forwarder" must sign the combined manifest. And then we have not talked 
about parametrized LS, yet (e.g. merging sorted file lists ..., and 
making the entries unique), meaning that the real work still is done 
outside the forwarder, we have no in-network aggregation gain.

Back to your suggested discovery protocol: it would have to be super 
simple. Here is an idea: fetch first and last entry (instead of full 
list), which would have a much easier merging task and could efficiently 
work for lexicographically as well as time- or size-sorted lists. I like 
two-line responses (and CAR/CDR) - too bad I failed to apply it to this 
post ;-)

best, c


On Fri, 26 Apr 2019, David R. Oran wrote:

> On 25 Apr 2019, at 21:49, 김학서 wrote:
>
>> Dear All,
>>
>> I am currently designing a NDN application with CanBePrefix flag.(by 
>> using interest.setCanBePrefix(true))
>>
>> I know that CanBePrefix flag is defined in the packet03transition 
>> plan, and it is used in NDN platform.
>> However, I understand that setting CanBePrefix flag for Interest 
>> packet may cause performance degradation issues for PIT processing.
>>
> Well, in high-speed forwarder algorithms, compared to exact match it can 
> cost an order of magnitude or more of forwarding throughput.
>
>> My Questions are following :
>>
>>
>> 1. What do you think about design of applications using CanBePrefix 
>> flag? If necessary, Can I use it?
>>
> Sure, as long as you use it sparingly. The primary suede is to do 
> discovery - to get the first access to a portion of you namespace. From 
> there traverse data either by predicting their names from the schema, or 
> (my preferred method) using Manifests.
>
>> 2. I wonder if you have any plans to remove CanBePrefix flag in the 
>> near future.
>>
> I can’t speak for the NDN team, obviously (I’m not part of the 
> project and work primarily on CCNx, not NDN), but since discovery is an 
> important/necessary function in any ICN system, if CanBePrefix ever gets 
> removed it would be because it’s replaced with something more powerful 
> and/or efficient, like an explicit discovery protocol on top of 
> exact-match in the basic forwarders.
>
>
>> Best Regards,
>> HS Kim
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
> DaveO
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>