<div dir="ltr"><br><br><div class="gmail_quote">On Fri Feb 20 2015 at 12:51:41 PM Mark Stapp <<a href="mailto:mjs@cisco.com">mjs@cisco.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 2/19/15 4:08 PM, Wentao Shang wrote:<br>
> Hi Mark,<br>
><br>
> Yes, I think the "CDN-style" model could be a starting point for solving<br>
> a class of mobility problems. A few things that are still unclear to me<br>
> include:<br>
><br>
> 1/ Can we use this rendezvous model for real-time communications like<br>
> video/audio conferencing? Not sure how the indirection will affect the<br>
> delays.<br>
><br>
<br>
there are plenty of familiar services - skype, webex, gotomeeting - that<br>
use a managed, distributed cdn service for rendezvous, at least. that<br>
allows clients with topological names (at home, at work, on mobile<br>
network) to rendezvous with one another. the clients can then<br>
communicate directly, having learned the necessary names from the<br>
rendezvous service. if one client is truly mobile (not likely at work,<br>
perhaps, but possible while transitioning from one network to another)<br>
that client can update the rendezvous service and it's possible the<br>
communication can recover without significant interruption.<br>
<br>
<br>
> 2/ If we plan to use Interest-Interest communication, how do we handle<br>
> the case when the producer doesn't have a routable prefix (or doesn't<br>
> know he has)? The Kite approach (i.e., using PIT to do reverse path<br>
> forwarding) is a significant change to the architecture and I still<br>
> don't understand the implication of this change yet.<br>
><br>
<br>
I don't quite follow that remark about not having a routable name. if<br>
you can't be reached, if you don't have a routable name, then ... you<br>
can't be reached? I guess I expect that when an ndn host arrives on a<br>
network, it learns some routable name prefix - just as an IP host learns<br>
one or more addresses along with other necessary IP info from DHCP.</blockquote><div><br></div><div>This is true. But what if the producer wants to publish data under some provider-independent identity while he is moving across networks? The mobile device may be reachable via some local prefix but the data may be under a different prefix. E.g., I always want to publish data under /ucla/cs/wentao prefix while I'm moving from my office to my TWC homenet, or even back to China...</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"> that<br>
will be a topological name, controlled by the administrator of the<br>
network. I expect that'd be the same whether you're getting 'native' ndn<br>
service (at home, at work), or using a tunnel to some ndn provider (as<br>
folks use v6 tunnel brokers like HE when native v6 or dual-stack service<br>
is not available).<br>
<br>
-- Mark<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><br>
> <mailto:<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<br>
>     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<br>
>     point as<br>
>      > indirection: you can have your producer publish its data to a<br>
>     well-known<br>
>      > location, such as an NDN repo, so that the consumer can fetch<br>
>     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>
>     ______________________________<u></u>___________________<br>
>     Ndn-interest mailing list<br>
>     <a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a> <mailto:<a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.<u></u>ucla.edu</a>><br>
>     <a href="http://www.lists.cs.ucla.edu/__mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/_<u></u>_mailman/listinfo/ndn-interest</a><br>
>     <<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/ndn-interest</a>><br>
><br>
</blockquote></div></div>