<div dir="ltr"><br><br><div class="gmail_quote">On Fri Feb 20 2015 at 2:17:27 AM Muhammad Hosain Abdollahi Sabet <<a href="mailto:M.AbdollahiSabet@mail.sbu.ac.ir">M.AbdollahiSabet@mail.sbu.ac.ir</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>






<div>


<p><font>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?</font></p></div></blockquote><div>The data can be reused in the scenario of multi-party conferencing or when the application needs auto-archiving and/or playback.</div><div><br></div><div>Wentao</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p><font><br>
​​<br>
On 20 Feb 2015 00:39, "Wentao Shang" <<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>> 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 <<a href="mailto:mjs@cisco.com" target="_blank">mjs@cisco.com</a>> 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>
>> <a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br>
>> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
><br>
><br>
> _______________________________________________<br>
> Ndn-interest mailing list<br>
> <a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br>
> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
></font></p></div></blockquote></div></div>