Subject: Re: [icnrg] Benefit of information centric network (ICN) compared to DTN in wireless communication

From: Paulo Mendes <[email-masked]>
Date: Wed, 14 Nov 2012 15:10:27 +0000

Hello

Just saw this email now (yes, I've a email delay tolerant system :) ), and I think that Ignacio is making an important point.. The DTN and ICN research/work started from different perspectives. From the DTN side, we have a standardization work aiming to devise one architecture. From the ICN side we started by having different projects that follow the same generic ICN principles, but any of which we can be stamped as THE ICN reference. So, from an architectural point of view, this discussion is useless, and should be resumed after the ICNRG come up with some standard track proposal.

From a general perspective, we can only try to analyze which paradigm brings more benefits to the end user (from whom does not matter how the engine works). Lets look at two aspects/requirements to start with:

a) Access to information: considering that the highest percentage of Internet traffic is data oriented (r.g. google, facebook, amazon, ebay, ...) and not point-to-point (e.g. VoIP) a pull model like ICN in which the user "just" need to ask the network to provide the requested data seems more beneficial.

b) Operation in challenge scenarios: if we look at the edges of the Internet core (beyond the cellular, wireless, etc end points) we need a architecture capable to support data exchange even when there is no end-to-end path between any pair of nodes, or when end-to-end paths have ver long delays. The DTN arch was created for this scenario, based on persistent storage and the creation of a chain of TCP links. But since persistent storage is also a key element of ICN and since ICN is agnostic of communication links, I would say that ICN is a concept that can be applied to the same scenarios that DTN was initial designed to.

It is with this goal in mind (bring ICN concept to the DTN world) that we at SITILabs (http://siti.ulusofona.pt) are working on an modular architecture called ICON (Information-centric Opportunistic Networking) that started from the basic CCN concepts and includes a social-aware opportunistic routing protocol. For now the major goal is more software engineer oriented: we created an easy to install and use platform that runs in any personal device (windows, android, iphone, linux) and is being adjusted to embedded devices. For more info check: http://siti.ulusofona.pt/index.php/teechnology/182-icon-dtn-amazon-project

So, IMO it is at all possible for a future ICNRG architecture proposal to be applied to any DTN scenario. It will all depend upon the direction/priorities that the ICNRG will set. Then we just need to show that such arch is also useful to set up point-to-point communications (see initial conceptual profs, as the 2009 VoCCN paper from Van Jacabson et al) :-).

Cheers
Paulo

On Sep 17, 2012, at 7:42 PM, <[email-masked]> <[email-masked]> wrote:

> Having worked on "all-of-the-above" I can say that the differences are not
> big.  I currently advise Preston and Rajesh on CBMEN (Content-Based Mobile
> Edge Networks) for DARPA, and I Worked on adding ICN capabilities to
> SPINDLE.
> 
> The differences between the two "architectures" are becoming
> smaller/fewer.    Kevin's slides from Dagstuhl summarize what the group
> talked about in terms of ICN/DTN.
> 
> One thing to note is that to some degree, both ICN and DTN refer to a
> group of projects or general architectures.  From my point of view, the
> DTN community is relatively unified in the sense that it follows a few
> standards/conventions  (RFC 5050?).  From the ICN perspective we have a
> situation where we're not unified at all. The different projects have made
> different tradeoffs.
> 
> Due to this it is probably better to compare DTN to NetInf, PURSUIT, CCN,
> etc.   Depending on your application you might find that more than one has
> the features that you want.  Potentially you might want to choose one due
> to code maturity/production-level  or  due to future expandability.
> 
> I would suggest that you think of the problem you're trying to solve,
> figure out the must-have and nice-to-have features and see which
> architecture/project works best for you based on:
> 
> * what is currently implement in the code (alpha, beta, production)
> * what is the planned features in the short, medium and long-term
> * what is technically possible with the architecture   (that might never
> get done unless you do it yourself)
> 
> 
> After all, you can do everything over IP given enough services on top.
> 
> Nacho
> 
> 
> 
> 
> 
> -- 
> Ignacio Solis
> Networking Area Manager
> Palo Alto Research Center
> +1(650)812-4458
> 
> 
> 
> 
> 
> 
> On 9/14/12 4:59 PM, "Elwyn Davies" <[email-masked]> wrote:
> 
> 
>> 
>> The US Army was (and as far as I know still are) very interested in DTN
>> as a way to improve throughput in what is essentially a vehicular ad-hoc
>> network.  Some years ago there were trials of the BBN-lead DARPA DTN
>> projects (SPINDLE) involving vehicles driving
>> round a track and comparing the performance of DTN and basic TCP. At one
>> point in time there was a comprehensive presentation (by Preston Marshall
>> if my memory is correct) of the results of this trial available on the
>> web, but it seems to have been withdrawn
>> - I failed to keep a copy of it and attempts to get it again have drawn
>> a blank.  There is some discussion of this work in the state of the art
>> document that I wrote for the N4C project about three years ago.  This
>> can be downloaded from
>> http://www.n4c.eu/Download/n4c-wp2-012-state-of-the-art-101.pdf.
>> 
>> A Google search for something like 'us army dtn tcp vehicles' throws up a
>> whole raft of interesting references including mentions of the CONDOR
>> project and other stuff that is going on in vehicular ad hoc networking.
>> There is brief mention of CCN related topics.
>> An interesting report of more recent and complex trials can be found in
>> http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/41752/1/JPL%20Pub%20D-65
>> 838.pdf
>> 
>> There is also an interestng perspective on combining ICN and DTN in this
>> talk...
>> http://rajesh-krishnan.com/talks/rkrishnan-coin-neu07.pdf
>> 
>> Regards,
>> Elwyn
>> 
>> 
>> On 14/09/12 15:02, Ngoc Thanh Dinh wrote:
>> 
>> Thank you very much!
>> That is one reason we want to implement ICN in ad-hoc vehicular network.
>> but we have to demonstrate it, before implementation, we have to make a
>> clear benefits.
>> 
>> In high density, high mobility case, and constraint information (delay
>> time and location), do you think that DTN will give a not good
>> performance? (even increase delay compared to other). and ICN may be
>> better because ICN could support automatic ifnormation
>> searching and distributtion (matching interest and data) ?
>> 
>> 
>> We should make a clear benefit to select which one is more suitable for
>> this scenario.
>> Hope to have your discussion and thank you very much!
>> 
>> 2012/9/14 Ivancic, William D. (GRC-RHN0)
>> <[email-masked]>
>> 
>> DTN, as is, only temporarily caches a bundle until it passes it on (in
>> general, but is implementation  and routing specific).  DTN, as is, does
>> not know what is inside the bundle (although, one could come up with
>> something
>> special to enable this).   ICN ensures that the information is cached at
>> the appropriate places and is available for ICN users to obtain. DTN
>> could be used to get the information to the ICN cache (complementary).
>> But, for DTN to be used as ICN, you have to
>> basically design ICN into DTN. DTN, as is, is complicated enough.
>> 
>> - Will
>> 
>> On Sep 14, 2012, at 8:52 AM, Ngoc Thanh Dinh wrote:
>> 
>> 
>> Yes. DTN could be a scenario which could be covered in ICN.
>> I am analyzing on the case of exchanging information among vehicles in
>> the ad-hoc vehicular network scenarios without infrastructure.
>> in case of long delay or disruption (main purpose of DTN), i think the
>> same performance could be implement based on information object and
>> caching of ICN.
>> but in the high density and high mobility case of vehicle, do you think
>> DTN will achieve a lower performance? (e.g. higher delay)
>> 
>> I want to listen your discussion about the points that
>> 
>> class 1: for information service which delayed or lost information does
>> not compromise safety or render the application useless (e.g. weather
>> reports,...) --> DTN capabilities can improve the quality in this case by
>> increasing the message delivery and reducing
>> delays in challenging scenarios.
>> And with ICN, we could also achieve this improvement, even more, based on
>> naming object, not destination host.
>> 
>> class 2: for delayed information may compromise safety, application may
>> require realtime communication --> DTN may not improve the quality of
>> this case.
>> But ICN may make an improvement? (based on information object caching)
>> 
>> Listen to your discussion and thank you very much!!!
>> 
>> 
>> 
>> 
>> 2012/9/14 Ivancic, William D. (GRC-RHN0)
>> <[email-masked]>
>> 
>> DTN and ICN may be complementary.  DTN is not ICN.  DTN is to move
>> information over, in some cases, long propagation delays, and in other
>> cases, systems that are normally disconnected, or both.  There is a
>> thought that, because
>> DTNs have to store content, that same storage could be used by the ICN.
>> However, trying to combine the two, IMHO, will complicate matters for
>> both ICN and DTN and hold back both.  But, that is just my opinion.
>> 
>> 
>> Regardless, I don't think you can compare "which one is better in the ad
>> hoc vehicular environment" because they are designed to do two different
>> things.  Perhaps the better question is "Do I need DTN for ad hoc
>> vehicular networks or will ICN suffice?"
>> What is your concept of operations?  Are you operating where 4G
>> connectivity is available?  Do i have a multi-hop DTN?  If not, DTN is
>> likely to buy you nothing.
>> 
>> - Will
>> 
>> 
>> 
>> On Sep 14, 2012, at 8:17 AM, Ngoc Thanh Dinh wrote:
>> 
>> 
>> Thank you very much!
>> Yes. I think so, ICN could cover many scenarios of DTN.
>> But to compare them in one experiment to show which one is better in the
>> ad-hocvehicular environment, it seems many consideration.
>> Do you have any opinion to compare performance of two approaches? on
>> delay, network resource consumption, overhead or other one?
>> I want to show that ICN is better one in the vehicular environment. but
>> in the partition case or in high density case, it still seems confusing
>> to compare.
>> Hope to have your discussion!!!
>> 
>> thank you very much!
>> 
>> 2012/9/14 Dirk Trossen <[email-masked]>
>> 
>> Let me bring back DY's email from a few days ago, pointing at Kevin
>> Fall's presentation (I included the link again, DY also sent the
>> presentation itself):
>> 
>>  http://fif.kr/gfi-summit/11/program.htm
>> 
>> It shows that there's more to ICN and DTN commonalities than one might
>> think originally
>> 
>> Dirk
>> 
>> On 14 Sep 2012, at 12:42, Pedro Martínez Juliá wrote:
>> 
>>> 14/09/12 08:07, Ngoc Thanh Dinh:
>>>> Dear Every one,
>>>> 
>>>> We are discussing about the benefit of ICN and DTN in global future
>>>> internet conference these days.
>>>> I am researching in ICN and DTN in vehicular network. There are some
>>>> papers
>>>> in both topics for vehicular network,
>>>> both of them support naming, caching, store-and-forward,...while DTN
>>>> has a
>>>> longer history than ICN
>>>> Could you give me your opinions about what is benefit of ICN compared
>>>> to
>>>> DTN?
>>>> Did anyone make a comparison between ICN and DTN?
>>>> 
>>> 
>>> Conceptually, they have very different objectives. However, ICN can
>>> cover some (or even many) DTN use cases. The main difference is that ICN
>>> manages named or uniquely identified information while DTN is
>>> concentrated in the communication. For example, and
>> correct me if I'm wrong, ICN permits to deliver the same information
>> piece to different clients requesting it without involving the
>> information source but in DTN is the sender who decides the destination
>> of a message.
>>> 
>>>> Thank you very much!
>>>> 
>>> 
>>> Regards,
>>> Pedro
>>> 
>>> --
>>> Pedro Martinez-Julia
>>> Department of Communication and Information Engineering
>>> Faculty of Computer Science
>>> University of Murcia
>>> Email: [email-masked]
>>> ---------------------------------------------------------
>>> *** Entia non sunt multiplicanda praeter necessitatem ***
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Dinh Ngoc Thanh | PhD candidate
>> Soongsil university - Seoul Korea
>> M: (+82) 010 4197 1879
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ******************************
>> William D. Ivancic
>> Phone 216-433-3494
>> Fax 216-433-8705
>> Networking Lab 216-433-2620
>> Mobile 440-503-4892
>> http://roland.grc.nasa.gov/~ivancic
>> <http://roland.grc.nasa.gov/%7Eivancic>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Dinh Ngoc Thanh | PhD candidate
>> Soongsil university - Seoul Korea
>> M: (+82) 010 4197 1879
>> 
>> 
>> 
>> 
>> 
>> 
>> ******************************
>> William D. Ivancic
>> Phone 216-433-3494
>> Fax 216-433-8705
>> Networking Lab 216-433-2620
>> Mobile 440-503-4892
>> http://roland.grc.nasa.gov/~ivancic
>> <http://roland.grc.nasa.gov/%7Eivancic>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Dinh Ngoc Thanh | PhD candidate
>> Soongsil university - Seoul Korea
>> M: (+82) 010 4197 1879
>> 
>> 
>> 
>> 
>> _______________________________________________
>> icnrg mailing list
>> [email-masked]://www.irtf.org/mailman/listinfo/icnrg
>> 
>> 
> 
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

-------------------------------------------------------------
Paulo Mendes, Ph.D
Scientific Director for Innovation of the Research Unit in Informatics Systems and Technologies (SITI)
Director of the Ph.D program on Informatics - New Media and Pervasive Systems (NEMPS)
Secretary of the ACM SIGCOMM Chapter - Portugal
University Lusofona, Portugal
[email-masked]
http://siti.ulusofona.pt/~pmendes
Tel.: 217 515 500 Fax: 21 757 7006

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 14 Nov 2012 15:18:34 +0000

Hi,

On Nov 14, 2012, at 16:10, Paulo Mendes <[email-masked]> wrote:
> From the DTN side, we have a standardization work aiming to devise one architecture. From the ICN side we started by having different projects that follow the same generic ICN principles, but any of which we can be stamped as THE ICN reference. So, from an architectural point of view, this discussion is useless, and should be resumed after the ICNRG come up with some standard track proposal.

just to clarify: IRTF research groups do not produce standards. The DTNRG isn't, and the ICNRG won't either. It's also not a goal to declare one of the current architecture proposals a "winner".

Lars

---

From: Paulo <[email-masked]>
Date: Wed, 14 Nov 2012 18:46:31 +0000

Hi Lars

it is well known the IRTF does not produce standards. The word "standard" was not used in a proper way in my email. The difference that I want to highlight is that on the DTN side there is a common concensus about a general arch, which we can clearly describe, while that is not a scenario that we can find in the ICN side.
I also didn`t say that ICNRG should declare a winner among the existing proposals (ccn, netinf,...). Not at all. Does are just related work. But if we want to clearly compare DTN with ICN, we need to create a common understanding about the general characteristics of an ICN arch within ICNRG. This may be a very usefull contribution from IRTF (bring or at least try to create consensus). 

Cheers
Paulo
-- 
@N900
----------------------------------
Paulo Mendes
Sientific Director of the Informatic Systems and Tecnology Labs (SITI Labs)
Http://siti.ulusofona.pt 

----- Mensagem original -----
> > From the DTN side, we have a standardization work aiming to devise one
> > architecture. From the ICN side we started by having different
> > projects that follow the same generic ICN principles, but any of which
> > we can be stamped as THE ICN reference. So, from an architectural
> > point of view, this discussion is useless, and should be resumed after
> > the ICNRG come up with some standard track proposal.
> 
> just to clarify: IRTF research groups do not produce standards. The
> DTNRG isn't, and the ICNRG won't either. It's also not a goal to declare
> one of the current architecture proposals a "winner".
> 
> Lars

---

From: <[email-masked]>
Date: Wed, 14 Nov 2012 21:59:55 +0000

Didn't the dtnrg declare the bundle protocol proposal the winner by fiat in its charter?

Bad start to a research group, but there you go. Not so much a goal, as an own goal.

If icnrg did the same thing, the rewards of illusory progress could be received in the short term.

Lloyd Wood
http://sat-net.com/L.Wood/

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Eggert, Lars [[email-masked]]
Sent: 14 November 2012 15:18
To: Paulo Mendes
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Subject: Re: [icnrg] Benefit of information centric network (ICN)       compared        to DTN in wireless communication

Hi,

Lars

---

From: Paulo <[email-masked]>
Date: Thu, 15 Nov 2012 08:04:24 +0000

Again... I think that I´m not been clear... I didn´t say that icnrg has to "declare" a winner as a starting point. What I said was that as in any research process, it would be good to try to reach to a consensus about the generic characteristics of an ICN arch.. It main happen that, as in any reach process, we end up not being able to do so.

That will be a good contribution: to come up with a reference model, to support large scale deployment of ICN, since money will only be invested with some ensurance of large deployment.

If this effort is not a goal, why should people pay attention to ICNRG? Just as an informative effort? To list deployment scenarios, surveying soa, and identifying research challenges? Of what? Research challenges of CCN and Netinf may be veryh different due to their different characteristics (e.g. Naming system). And this was for sure already did by the peoplo that devised such approaches (e.g. NDN and SAIL projects).

As Einstein would say: if I knew that would be possible to create a ICN reference architecture, that would not be research :)

But if the creation of a ref arch is not a ICNRG goal, people expect IRTF to tell them how to interoperate all the existing and future ICN flavours.

Cheers
Paulo 

----- Mensagem original -----
> From: [email-masked] [[email-masked]] On Behalf Of
> Eggert, Lars [[email-masked]] Sent: 14 November 2012 15:18
> To: Paulo Mendes
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>;
> <[email-masked]> Subject: Re: [icnrg] Benefit of information
> centric network (ICN)             compared               to DTN in wireless
> communication
> 
> Hi,
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Nov 2012 09:32:33 +0000

(trimmed cc list)

> But if the creation of a ref arch is not a ICNRG goal, people expect IRTF to tell them how to interoperate all the existing and future ICN flavours.

People really expect that? They're liable to be disappointed;-)

I don't think interop between any pair of ICN approaches is
that big a deal myself at the protocol level. If however, we
had a way in which the different approaches (and non ICN things
like maybe cdni) could use the same names for objects then I
think that would enable some good things both for research
and if there were any real deployments. That's why we're trying
to propose that ni URI thing - I'd love to know if it might
really be usable for other ICN approaches, or if not, why not.

Cheers,
S.

---

From: Paulo Mendes <[email-masked]>
Date: Fri, 16 Nov 2012 15:59:09 +0000

Hi Stephen

See my comments inline.

> People really expect that? They're liable to be disappointed;-)

Since there are already a considerable arch proposals for ICN, currently researchers have to decide which one to use based on its own evaluation, facing the problem of creating communication islands. There are only two way to avoid this situation: i) create a way to make icn proposals interoperable; ii) hope that one of the existing proposals will be elected as a de facto standard.

If option ii) is the way to go, which is not impossible if we see for instance all the community growing around CCN, the contributions of ICNRG will be just informative: survey; research statement; scenarios. This is a type of work that most previous projects on ICN, such as most EU projects may already have done, since it is normal that a 3 years project with a large consortium will be to create scenarios, do a survey and set research statement. 

If option i) is the way to go, then the output could be very useful: allow the research community to use any existing (solid) proposal, since all of them will interoperate.

What I was proposing is something similar to what is being discussed in the DTNRG in relation to routing: after the creation of a large number of routing proposal for DTNs, with two of them being specified i DTNRG (ProPhet and dLife) it is being discussed the creation of a routing reference model to identify a common routing framework, since most proposal have similar grounds.  Maybe it will be impossible to create a reference model for ICNs. Maybe it will not be so impossible to do so for specific core functionally such as naming and routing. But we will only know the answer to this is we do some research :-).

When I proposed, before the Atlanta meeting to change the survey draft for a concept draft, the idea was exactly to research the possibility to create a reference model by analyzing the conceptual similarities between the existing proposal.. The conclusion of that work would give ICNRG information to decide about what to do after the initial three goals: survey, research challenges, scenarios. 

> that big a deal myself at the protocol level.

Good. So it will not be difficult to specify it and make it available to the research community :). This will allow any research to save time deciding about the deployment issues associated to a decision about one of the existing ICN proposals.

> If however, we

This is one of the core functionality that I mentioned above: naming... Then we have others, such as routing (pure name-based routing; (late) name resolution based routing; opportunistic for disruptive scenarios, etc)

Cheers
Paulo

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Fri, 16 Nov 2012 16:57:52 +0000

Hi Paulo,

<snip>

|Since there are already a considerable arch proposals for ICN,
|currently researchers have to decide which one to use

<snip>

I do not agree that researchers are waiting from ICNRG to tell them which arch proposal to use.

Best Regards,

Kostas

---

From: Paulo Mendes <[email-masked]>
Date: Fri, 16 Nov 2012 20:57:55 +0000

Kostas 

With your statement that researchers have to pick up one of the existing solutions to develop ICN work, it seems that you're assuming that existing proposals provide already a good support (starting point) to identified problems/challenges... 

More over, since these ICN proposals resulted from large projects that for sure already did a good survey of the state of the art, a description of scenarios and use cases and have (as a result of their work) for sure identified research challanges, it seems that the current icnrg goals can be accomplished with a sum up report, pointing out to the work done by those projects. Is this what you are saying?

If so, what would then be the propose of ICNRG?

Paulo