[Ndn-interest] NDN-friendly Mobility solutions

Wentao Shang wentaoshang at gmail.com
Sun Feb 15 12:50:46 PST 2015


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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150215/6ab82165/attachment.html>


More information about the Ndn-interest mailing list