<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Actually what is awesome about the Kite solution is that the anchor point will be the final destination from the perspective of Interest sender(unlike previous rendezvous point based solutions), and since the ap is supposed to be fixed, there is no need for updating FIB entries. But when the mobile endpoint gets farther from access range of the anchor point, the solution starts to become something like previous proxy based ones and thus we will have the triangle routing issue. Unless there would be some mechanism to change anchor point optimally, which I didn't see such in the Kite TR.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 16, 2015 at 12:20 AM, Wentao Shang <span dir="ltr"><<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span class="">On Sun Feb 15 2015 at 12:09:54 PM Tai-Lin Chu <<a href="mailto:tailinchu@gmail.com" target="_blank">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></span><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><span class="HOEnZb"><font color="#888888"><div><br></div><div>Wentao</div></font></span><div><div class="h5"><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></div></div>
<br>_______________________________________________<br>
Ndn-interest mailing list<br>
<a href="mailto:Ndn-interest@lists.cs.ucla.edu">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/mailman/listinfo/ndn-interest</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div dir="rtl"><font face="tahoma, sans-serif">خندان باشید</font></div><div dir="rtl"><font face="tahoma, sans-serif">با تشکر</font></div></div></div>
</div>