[Ndn-interest] NDN-friendly Mobility solutions

[Muhammad Hosain Abdollahi Sabet]

Hi everyone,
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(http://www.caida.org/workshops/ndn/1409/) 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.

Thanks,
Sabet


-----Original Message-----
From: Tai-Lin Chu [mailto:tailinchu at gmail.com]
Sent: Sat 2/21/2015 3:12 AM
Cc: Muhammad Hosain Abdollahi Sabet; ndn-interest at lists.cs.ucla.edu
Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions
 
> Well, I'm just looking from the perspective of mobility problem. Is there any problem or prevention if pendingData not be empty?

In case of pendingData, mobile caller has something to send but static
callee doesn't. The other direction is supported by ndn already.

> If so, it seems there's a need to modify packet structure and add optional pendingData flag field(something like Kite).

I prefer not to add additional field, but implement this with a new
ContentType: "pendingData" (0x3). (IMHO, we should try to remove field
by making packet format flexible.)

> What if the producer moves after sending the pendingData?

In my pdf, pendingData's mechanism is just like regular interest in
pending interest table. So unlike Kite, no additional table is needed.

After the producer moves, the pendingData cannot get satisfied. The
producer can efficiently start over.


On Fri, Feb 20, 2015 at 9:50 AM, Wentao Shang <wentaoshang at gmail.com> wrote:
>
>
> On Fri Feb 20 2015 at 2:17:27 AM Muhammad Hosain Abdollahi Sabet
> <M.AbdollahiSabet at mail.sbu.ac.ir> wrote:
>>
>> 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?
>
> The data can be reused in the scenario of multi-party conferencing or when
> the application needs auto-archiving and/or playback.
>
> Wentao
>
>>
>>
>>
>> On 20 Feb 2015 00:39, "Wentao Shang" <wentaoshang at gmail.com> 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
>> > include:
>> >
>> > 1/ Can we use this rendezvous model for real-time communications like
>> > video/audio conferencing? Not sure how the indirection will affect the
>> > delays.
>> >
>> > 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.
>> >
>> > Wentao
>> >
>> >
>> > On Thu Feb 19 2015 at 7:16:07 AM Mark Stapp <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
>> >> > scenario,
>> >> > 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
>> >> > well-known
>> >> > 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
>> >> focus
>> >> on mechanisms that support this design.
>> >>
>> >> Thanks,
>> >> Mark
>> >>
>> >> _______________________________________________
>> >> Ndn-interest mailing list
>> >> Ndn-interest at lists.cs.ucla.edu
>> >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>> >
>> >
>> > _______________________________________________
>> > Ndn-interest mailing list
>> > Ndn-interest at lists.cs.ucla.edu
>> > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>> >
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150518/a20c4a5c/attachment.html>