[Ndn-interest] NDN-friendly Mobility solutions

[Muhammad Hosain Abdollahi Sabet]

Sorry. The last one was from me. It was a mistake.


-----Original Message-----
From: Muhammad Sabet [mailto:mhasabet at gmail.com]
Sent: Mon 2/16/2015 10:12 AM
To: Wentao Shang
Cc: Tai-Lin Chu; Muhammad Hosain Abdollahi Sabet; ndn-interest at lists.cs.ucla.edu
Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions
 
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.

On Mon, Feb 16, 2015 at 12:20 AM, Wentao Shang <wentaoshang at gmail.com>
wrote:

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


-- 
????? ?????
?? ????

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150216/7af92dbc/attachment.html>