[Ndn-interest] Basic Query about Dual Names for one Content

Tai-Lin Chu tailinchu at gmail.com
Sun Jul 24 08:10:28 PDT 2016


Hi, Syed and Junxiao,

We experimented with LINK for a while. It works fine but there is a
cost in managing LINKs, and its overhead (packet size and
signing/verification) is high. As a result, we explored another
solution on top of NDN.

The idea is to have a set of dedicated nodes for distribution (this
also tries to improve data availability). First, when producer
publishes data, it also specifies possible name aliases (and some
other things) in the content field of data packet.  Second, producer
tries to push the “higher-level” data packet to the raft leader of the
dedicated distribution nodes, and the leader replicates it to other
nodes according to the raft consensus protocol. Third, these dedicated
distribution nodes “compile” one higher-level data packet to many data
packets (with various name alias, signature types, etc) when it is
received.

This idea solves the availability problem, so producer can be off
sometimes. For example, a sensor could use this to save power, without
worrying that cache eviction and sleeping might make its data
unavailable.

In addition to improving availability, higher-level data packet makes
producing data simpler. A producer only needs to publish one data
packet, and the packet can be compiled with different signature types,
and name hierarchies for consumers with various needs. In general, I
think it is hard for ndn applications to pick only one name hierarchy.
In order to embed application design in one name hierarchy, we often
make significant compromises, but it should not be necessary to.

Finally, this is more efficient because there are less signatures to
sign and verify. In many use cases, this idea is like flattening data
packet with LINK.

I wonder there are some other improvements to publishing with
different names. I am open to discuss more.

On Thu, Jul 21, 2016 at 10:26 AM, Junxiao Shi
<shijunxiao at email.arizona.edu> wrote:
> Hi Syed
>
>
>
> Upon learning the correct prefix “10pm”, the consumer has to send a second
> Interest with “10pm”. For all subsequent segments, the consumer can directly
> send “10pm” Interests without first expressing a “2200” Interest and getting
> a redirection.
>
>
>
> The redirection can be in the form of a Link object, as seen in SNAMP paper.
>
> Data /vid/sf/breakingnews/20151231/2200/%00%00
>
>   Content=REDIRECT to /vid/sf/breakingnews/20151231/10pm/%00%00
>
>           Link /vid/sf/breakingnews/20151231/10pm
>
>             => /vid/sf/breakingnews/20151231/2200
>
>           signed by breakingnews.com
>
>   signed by vehicle
>
> However, this implies the Link object needs to be prepared by the original
> publisher.
>
>
>
> A producer application must have registered a prefix in the local forwarder
> to receive the Interest, and construct the Data with redirection when an
> Interest arrives. ContentStore cannot handle it.
>
> Therefore, the best solution is still: make sure the naming scheme is
> consistent.
>
>
>
> Yours, Junxiao
>
>
>
> From: Syed Hassan Ahmed
> Sent: Thursday, July 21, 2016 09:27
> To: Brown, Andrew
> Cc: ndn-interest at lists.cs.ucla.edu
> Subject: Re: [Ndn-interest] Basic Query about Dual Names for one Content
>
>
>
> Dear Prof. Junxiao,
>
>
>
> Thanks for the detailed explanation. I understood the encapsulation idea,
> however, your very last comment is basically endorsing my query, where, the
> appearance of two prefixes may occur for the same content, the consumer has
> to send Interest two times. Because upon the first Interest Type 1
> (referring my previous email), the consumer couldn't retrieve the required
> content, but it has been informed (redirected) to retransmit Interest with
> the valid Name prefix...
>
>
>
> 1. Now here jumps in the attacker? Or Malicious Node? What is the security
> aspect in this case?
>
> 2. Why would a consumer believe this publisher's intention? If the
> redirecting message is only signed by the vehicle?
>
> 3. And through what medium/face this Redirection information will be passed?
> I mean, in a pull based manner, the producer only sends Data, if the prefix
> matches, otherwise, forwarding Daemon gets active for that Interest and
> takes decision depending on the strategy, of course.
>
>
>
> Is there any scheme or architectural discussion available, where, two
> prefixes are used for same content or chunk level retrieval. ?
>
>
>
>
>
>
>
>
>
>
>
> From: Junxiao Shi
> Sent: Thursday, July 21, 2016 03:39
> To: Syed Hassan Ahmed
> Cc: ndn-interest at lists.cs.ucla.edu
> Subject: Re: [Ndn-interest] Basic Query about Dual Names for one Content
>
>
>
> Hi Syed
>
>
>
> A properly designed application should use a consistent naming scheme to
> access the same content. Choose one of "10pm" and "2200", and stick to it.
>
> If the content is published under two different names, but the network is
> not aware of this situation, in-network caching would be ineffective when
> the Interest carries a different name.
>
>
>
> If the data mule (vehicle) knows the dual name situation, it could respond
> to "2200" Interest with "10pm" Data through encapsulation;
>
> Data /vid/sf/breakingnews/20151231/2200/%00%00
>
>   Content=Data /vid/sf/breakingnews/20151231/10pm/%00%00
>
>           Content=news headlines
>
>           signed by breakingnews.com
>
>   signed by vehicle
>
> Encapsulation is necessary because Interest name must be a prefix of Data
> name, but breakingnews.com signature is bound to the "10pm" name and the
> vehicle does not have breakingnews.com signing key.
>
> Or the response could use redirection:
>
> Data /vid/sf/breakingnews/20151231/2200/%00%00
>
>   Content=REDIRECT to /vid/sf/breakingnews/20151231/10pm/%00%00
>
>   signed by vehicle
>
> Upon receiving this response, the consumer should reexpress the Interest
> with "10pm" name.
>
>
>
> Yours, Junxiao
>
>
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>




More information about the Ndn-interest mailing list