<div dir="ltr"><br><br><div class="gmail_quote">On Sun Feb 15 2015 at 12:09:54 PM Tai-Lin Chu <<a href="mailto:tailinchu@gmail.com">tailinchu@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as indirection: you can have your producer publish its data to a well-known location, such as an NDN repo, so that the consumer can fetch data from the repo instead of talking to the producer directly.<br>
<br>
I think there is something missing in this design. When producer needs<br>
to send its data to the repo, the repo becomes the client. As a<br>
result, this looks like a recursive algorithm without base case :)<br></blockquote><div><br></div><div>Exactly! Devil is always in the detail :)</div><div><br></div><div>However, in this case you can make more assumptions about the repo: it will be always on line and perhaps not moving; it will have a routable prefix (which is a very important distinction because normal consumers do not have routable prefix) so that you can play tricks like Interest-Interest communication or use the Kite solution (Kite is designed exactly for this scenario).</div><div><br></div><div>Wentao</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Sun, Feb 15, 2015 at 11:18 AM, Wentao Shang <<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>> wrote:<br>
> While any solution must be based on the specific application scenario, there<br>
> are still some general guidelines that you may consider:<br>
><br>
> 1/ Producer mobility is hard because the consumer has to shoot Interest to a<br>
> moving target. Therefore the principle is to find something invariant and<br>
> use that as an indirection, which is essentially the same idea as locator/id<br>
> separation.<br>
><br>
> 2/ One way to do that is to directly apply the LISP concept to the NDN<br>
> network: you can assign a location-independent name to the producer and let<br>
> the producer register its current location to a general mapping system (e.g,<br>
> NDNS); then the consumer can send Interest to the producer's latest location<br>
> using either Interest encapsulation or forwarding hint.<br>
><br>
> This design is useful if your application must enforce P2P communication<br>
> (e.g., if you want to send control commands to a specific sensor on a plane<br>
> that is flying from LAX to JFK).<br>
><br>
> 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as<br>
> indirection: you can have your producer publish its data to a well-known<br>
> location, such as an NDN repo, so that the consumer can fetch data from the<br>
> repo instead of talking to the producer directly.<br>
><br>
> This design also applies to sensor networks where the producer has limited<br>
> storage capacity and/or low duty-cycle so that it must offload the data<br>
> storage task to a more powerful device.<br>
><br>
> 4/ I remember Prof. Lixia showed us some slides in her class about the idea<br>
> of NDN routing via self-learning. The key idea is to utilize NDN's stateful<br>
> forwarding plain to estimate the validity of a route on the fly.<br>
> Unfortunately I couldn't remember any reference for that work.<br>
><br>
> Hope this may be helpful to your research.<br>
><br>
> Wentao<br>
><br>
><br>
> On Sun Feb 15 2015 at 3:47:47 AM Muhammad Hosain Abdollahi Sabet<br>
> <<a href="mailto:M.AbdollahiSabet@mail.sbu.ac.ir" target="_blank">M.AbdollahiSabet@mail.sbu.ac.<u></u>ir</a>> wrote:<br>
>><br>
>> Good point! I agree that NDN supports subscriber mobility in it's nature<br>
>> and as you said most of mobility issues in subscriber-side scenarios<br>
>> disappear automatically. But what about some producer ones?  As an example,<br>
>> the application scenario we are talking about could be voice/video chat when<br>
>> both caller and callee are mobile. How could we consider it in a non-P2P<br>
>> model?<br>
>><br>
>> Could you please guide me to find about possibility for intelligent<br>
>> broadcast/multicast using self-learning path selection ?<br>
>><br>
>><br>
>><br>
>><br>
>> -----Original Message-----<br>
>> From: Wentao Shang [mailto:<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>]<br>
>> Sent: Sun 2/15/2015 3:47 AM<br>
>> To: Muhammad Hosain Abdollahi Sabet; Lixia Zhang;<br>
>> <a href="mailto:ndn-interest@lists.cs.ucla.edu" target="_blank">ndn-interest@lists.cs.ucla.edu</a><br>
>> Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions<br>
>><br>
>> On Sat Feb 14 2015 at 9:26:50 AM Muhammad Hosain Abdollahi Sabet <<br>
>> <a href="mailto:M.AbdollahiSabet@mail.sbu.ac.ir" target="_blank">M.AbdollahiSabet@mail.sbu.ac.<u></u>ir</a>> wrote:<br>
>><br>
>> >  Thank you so much for answering.<br>
>> > Actually it struck my mind that "it" is unclear, which I'm sorry for the<br>
>> > ambiguity. The second one was the closest one. I meant: "Is the solution<br>
>> > for producer-side mobility clear enough that there hasn't been real<br>
>> > attempt<br>
>> > about it?<br>
>><br>
>> > I'll be absolutely glad to help. ?As far as I understand we have another<br>
>><br>
>><br>
>> > paradigm shifting again in some mobility application scenarios like<br>
>> > mobile<br>
>> > caller-callee. NDN shifts networking from host-centric(point to point)<br>
>> > to a<br>
>> > content-centric architecture. And now we want to make point to point<br>
>> > connection overlay of NDN. Right?<br>
>> ><br>
>> Not sure why you want to make point-to-point connection over NDN. Is it a<br>
>> requirement from specific application in your mind? NDN shifts away from<br>
>> the P2P connection model and therefore provides new opportunity for better<br>
>> mobility support. Perhaps it is more efficient to design your application<br>
>> in the NDN model (in which case some mobility issue may disappear<br>
>> automatically) than to fit the old model into the new architecture.<br>
>><br>
>><br>
>> > So I think using some IP-like producer mobility solutions is not<br>
>> > avoidable. On the other hand some of NDN features like being broadcast<br>
>> > finendly which is referred to in "A New Perspective in Mobility<br>
>> > Support''<br>
>> > as a suggestion, isn't practical in large scale because of producing<br>
>> > heavy<br>
>> > overhead of controlling data(specially in hard-state mode).<br>
>> ><br>
>> Broadcast is impractical for large scale IP network. But NDN has a smarter<br>
>> forwarding plain which opens possibility for intelligent<br>
>> broadcast/multicast using self-learning path selection and traffic<br>
>> reduction.<br>
>><br>
>> Different mobility solutions are designed for different application<br>
>> scenarios. In some extreme cases where the network is so dynamic that it<br>
>> is<br>
>> impossible to maintain a stable topology, broadcast/multicast may be the<br>
>> only choice.<br>
>><br>
>><br>
>> > Furthermore, hierarchical naming brings some location dependency,<br>
>> ><br>
>> It is not that hierarchical naming brings location dependency. Any<br>
>> identifier that is used in routing and forwarding will cause location<br>
>> dependency. That's why people invented the concept of Locator/ID<br>
>> separation, which is mentioned in the mobility TR. The "forwarding hint"<br>
>> is<br>
>> one way to implement that in NDN.<br>
>><br>
>> Wentao<br>
>><br>
>><br>
>> > and maybe we need some conventions in this field, in which network can<br>
>> > approximate location of endpoint while pinpointing location of endpoint<br>
>> > can<br>
>> > be postponed to last steps.<br>
>> > I just listed some of the challenges I faced till now. I'll be grateful<br>
>> > to<br>
>> > know your opinion about them.<br>
>> ><br>
>> > Thanks again,<br>
>> > Sabet<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > -----Original Message-----<br>
>><br>
>> > From: Lixia Zhang [mailto:<a href="mailto:lixia@cs.ucla.edu" target="_blank">lixia@cs.ucla.edu</a> <<a href="mailto:lixia@cs.ucla.edu" target="_blank">lixia@cs.ucla.edu</a>>]<br>
>> > Sent: Fri 2/13/2015 8:26 PM<br>
>> > To: Muhammad Hosain Abdollahi Sabet<br>
>> > Cc: <a href="mailto:ndn-interest@lists.cs.ucla.edu" target="_blank">ndn-interest@lists.cs.ucla.edu</a><br>
>> > Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions<br>
>> ><br>
>> ><br>
>> > > On Feb 12, 2015, at 2:16 PM, Muhammad Hosain Abdollahi Sabet <<br>
>> > <a href="mailto:M.AbdollahiSabet@mail.sbu.ac.ir" target="_blank">M.AbdollahiSabet@mail.sbu.ac.<u></u>ir</a>> wrote:<br>
>> > ><br>
>> > > Hello everyone.<br>
>> > > I've been studying NDN for a couple of months now. For supporting<br>
>> > mobility in environments without any clear infrastructure and topology<br>
>> > like<br>
>> > MANET (VANET in particular), it's been developing like a charm. But as<br>
>> > far<br>
>> > as I've learned, it's producer-side mobility support in large scales<br>
>> > still<br>
>> > has some serious challenges, particularly in scenarios like mobile<br>
>> > caller-callee. And as "A New Perspective on Mobility Support" has<br>
>> > reported,<br>
>> > none of the proposed solutions(Proxy based, Rendezvous point based, ...)<br>
>> > seems to have a NDN-likely technique. I'm eager to work on it as my B.S<br>
>> > thesis. But the problem is, when I look at the ICN workshops,<br>
>> > conferences,<br>
>> > articles, posters, demos and etc, I cannot find real attempts on<br>
>> > this(unless Kite I may say). Not that I've seen for example about<br>
>> > Routing<br>
>> > or Security. And now I'm wondering: Is it really that clear?! Maybe you<br>
>> > can<br>
>> > guide me to a vision I don't have.<br>
>> > ><br>
>> > > Thanks,<br>
>> > > Sabet<br>
>> ><br>
>> > Sabet,<br>
>> ><br>
>> > thanks for your msg. I wonder what you meant by "Is it really that<br>
>> > clear?!".<br>
>> > If you are asking whether it is clear that NDN can offer superior<br>
>> > mobility<br>
>> > support than TCP/IP, then you know the answer is YES, right?<br>
>> > If you are asking whether mobile producer solutions have been fully<br>
>> > developed: it is still being developed, hence the need for your effort<br>
>> > on<br>
>> > this problem.  We *are* developing solutions, first for specific<br>
>> > application scenarios, which help us understand how to provide general<br>
>> > solutions.<br>
>> > If you are asking for examples of routing solutions: I'm sure you've<br>
>> > seen<br>
>> > NLSR work as an example; we are also actively working on hyperbolic<br>
>> > routing<br>
>> > as potential long term directly.<br>
>> > For security, you may look into recent NDN retreat which focused on<br>
>> > security solution development.<br>
>> ><br>
>> > Lixia<br>
>> ><br>
>> ><br>
>> ><br>
>> >  ______________________________<u></u>_________________<br>
>> > Ndn-interest mailing list<br>
>> > <a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br>
>> > <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/ndn-interest</a><br>
>> ><br>
>><br>
><br>
> ______________________________<u></u>_________________<br>
> Ndn-interest mailing list<br>
> <a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br>
> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/ndn-interest</a><br>
><br>
</blockquote></div></div>