<!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>Hi everyone,<BR>
Sorry if I'm to bringing up this cool conversation without any new shining thing. But I'm not sure where else I should ask this, and I didn't want to start a new topic which is not necessarily technical. Anyway, there was a question about mobility issues in NDNComm 2014(<A HREF="http://www.caida.org/workshops/ndn/1409/">http://www.caida.org/workshops/ndn/1409/</A>) which is answered by kc that there will be a meeting which six people are going to talk about mobility realm. Well, I couldn't find any agenda, report or something about such a meeting. Has it been held out yet? If yes, where can I find something about the talks and ideas that were produced. I'm asking the question here because there are people in this topic that I believe they were present in NDNComm 2014 and can help me with this. I really appreciate it.<BR>
<BR>
Thanks,<BR>
Sabet<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Tai-Lin Chu [<A HREF="mailto:tailinchu@gmail.com">mailto:tailinchu@gmail.com</A>]<BR>
Sent: Sat 2/21/2015 3:12 AM<BR>
Cc: Muhammad Hosain Abdollahi Sabet; ndn-interest@lists.cs.ucla.edu<BR>
Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions<BR>
<BR>
> Well, I'm just looking from the perspective of mobility problem. Is there any problem or prevention if pendingData not be empty?<BR>
<BR>
In case of pendingData, mobile caller has something to send but static<BR>
callee doesn't. The other direction is supported by ndn already.<BR>
<BR>
> If so, it seems there's a need to modify packet structure and add optional pendingData flag field(something like Kite).<BR>
<BR>
I prefer not to add additional field, but implement this with a new<BR>
ContentType: "pendingData" (0x3). (IMHO, we should try to remove field<BR>
by making packet format flexible.)<BR>
<BR>
> What if the producer moves after sending the pendingData?<BR>
<BR>
In my pdf, pendingData's mechanism is just like regular interest in<BR>
pending interest table. So unlike Kite, no additional table is needed.<BR>
<BR>
After the producer moves, the pendingData cannot get satisfied. The<BR>
producer can efficiently start over.<BR>
<BR>
<BR>
On Fri, Feb 20, 2015 at 9:50 AM, Wentao Shang <wentaoshang@gmail.com> wrote:<BR>
><BR>
><BR>
> On Fri Feb 20 2015 at 2:17:27 AM Muhammad Hosain Abdollahi Sabet<BR>
> <M.AbdollahiSabet@mail.sbu.ac.ir> wrote:<BR>
>><BR>
>> Despite the possibility of delay in repo-based solution, is it cost<BR>
>> effective? I mean, in a CDN-like solution we focus on caching(for<BR>
>> distributing contents), which in this scenario(real-time communication) is<BR>
>> not that usable because we are not going to use the produced data(from the<BR>
>> vice-chat application) again, right?<BR>
><BR>
> The data can be reused in the scenario of multi-party conferencing or when<BR>
> the application needs auto-archiving and/or playback.<BR>
><BR>
> Wentao<BR>
><BR>
>><BR>
>><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<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>
>> > 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 know<BR>
>> > he has)? The Kite approach (i.e., using PIT to do reverse path forwarding)<BR>
>> > is a significant change to the architecture and I still don't understand the<BR>
>> > 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<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 point<BR>
>> >> > 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 data<BR>
>> >> > 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<BR>
>> >> 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>
>> ><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>
><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>