[Nfd-dev] Unicast communication in a distributed application in NDN paradigm

Thu Oct 23 21:13:25 PDT 2014

> On Oct 23, 2014, at 8:59 PM, Haroon Rashid <haroonr at iiitd.ac.in> wrote:
> 
> >>If B and D use the exact same Interest, then the PIT entry will have an appropriate set of face records that tells the node where to
>  relay the returning Data.
>  
> 
>  
> >>>>Consider if I want to maintain a log (name) of all machines at “C” which requested for some computational results.  In above scenario with interest aggregation at intermediate 
> 
> routers machine “c” will never be able to know which all machines took benefit from it. In such a case, how can machine “C” maintain a log of all requesting machines?
> 
>  

This sounds like a different problem because you want to know the identity of the requester. There is nothing in an Interest to identify the sender. Conceptually, a PIT entry is providing at most “the Interest came from that way”. You would need to add identifying information to the Interest. For example, the name could encode “Perform computation X on 'Alice’s machine’ for ‘Bob’ “.

>  
> >>Selectors don’t change this. In fact, selectors are not used for routing the Interests to C in the first place. The selector’s job is to further specify the 
> requested Data (“select something”) when there are one or more options (e.g. in a CS or repo) and determining which PIT entries can be satisfied by a returning 
> Data packet.
>  
> >>>I was thinking of placing the public key of C in the Selectors part so as to direct the Interest to C in the first place. If it is not possible in this way, then how can I direct the interest to
>  C in the first place? In other words, how should I use the public key of C for directing the Interest to "C" only? Should I use this public key as a part of the name itself rather 
> than specifiying it in other parts of Interest packet?

Ideally, you should use a sufficiently specific name so that the Interest will be routed to C. Names are the primary driver of forwarding; we do longest prefix match to find the set of possible next hops. Forwarding strategy then chooses which one(s) to use. In the general case, intermediate routers don’t know that there is some machine named C. Instead, they have a bunch of prefixes and one or more may eventually lead to the machine known to the requester as C. Therefore, you want to use a sufficiently specific name in your Interest to make sure your request is getting to the right place.

I don’t think it matters too much how you choose to identify C in your protocol. Using the public key digest to name the destination is one option, but it has no special power over forwarding. It’s just another name component to the network. You could just as easily, and possibly prefer to, use a human readable name to refer to C.

Encryption guarantees that only C can process the message. For example, when the longest matching routing prefix is not specific to C. As an example usage, suppose you are expressing the computation as one or more name components. You could encrypt the computation components under C’s key to ensure only C is able to perform the computation.

>  
> 
> On Thu, Oct 23, 2014 at 6:42 PM, Steve DiBenedetto <dibenede at cs.colostate.edu <mailto:dibenede at cs.colostate.edu>> wrote:
> 
>> On Oct 23, 2014, at 1:10 AM, Haroon Rashid <haroonr at iiitd.ac.in <mailto:haroonr at iiitd.ac.in>> wrote:
>> 
>> Thanks, Steve and Jeff for useful references.
>> 
>> 
>> 
>> First, I want to make it clear that I don’t have any particular application in my mind right now. What all I am thinking of completely unicast communication in NDN in both directions (source->destination && destination->source), i.e., sort of end to end connection. I mean a distributed computing type of application (not a lighting one). While going through the paper (lighting), I found that we can communicate with the target machine using its public key. This gives me an answer to one part of my question, but, now my other issue is to differentiate the tasks from different machines. To make it easy to understand let us use the following NDN network with 5 machines connected via LAN.
>> 
>> 
>>                                       <Network.JPG>
>> 
>>  
>>  Now suppose both “B” and “D” need some computational results from “C” and hence accordingly sent the interest packet containing public key of “C” so that only C (not A or E) can act on the Interest packet. Therefore, “C” has received interests and did some computations and now it needs to send back computational results to “B” and “D” only. Now, accordingly these results should be unicasted back by using the public keys of B and D. But,  “C” does not know anything about these (B and D) because interest packet  from “B and D”  to “C” does not contain any information about their origin.  So, I want to know how “C” will send  specific results back to these respective machines.
>> 
>> 
> 
> How important is it for B and D to be the only possible recipients? If it’s ok for others to receive the response (e.g. cache hit for a future request from A), then I don’t think you need to worry about encrypting the response.
> 
> If you need B and D to be the unique recipients of their respective requests (B can’t read D’s response and vice versa), then you will want to encrypt. However, you don’t need B or D’s public key for this. Instead, B and D should provide a symmetric key to C as part of the computation request (i.e. encrypt the symmetric key towards C and place in a name component).
> 
> We used this basic technique implementing ANDaNA (NDN Tor). There’s also a session-based version so that future requests use symmetric keys exclusively (encrypting towards C and the response). See: http://www.internetsociety.org/andana-anonymous-named-data-networking-application <http://www.internetsociety.org/andana-anonymous-named-data-networking-application> 
>> I know that pending interests in PIT of “C” and in-between routers might help but still I am not quite confident that it will work successfully. This is because in the Interest packet I used Selectors part to reach “C” , while as in the Data packet I don’t find any such field to specify specific origin machines (B or D). Can anyone  help me in the understanding of the same or point out  to some references from where I can understand the same.
>> 
> 
> First and foremost, so long as the PIT entry is present, B and D will get a Data packet back (assuming the computation finishes in time, etc…). If B and D use the exact same Interest, then the PIT entry will have an appropriate set of face records that tells the node where to relay the returning Data. The same thing happens if B and D use different Interests, except there’s now one PIT entry for each with their respective face records.
> 
> Selectors don’t change this. In fact, selectors are not used for routing the Interests to C in the first place. The selector’s job is to further specify the requested Data (“select something”) when there are one or more options (e.g. in a CS or repo) and determining which PIT entries can be satisfied by a returning Data packet.
> 
>>  
>> Thanking you,   
>> 
>>  
>> 
>> On Thu, Oct 23, 2014 at 1:29 AM, Burke, Jeff <jburke at remap.ucla.edu <mailto:jburke at remap.ucla.edu>> wrote:
>> 
>> I agree with Steve – the cases in the publications he sites are pretty specific, and are actually about targeting a physical object (light) not a computing node.  We could make suggestions if you could describe the application.
>> Jeff
>> 
>> From: Steve DiBenedetto <dibenede at cs.colostate.edu <mailto:dibenede at cs.colostate.edu>>
>> Date: Wed, 22 Oct 2014 09:42:34 -0400
>> To: Haroon Rashid <haroonr at iiitd.ac.in <mailto:haroonr at iiitd.ac.in>>
>> Cc: Nitinder Mohan <nitinder1369 at iiitd.ac.in <mailto:nitinder1369 at iiitd.ac.in>>, "<nfd-dev at lists.cs.ucla.edu <mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu <mailto:nfd-dev at lists.cs.ucla.edu>>, Pushpendra Singh <psingh at iiitd.ac.in <mailto:psingh at iiitd.ac.in>>, "ndn-app at lists.cs.ucla.edu <mailto:ndn-app at lists.cs.ucla.edu>" <ndn-app at lists.cs.ucla.edu <mailto:ndn-app at lists.cs.ucla.edu>>
>> Subject: Re: [Nfd-dev] Unicast communication in a distributed application in NDN paradigm
>> 
>> Hi,
>> 
>> I have not read these specific papers, but I recall their topics being similar to what you’re after:
>> 
>> http://named-data.net/wp-content/uploads/nomen13.pdf <http://named-data.net/wp-content/uploads/nomen13.pdf>
>> http://named-data.net/wp-content/uploads/TRlighting.pdf <http://named-data.net/wp-content/uploads/TRlighting.pdf>
>> 
>> In the past, I think we (the project) have discussed how NDN provides a superset of IP’s capabilities. If you really need point to point, there are mechanisms to get there. As you suggested, using a name that uniquely identifies an endpoint is something in that direction. Encrypting the Interest’s name and the Data response can further lock things down.
>> 
>> **However**, it sounds like you are questioning whether or not this is the communication model you really want. We may be able to offer some suggestions if you can describe the application.
>> 
>> -Steve
>> 
>> 
>>> On Oct 22, 2014, at 7:16 AM, Haroon Rashid <haroonr at iiitd.ac.in <mailto:haroonr at iiitd.ac.in>> wrote:
>>> 
>>> Hello All,
>>> 
>>> I am planning to develop a distributed application using NDN paradigm. In this application, each machine should be able to do unicast communication and should not use shared memory (like ccnsync/chronosync). If I am correct, we already have a distributed NDN-chat application which is of broadcast nature (because message written in a namespace gets broadcasted to all members in the same namespace) and hence it uses the shared memory concept. Is there any other distributed application in NDN where unicast communication is supported? If not, how Can I achieve the same in NDN? Should I put the name of the target machine in the Interest packet (name) itself for facilitating such communication? But, would that will not change the basic architecture of NDN/CCN paradigm?
>>> 
>>> -- 
>>> Haroon Rashid
>>> 
>>> 
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>> 
>> _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>> 
>> 
>> -- 
>> Haroon Rashid
>> 
>> 
> 
> 
> 
> 
> -- 
> Haroon Rashid
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20141023/a18112cb/attachment.html>