<!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>Despite the possibility of delay in repo-based solution, is it cost effective? I mean, in a CDN-like solution we focus on caching(for distributing contents), which in this scenario(real-time communication) is not that usable because we are not going to use the produced data(from the vice-chat application) again, right?<BR>
<BR>
On 20 Feb 2015 00:39, "Wentao Shang" <wentaoshang@gmail.com> wrote:<BR>
><BR>
> Hi Mark,<BR>
><BR>
> 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 include:<BR>
><BR>
> 1/ Can we use this rendezvous model for real-time communications like video/audio conferencing? Not sure how the indirection will affect the delays.<BR>
><BR>
> 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.<BR>
><BR>
> Wentao<BR>
><BR>
><BR>
> On Thu Feb 19 2015 at 7:16:07 AM Mark Stapp <mjs@cisco.com> wrote:<BR>
>><BR>
>> Hi Wentao,<BR>
>><BR>
>> On 2/15/15 2:18 PM, Wentao Shang wrote:<BR>
>> > While any solution must be based on the specific application scenario,<BR>
>> > there are still some general guidelines that you may consider:<BR>
>> ><BR>
>><BR>
>> [...]<BR>
>><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 repo instead of talking to the producer directly.<BR>
>> ><BR>
>><BR>
>> hmm - that sure sounds like a CDN design, the kind that we use all the<BR>
>> time - facebook, flickr, gmail. is that the kind of thing you had in<BR>
>> mind? if so, as you know I agree, and I think there should be more focus<BR>
>> on mechanisms that support this design.<BR>
>><BR>
>> Thanks,<BR>
>> Mark<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>
> 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>
></FONT>
</P>
</BODY>
</HTML>