<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [Ndn-interest] NDN-friendly Mobility solutions</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Sorry. The last one was from me. It was a mistake.<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Muhammad Sabet [<A HREF="mailto:mhasabet@gmail.com">mailto:mhasabet@gmail.com</A>]<BR>
Sent: Mon 2/16/2015 10:12 AM<BR>
To: Wentao Shang<BR>
Cc: Tai-Lin Chu; Muhammad Hosain Abdollahi Sabet; ndn-interest@lists.cs.ucla.edu<BR>
Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions<BR>
<BR>
Actually what is awesome about the Kite solution is that the anchor point<BR>
will be the final destination from the perspective of Interest<BR>
sender(unlike previous rendezvous point based solutions), and since the ap<BR>
is supposed to be fixed, there is no need for updating FIB entries. But<BR>
when the mobile endpoint gets farther from access range of the anchor<BR>
point, the solution starts to become something like previous proxy based<BR>
ones and thus we will have the triangle routing issue. Unless there would<BR>
be some mechanism to change anchor point optimally, which I didn't see such<BR>
in the Kite TR.<BR>
<BR>
On Mon, Feb 16, 2015 at 12:20 AM, Wentao Shang <wentaoshang@gmail.com><BR>
wrote:<BR>
<BR>
><BR>
><BR>
> On Sun Feb 15 2015 at 12:09:54 PM Tai-Lin Chu <tailinchu@gmail.com> wrote:<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>
>> 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>
>><BR>
><BR>
> Exactly! Devil is always in the detail :)<BR>
><BR>
> However, in this case you can make more assumptions about the repo: it<BR>
> will be always on line and perhaps not moving; it will have a routable<BR>
> prefix (which is a very important distinction because normal consumers do<BR>
> not have routable prefix) so that you can play tricks like<BR>
> Interest-Interest communication or use the Kite solution (Kite is designed<BR>
> exactly for this scenario).<BR>
><BR>
> Wentao<BR>
><BR>
><BR>
>><BR>
>> On Sun, Feb 15, 2015 at 11:18 AM, Wentao Shang <wentaoshang@gmail.com><BR>
>> wrote:<BR>
>> > While any solution must be based on the specific application scenario,<BR>
>> 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<BR>
>> to a<BR>
>> > moving target. Therefore the principle is to find something invariant<BR>
>> and<BR>
>> > use that as an indirection, which is essentially the same idea as<BR>
>> 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<BR>
>> let<BR>
>> > the producer register its current location to a general mapping system<BR>
>> (e.g,<BR>
>> > NDNS); then the consumer can send Interest to the producer's latest<BR>
>> 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<BR>
>> 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<BR>
>> the<BR>
>> > repo instead of talking to the producer directly.<BR>
>> ><BR>
>> > This design also applies to sensor networks where the producer has<BR>
>> 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<BR>
>> idea<BR>
>> > of NDN routing via self-learning. The key idea is to utilize NDN's<BR>
>> 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>
>> > <M.AbdollahiSabet@mail.sbu.ac.ir> wrote:<BR>
>> >><BR>
>> >> Good point! I agree that NDN supports subscriber mobility in it's<BR>
>> 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<BR>
>> example,<BR>
>> >> the application scenario we are talking about could be voice/video<BR>
>> chat when<BR>
>> >> both caller and callee are mobile. How could we consider it in a<BR>
>> 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 [<A HREF="mailto:wentaoshang@gmail.com">mailto:wentaoshang@gmail.com</A>]<BR>
>> >> Sent: Sun 2/15/2015 3:47 AM<BR>
>> >> To: Muhammad Hosain Abdollahi Sabet; Lixia Zhang;<BR>
>> >> ndn-interest@lists.cs.ucla.edu<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>
>> >> M.AbdollahiSabet@mail.sbu.ac.ir> wrote:<BR>
>> >><BR>
>> >> > Thank you so much for answering.<BR>
>> >> > Actually it struck my mind that "it" is unclear, which I'm sorry for<BR>
>> the<BR>
>> >> > ambiguity. The second one was the closest one. I meant: "Is the<BR>
>> 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<BR>
>> 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<BR>
>> 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<BR>
>> it a<BR>
>> >> requirement from specific application in your mind? NDN shifts away<BR>
>> from<BR>
>> >> the P2P connection model and therefore provides new opportunity for<BR>
>> better<BR>
>> >> mobility support. Perhaps it is more efficient to design your<BR>
>> 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<BR>
>> 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<BR>
>> 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<BR>
>> it<BR>
>> >> is<BR>
>> >> impossible to maintain a stable topology, broadcast/multicast may be<BR>
>> 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<BR>
>> 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<BR>
>> can<BR>
>> >> > approximate location of endpoint while pinpointing location of<BR>
>> endpoint<BR>
>> >> > can<BR>
>> >> > be postponed to last steps.<BR>
>> >> > I just listed some of the challenges I faced till now. I'll be<BR>
>> 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 [<A HREF="mailto:lixia@cs.ucla.edu">mailto:lixia@cs.ucla.edu</A> <lixia@cs.ucla.edu>]<BR>
>> >> > Sent: Fri 2/13/2015 8:26 PM<BR>
>> >> > To: Muhammad Hosain Abdollahi Sabet<BR>
>> >> > Cc: ndn-interest@lists.cs.ucla.edu<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>
>> >> > M.AbdollahiSabet@mail.sbu.ac.ir> 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<BR>
>> topology<BR>
>> >> > like<BR>
>> >> > MANET (VANET in particular), it's been developing like a charm. But<BR>
>> 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>
>> ...)<BR>
>> >> > seems to have a NDN-likely technique. I'm eager to work on it as my<BR>
>> 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<BR>
>> 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<BR>
>> effort<BR>
>> >> > on<BR>
>> >> > this problem. We *are* developing solutions, first for specific<BR>
>> >> > application scenarios, which help us understand how to provide<BR>
>> 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>
>> >> > _______________________________________________<BR>
>> >> > Ndn-interest mailing list<BR>
>> >> > Ndn-interest@lists.cs.ucla.edu<BR>
>> >> > <A HREF="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</A><BR>
>> >> ><BR>
>> >><BR>
>> ><BR>
>> > _______________________________________________<BR>
>> > Ndn-interest mailing list<BR>
>> > Ndn-interest@lists.cs.ucla.edu<BR>
>> > <A HREF="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</A><BR>
>> ><BR>
>><BR>
><BR>
> _______________________________________________<BR>
> Ndn-interest mailing list<BR>
> Ndn-interest@lists.cs.ucla.edu<BR>
> <A HREF="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</A><BR>
><BR>
><BR>
<BR>
<BR>
--<BR>
????? ?????<BR>
?? ????<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>