[Ndn-interest] NDN-friendly Mobility solutions
tailinchu at gmail.com
Fri Feb 20 15:20:37 PST 2015
> there are plenty of familiar services - skype, webex, gotomeeting - that use a managed, distributed cdn service for rendezvous, at least. that allows clients with topological names (at home, at work, on mobile network) to rendezvous with one another.
The situation is very different if we want to do this purely in ndn.
> I don't quite follow that remark about not having a routable name. if you can't be reached, if you don't have a routable name, then ... you can't be reached?
there are two different scenarios:
1. you dont have a routable name; It is ok that you can never spread
information (publish data)?
2. you have a routable name; how long you have to wait til routing
update finishes in order to publish data globally in a new location?
I believe pendingData is a relatively simple solution.
On Fri, Feb 20, 2015 at 12:51 PM, Mark Stapp <mjs at cisco.com> wrote:
> On 2/19/15 4:08 PM, Wentao Shang wrote:
>> Hi Mark,
>> Yes, I think the "CDN-style" model could be a starting point for solving
>> a class of mobility problems. A few things that are still unclear to me
>> 1/ Can we use this rendezvous model for real-time communications like
>> video/audio conferencing? Not sure how the indirection will affect the
> there are plenty of familiar services - skype, webex, gotomeeting - that use
> a managed, distributed cdn service for rendezvous, at least. that allows
> clients with topological names (at home, at work, on mobile network) to
> rendezvous with one another. the clients can then communicate directly,
> having learned the necessary names from the rendezvous service. if one
> client is truly mobile (not likely at work, perhaps, but possible while
> transitioning from one network to another) that client can update the
> rendezvous service and it's possible the communication can recover without
> significant interruption.
>> 2/ If we plan to use Interest-Interest communication, how do we handle
>> the case when the producer doesn't have a routable prefix (or doesn't
>> know he has)? The Kite approach (i.e., using PIT to do reverse path
>> forwarding) is a significant change to the architecture and I still
>> don't understand the implication of this change yet.
> I don't quite follow that remark about not having a routable name. if you
> can't be reached, if you don't have a routable name, then ... you can't be
> reached? I guess I expect that when an ndn host arrives on a network, it
> learns some routable name prefix - just as an IP host learns one or more
> addresses along with other necessary IP info from DHCP. that will be a
> topological name, controlled by the administrator of the network. I expect
> that'd be the same whether you're getting 'native' ndn service (at home, at
> work), or using a tunnel to some ndn provider (as folks use v6 tunnel
> brokers like HE when native v6 or dual-stack service is not available).
> -- Mark
>> On Thu Feb 19 2015 at 7:16:07 AM Mark Stapp <mjs at cisco.com
>> <mailto:mjs at cisco.com>> wrote:
>> Hi Wentao,
>> On 2/15/15 2:18 PM, Wentao Shang wrote:
>> > While any solution must be based on the specific application
>> > there are still some general guidelines that you may consider:
>> > 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
>> > location, such as an NDN repo, so that the consumer can fetch
>> data from
>> > the repo instead of talking to the producer directly.
>> hmm - that sure sounds like a CDN design, the kind that we use all the
>> time - facebook, flickr, gmail. is that the kind of thing you had in
>> mind? if so, as you know I agree, and I think there should be more
>> on mechanisms that support this design.
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
More information about the Ndn-interest