[Ndn-interest] NDN-friendly Mobility solutions

Sun Feb 15 12:09:53 PST 2015

> 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 :)

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
>