Subject: [Icn-interest] Icn-interest Digest, Vol 11, Issue 6
From: Dirk.Kutscher at neclab.eu (Dirk Kutscher)
Date: Wed, 11 Jan 2012 08:34:50 +0000

Hi Beichuan,

Don't worry, technical discussions are more welcome.

Thanks,
Dirk

From: icn-interest-bounces at listserv.netlab.nec.de [mailto:icn-interest-bounces at listserv.netlab.nec.de] On Behalf Of Beichuan Zhang
Date: Tue, 10 Jan 2012 21:52:00 +0100
To: icn-interest at listserv.netlab.nec.de
Subject: Re: [Icn-interest] Icn-interest Digest, Vol 11, Issue 6

Not sure if this list is an appropriate place for technical discussions of a specific ICN design, but my comments inline anyway.

Date: Tue, 10 Jan 2012 16:07:10 +0800
From: xiaoyan Hu <xhbreezehu at gmail.com<mailto:xhbreezehu at gmail.com>>
Subject: [Icn-interest] questions about NDN data signature and routing
        adaptability in network dynamic
To: icn-interest at listserv.netlab.nec.de<mailto:icn-interest at listserv.netlab.nec.de>

Dear all,

I have two questions for NDN.
First, one question about the verification of data signature in NDN if the
key pair of some publisher is renewed: for example, in NDN, a publisher use
some private-public key pair for data signature in a period; then the key
pair is deprecated later. My question is that whether other Internet users
can locate the old public key. If not, how can the old content (content
signed by the old private key) be validated? And I think it is infeasible
to sign each piece of old content with the new private key. But if yes, I
think the old key pair would be abused by malicious attackers (if I am
wrong, please correct me). Do you guys have any thought about this?

The publisher can use the new key to sign a content object that binds the new key and the old key.

From: bzhang at arizona.edu (Beichuan Zhang)
Date: Tue, 10 Jan 2012 13:51:54 -0700
Subject: [Icn-interest] Icn-interest Digest, Vol 11, Issue 6
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Not sure if this list is an appropriate place for technical discussions of a specific ICN design, but my comments inline anyway.

> Date: Tue, 10 Jan 2012 16:07:10 +0800
> From: xiaoyan Hu <xhbreezehu at gmail.com>
> Subject: [Icn-interest] questions about NDN data signature and routing
> 	adaptability in network dynamic
> To: icn-interest at listserv.netlab.nec.de
> 
> Dear all,
> 
> I have two questions for NDN.
> First, one question about the verification of data signature in NDN if the
> key pair of some publisher is renewed: for example, in NDN, a publisher use
> some private-public key pair for data signature in a period; then the key
> pair is deprecated later. My question is that whether other Internet users
> can locate the old public key. If not, how can the old content (content
> signed by the old private key) be validated? And I think it is infeasible
> to sign each piece of old content with the new private key. But if yes, I
> think the old key pair would be abused by malicious attackers (if I am
> wrong, please correct me). Do you guys have any thought about this?

The publisher can use the new key to sign a content object that binds the new key and the old key.

From: xhbreezehu at gmail.com (xiaoyan Hu)
Date: Tue, 10 Jan 2012 16:07:10 +0800
Subject: [Icn-interest] questions about NDN data signature and routing adaptability in network dynamic
Message-ID: <[email-masked]>

Dear all,

I have two questions for NDN.
First, one question about the verification of data signature in NDN if the
key pair of some publisher is renewed: for example, in NDN, a publisher use
some private-public key pair for data signature in a period; then the key
pair is deprecated later. My question is that whether other Internet users
can locate the old public key. If not, how can the old content (content
signed by the old private key) be validated? And I think it is infeasible
to sign each piece of old content with the new private key. But if yes, I
think the old key pair would be abused by malicious attackers (if I am
wrong, please correct me). Do you guys have any thought about this?

Second, I think NDN routing is not as good as IP in adapting to network
dynamics. Since the Interest and Data packet follow the same path, then if
some node on the path fails (or if the related PIT entry in a node on the
path is lost) when the data comes back to content requester(s) , the data
packet will not be forwarded and the requester(s) have to solicit it again.
While in IP networking, the routing may adapt to the node failure fast and
redirect the data packet to the requester. What do you think?

Thanks,
Xiaoyan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120110/7416ecd8/attachment.htm>

From: giovanna.carofiglio at alcatel-lucent.com (CAROFIGLIO, GIOVANNA (GIOVANNA))
Date: Fri, 6 Jan 2012 21:48:11 +0100
Subject: [Icn-interest] RE :  Universal caching unnecessary?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CA+y5TP3sKqFdHGPOVc0p3icYK=aUJaw6VRYNZQNM2297=[email-masked]>, <[email-masked]>
Message-ID: <[email-masked]>

Very interesting topic we are investigating in the ICN/CCN scope and which has shown broader potential for the application to current content delivery solutions.

Universal caching is for sure one of the aspects where ICN shows at this stage the largest benefits, but is not a prerogative of ICN architectures only. CDN are evolving in terms of distributing more  caching caching capabilities into the network and the publishing model has space to evolve accordingly. 

The use of transparent caching in addition goes in the same direction as ICN if adding this new dimension to content delivery, moving content in time (e.g. via opportunistic in path caching) and not only  in space as done by traditional content delivery. 

To exploit this new dimension,  a new communication model has to follow and this is where an ICN design can make the difference, once the limitations of a CDN evolution over-the-top at application layer will be more than today visible and will prevent network architecture evolution in this sense.

Giovanna.
________________________________________
De : icn-interest-bounces at listserv.netlab.nec.de [icn-interest-bounces at listserv.netlab.nec.de] de la part de Dirk Trossen [dirk.trossen at cl.cam.ac.uk]
Date d'envoi : vendredi 6 janvier 2012 18:22
? : icn-interest at listserv.netlab.nec.de
Objet : Re: [Icn-interest] Universal caching unnecessary?

Think of the following model of a future 'intelligent road':
You have sensors deployed, e.g., in the road surface for ice warnings, distance sensors, speed sensors, .... Cars are driving along the road, accessing the sensor data as they go, e.g., for ice warnings, distance warnings, accident warnings, navigation re-routing, etc. What are the different service possibilities?
A) each sensor can publish its data at the rate it deems suitable (say temperature every 10 seconds - anything else is often futile). The cars subscribe to the individual ones, according to their service/app. This is close to a flow model where data is sent from the sensor (pub) to the car (sub).
B) Asume that you deploy caches along lamp-posts along the road. Each sensor (pub) publishes its data towards the caches (subs) at relatively low rate. Each car subscribes to the data (directed towards the nearest lamp-post). Your only 'real-time' flow here is the sensor data from the cache to the car (which could rely on simple local wireless broadcast), which you could use an efficient fixed line broadcast medium for the cache distribution.
C) Add other cars to the mix above and it becomes real interesting, also from the incentives perspective.

A)+B)+C) are only examples how to play with a time/space-decoupled model of communication!

Dirk

On 6 Jan 2012, at 16:29, Yaogong Wang wrote:

That's a very interesting point. One possible publishing model could be like a seeder in BitTorrent. Once you delivered a full copy of the content to the network, the publisher may even leave the system. Are there other models you envision? I think this finally comes to the business model of ICN. Anyway, someone (the publishers, the users, the ISPs, etc.) needs to provide the resources to host the contents. It depends on who has the most incentive to do so.

Regards,
Yaogong

On Fri, Jan 6, 2012 at 10:54 AM, Dirk Trossen <dirk.trossen at cl.cam.ac.uk<mailto:dirk.trossen at cl.cam.ac.uk>> wrote:
 By decoupling the content name from the server location and from the authentication, the publishing model of content is fundamentally changed.

Now we're coming to a central point! The decoupling aspect has a fundamental impact on the models to provide services and content, as you rightly point out. Whether or not the operational gains of, e.g., caching are comparable depends on whether the models of services are the same - that's where it gets tricky and often ends in comparing apple and oranges.

-Ashok

On Jan 6, 2012, at 1/6 9:56 AM, Yaogong Wang wrote:

Hi Pedro and Ruidong,

Thanks for sharing your opinions. I understand that ICN is not just improving CDN. But it appears to me that, by doing ICN and making each content self-contained, we basically make in-network caching easier. This would of course make CDN implementation simpler or more natural. But if that's all, I don't think there's enough incentive to overhaul the Internet architecture. I think the real power of ICN is to enable universal caching. But if it turns out that universal caching won't deliver the performance we expect and the current method (CDN which caches contents at strategic points in the Internet) is about the optimal point to balance between cost and benefit, then do we still need to do ICN?

Thanks,
Yaogong

On Thu, Jan 5, 2012 at 8:23 PM, Ruidong Li <lrd at nict.go.jp<mailto:lrd at nict.go.jp>> wrote:
Hi,

Agree with Pedro. The design of ICN has different and much more agressive motivations than CDN.
ICN is a balance between in-network caching storage & indexing cost and traffic overhead & latency over possible future network.

Best Regards,
Ruidong

Pedro Mart?nez Juli? ????????:

Yaogong Wang escribi?:
Hi all,

Hi,

In a recent paper in HotNets 2011 (
http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final11.pdf,
especially Section 4.3), the authors argue that universal/ubiquitous
caching and locating the nearest copy of a requested content provide
marginal performance benefit over existing content distribution mechanisms
like CDN or Web proxies. What do you think about this argument?

From: dirk.trossen at cl.cam.ac.uk (Dirk Trossen)
Date: Fri, 6 Jan 2012 17:22:14 +0000
Subject: [Icn-interest] Universal caching unnecessary?
In-Reply-To: <CA+y5TP3sKqFdHGPOVc0p3icYK=aUJaw6VRYNZQNM2297=[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CA+y5TP3sKqFdHGPOVc0p3icYK=aUJaw6VRYNZQNM2297=[email-masked]>
Message-ID: <[email-masked]>

Think of the following model of a future 'intelligent road':
You have sensors deployed, e.g., in the road surface for ice warnings, distance sensors, speed sensors, .... Cars are driving along the road, accessing the sensor data as they go, e.g., for ice warnings, distance warnings, accident warnings, navigation re-routing, etc. What are the different service possibilities?
A) each sensor can publish its data at the rate it deems suitable (say temperature every 10 seconds - anything else is often futile). The cars subscribe to the individual ones, according to their service/app. This is close to a flow model where data is sent from the sensor (pub) to the car (sub).
B) Asume that you deploy caches along lamp-posts along the road. Each sensor (pub) publishes its data towards the caches (subs) at relatively low rate. Each car subscribes to the data (directed towards the nearest lamp-post). Your only 'real-time' flow here is the sensor data from the cache to the car (which could rely on simple local wireless broadcast), which you could use an efficient fixed line broadcast medium for the cache distribution. 
C) Add other cars to the mix above and it becomes real interesting, also from the incentives perspective. 

A)+B)+C) are only examples how to play with a time/space-decoupled model of communication!

Dirk

On 6 Jan 2012, at 16:29, Yaogong Wang wrote:

> That's a very interesting point. One possible publishing model could be like a seeder in BitTorrent. Once you delivered a full copy of the content to the network, the publisher may even leave the system. Are there other models you envision? I think this finally comes to the business model of ICN. Anyway, someone (the publishers, the users, the ISPs, etc.) needs to provide the resources to host the contents. It depends on who has the most incentive to do so.
> 
> Regards,
> Yaogong
> 
> On Fri, Jan 6, 2012 at 10:54 AM, Dirk Trossen <dirk.trossen at cl.cam.ac.uk> wrote:
>>  By decoupling the content name from the server location and from the authentication, the publishing model of content is fundamentally changed. 
> 
> Now we're coming to a central point! The decoupling aspect has a fundamental impact on the models to provide services and content, as you rightly point out. Whether or not the operational gains of, e.g., caching are comparable depends on whether the models of services are the same - that's where it gets tricky and often ends in comparing apple and oranges.
> 
>> 
>> -Ashok
>> 
>> On Jan 6, 2012, at 1/6 9:56 AM, Yaogong Wang wrote:
>> 
>>> Hi Pedro and Ruidong,
>>> 
>>> Thanks for sharing your opinions. I understand that ICN is not just improving CDN. But it appears to me that, by doing ICN and making each content self-contained, we basically make in-network caching easier. This would of course make CDN implementation simpler or more natural. But if that's all, I don't think there's enough incentive to overhaul the Internet architecture. I think the real power of ICN is to enable universal caching. But if it turns out that universal caching won't deliver the performance we expect and the current method (CDN which caches contents at strategic points in the Internet) is about the optimal point to balance between cost and benefit, then do we still need to do ICN?
>>> 
>>> Thanks,
>>> Yaogong
>>> 
>>> On Thu, Jan 5, 2012 at 8:23 PM, Ruidong Li <lrd at nict.go.jp> wrote:
>>> Hi,
>>> 
>>> Agree with Pedro. The design of ICN has different and much more agressive motivations than CDN.
>>> ICN is a balance between in-network caching storage & indexing cost and traffic overhead & latency over possible future network.
>>> 
>>> Best Regards,
>>> Ruidong
>>> 
>>> 
>>> Pedro Mart?nez Juli? ????????:
>>> 
>>> Yaogong Wang escribi?:
>>> Hi all,
>>> 
>>> 
>>> Hi,
>>> 
>>> In a recent paper in HotNets 2011 (
>>> http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final11.pdf,
>>> especially Section 4.3), the authors argue that universal/ubiquitous
>>> caching and locating the nearest copy of a requested content provide
>>> marginal performance benefit over existing content distribution mechanisms
>>> like CDN or Web proxies. What do you think about this argument?
>>> 
>>> 
>>> From my point of view, the ICN performance benefit is not intended to improve the CDN benefits. I think that CDNs will survive with ICN but they can rely on a simpler delivery protocol that will increase the overall performance by, at least, reducing the steps of a client to reach a content.
>>> 
>>> Just my two cents.
>>> 
>>> Thanks,
>>> Yaogong
>>> 
>>> 
>>> Regards,
>>> Pedro
>>> 
>>> 
>>> 
>>> -- 
>>> -----------------------------------------------------------------------
>>> Ruidong Li (Ph. D.)
>>> Network Architecture Labrotary, Photonic Network Research Institute,
>>> National Institute of Information and Communications Technology (NICT),
>>> 4-2-1 Nukui-kita Machi, Koganei City, Tokyo, 184-8795, Japan
>>> Tel: +81-42-327-5813 Fax: +81-42-327-6680
>>> Email: lrd at nict.go.jp -----------------------------------------------------------------------
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Icn-interest mailing list
>>> Icn-interest at listserv.netlab.nec.de
>>> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest
>>> 
>>> 
>>> 
>>> -- 
>>> ========================
>>> Yaogong Wang, PhD candidate
>>> Department of Computer Science
>>> North Carolina State University
>>> http://www4.ncsu.edu/~ywang15/
>>> ========================
>>> _______________________________________________
>>> Icn-interest mailing list
>>> Icn-interest at listserv.netlab.nec.de
>>> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest
>> 
>> _______________________________________________
>> Icn-interest mailing list
>> Icn-interest at listserv.netlab.nec.de
>> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest
> 
> 
> _______________________________________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest
> 
> 
> 
> 
> -- 
> ========================
> Yaogong Wang, PhD candidate
> Department of Computer Science
> North Carolina State University
> http://www4.ncsu.edu/~ywang15/
> ========================
> _______________________________________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120106/6043e9f3/attachment.htm>

From: dirk.trossen at cl.cam.ac.uk (Dirk Trossen)
Date: Fri, 6 Jan 2012 17:15:06 +0000
Subject: [Icn-interest] Universal caching unnecessary?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Kevin Fall had an interesting presentation at the recent AsiaFI GFI event in Seoul (right after my own presentation) in which he outlined the differences between DTN and NDN. It turned out in discussions with him, that certain models of ICN are closer to DTN than others ;-) 

Best,

Dirk
On 6 Jan 2012, at 16:58, Elwyn Davies wrote:

> On Fri, 2012-01-06 at 15:54 +0000, Dirk Trossen wrote:
>>> By decoupling the content name from the server location and from
>>> the authentication, the publishing model of content is fundamentally
>>> changed. 
>> 
>> 
>> Now we're coming to a central point! The decoupling aspect has a
>> fundamental impact on the models to provide services and content, as
>> you rightly point out. Whether or not the operational gains of, e.g.,
>> caching are comparable depends on whether the models of services are
>> the same - that's where it gets tricky and often ends in comparing
>> apple and oranges.
> 
> I agree that it is critical to understand the model of service.  The
> paper under consideration does not explicitly say what sort of network
> it is considering, but I guess the assumption is a 'continuous,
> synchronous connection' network such as the connected Internet.  Caching
> may be a vital constituent of a network where there are interruptions of
> service. Situations such as trying to access content from a moving
> train:  Tunnels are rarely equipped with suitable wireless and breaks in
> connectivity are a fact of life.
> 
> Regards,
> Elwyn Davies
> 
> 
> 
> _______________________________________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

From: elwynd at folly.org.uk (Elwyn Davies)
Date: Fri, 06 Jan 2012 16:58:52 +0000
Subject: [Icn-interest] Universal caching unnecessary?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 2012-01-06 at 15:54 +0000, Dirk Trossen wrote:
> >  By decoupling the content name from the server location and from
> > the authentication, the publishing model of content is fundamentally
> > changed. 
> 
> 
> Now we're coming to a central point! The decoupling aspect has a
> fundamental impact on the models to provide services and content, as
> you rightly point out. Whether or not the operational gains of, e.g.,
> caching are comparable depends on whether the models of services are
> the same - that's where it gets tricky and often ends in comparing
> apple and oranges.

I agree that it is critical to understand the model of service.  The
paper under consideration does not explicitly say what sort of network
it is considering, but I guess the assumption is a 'continuous,
synchronous connection' network such as the connected Internet.  Caching
may be a vital constituent of a network where there are interruptions of
service. Situations such as trying to access content from a moving
train:  Tunnels are rarely equipped with suitable wireless and breaks in
connectivity are a fact of life.

Regards,
Elwyn Davies

From: matteo.varvello at alcatel-lucent.com (Varvello, Matteo (Matteo))
Date: Fri, 6 Jan 2012 10:40:26 -0600
Subject: [Icn-interest] Universal caching unnecessary? (Matteo Varvello)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Very interesting paper and topic. I think that the ICN model has far more potential than improving over CDN. To me, ICN does not imply ubiquitous caching: ICN enables ubiquitous caching, which is a big difference. Nothing prevents CDN-like caching models in ICN.  

Now talking about ICN and the CDN space. I do believe that ICN can provide terrific benefits to CDNs. CDNs evolved in an uncontrolled way around the end-to-end paradigm. They are more an hack than a clean solution, e.g., DNS/HTTP redirection, socket migration, etc. For example, this is an interesting reading on why the DNS shouldn't be used as it is used today http://queue.acm.org/detail.cfm?id=1647302 I think we can argue that ICN by approaching the problem with more freedom could do better, but it is still hard to claim that CDNs do not work, cause they indeed do work. However, CDNs might work better and be cheaper; also interconnection might be much easier by leveraging a common ICN layer. In research, we are enthusiastic about efficiency and optimization, but vendors like to hear cheap and easy to control. I truly believe that the ICN model can bring both, so the CDN space could be a first playground for an ICN substrate. 

Regards, 
Matteo 

-----Original Message-----
From: icn-interest-bounces at listserv.netlab.nec.de [mailto:icn-interest-bounces at listserv.netlab.nec.de] On Behalf Of icn-interest-request at listserv.netlab.nec.de
Sent: Friday, January 06, 2012 6:00 AM
To: icn-interest at listserv.netlab.nec.de
Subject: Icn-interest Digest, Vol 11, Issue 2

Send Icn-interest mailing list submissions to
	icn-interest at listserv.netlab.nec.de

To subscribe or unsubscribe via the World Wide Web, visit
	https://listserv.netlab.nec.de/mailman/listinfo/icn-interest
or, via email, send a message with subject or body 'help' to
	icn-interest-request at listserv.netlab.nec.de

You can reach the person managing the list at
	icn-interest-owner at listserv.netlab.nec.de

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Icn-interest digest..."

Today's Topics:

   1. Re: Request for Technical Info (Dirk Kutscher)
   2. Universal caching unnecessary? (Yaogong Wang)
   3. Re: Universal caching unnecessary? (Pedro Mart?nez Juli?)
   4. Re: Universal caching unnecessary? (Ruidong Li)

----------------------------------------------------------------------

Message: 1
Date: Thu, 5 Jan 2012 12:03:39 +0000
From: Dirk Kutscher <Dirk.Kutscher at neclab.eu>
Subject: Re: [Icn-interest] Request for Technical Info
To: "icn-interest at listserv.netlab.nec.de"
	<icn-interest at listserv.netlab.nec.de>
Message-ID:
	<82AB329A76E2484D934BBCA77E9F524924BC2BD3 at PALLENE.office.hd>
Content-Type: text/plain; charset="iso-8859-1"

In addition, you may find the proceedings and the published material of the 2010 Dagstuhl ICN seminar interesting:

http://www.dagstuhl.de/en/program/calendar/semhp/?semnr=10492

Best regards,
Dirk

From: icn-interest-bounces at listserv.netlab.nec.de [mailto:icn-interest-bounces at listserv.netlab.nec.de] On Behalf Of Bursztynowski Dariusz - Korpo TP
Date: Thu, 05 Jan 2012 10:02:00 +0100
To: icn-interest at listserv.netlab.nec.de
Subject: Re: [Icn-interest] Request for Technical Info

Good hint, I think. Alternatively, you can go directly to the web pages of the most known projects on this topic (in a random order belo :) ):

http://www.4ward-project.eu/ (see publications, and deliverables - WP6 in particular)
http://www.sail-project.eu/ (see publications, and deliverables - D.B.x in particular)
http://www.ccnx.org/ (and references therein)
http://www.fp7-pursuit.eu/PursuitWeb/ and www.psirp.org<http://www.psirp.org/> (although the latter has been unavailable today :( )
http://www.comet-project.org/
http://anr-connect.org/

Cheers,
Darek

________________________________
From: icn-interest-bounces at listserv.netlab.nec.de<mailto:icn-interest-bounces at listserv.netlab.nec.de> [mailto:icn-interest-bounces at listserv.netlab.nec.de]<mailto:[mailto:icn-interest-bounces at listserv.netlab.nec.de]> On Behalf Of Nicola Blefari Melazzi
Sent: Thursday, January 05, 2012 9:50 AM
To: icn-interest at listserv.netlab.nec.de<mailto:icn-interest at listserv.netlab.nec.de>
Subject: Re: [Icn-interest] Request for Technical Info

I would start from papers appeared on the ACM SIGCOMM Workshop on Information-Centric Networking (http://www.neclab.eu/icn-2011/), which quote, I think, most of the papers published on ICN

Nicola

Il 05/01/2012 09:39, Yeoh Chun-Yeow ha scritto:
Hi, all

Where can I find a good source of references related to ICN concept and technologies?
Please advice. Thanks

Regards,
Chun-Yeow

_______________________________________________

Icn-interest mailing list

Icn-interest at listserv.netlab.nec.de<mailto:Icn-interest at listserv.netlab.nec.de>

https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

--

--------------------------------------------------------------------------

Nicola BLEFARI MELAZZI, PhD

Full Professor of Telecommunications

Head of the Department of Electronic Engineering

Dipartimento di Ingegneria Elettronica

Universit? degli Studi di Roma - Tor Vergata

Via del Politecnico, 1

00133 - Roma (Italia)

Ph.:       +39 06 7259 7501

Fax:       +39 06 7259 7435

E-mail:    blefari at uniroma2.it<mailto:blefari at uniroma2.it>

URL:       http://blefari.eln.uniroma2.it/

--------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120105/f4242bf0/attachment-0001.htm>

------------------------------

Message: 2
Date: Thu, 5 Jan 2012 11:49:36 -0500
From: Yaogong Wang <wygivan at gmail.com>
Subject: [Icn-interest] Universal caching unnecessary?
To: icn-interest at listserv.netlab.nec.de
Message-ID:
	<CA+y5TP3e8ZuONopRMgwKovzH0dH14rAvL9-8rPF3hs6rUzMrJw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi all,

In a recent paper in HotNets 2011 (
http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final11.pdf,
especially Section 4.3), the authors argue that universal/ubiquitous
caching and locating the nearest copy of a requested content provide
marginal performance benefit over existing content distribution mechanisms
like CDN or Web proxies. What do you think about this argument?

Thanks,
Yaogong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120105/fb358b61/attachment-0001.htm>

------------------------------

Message: 3
Date: Thu, 05 Jan 2012 20:44:56 +0100
From: Pedro Mart?nez Juli? <pedromj at um.es>
Subject: Re: [Icn-interest] Universal caching unnecessary?
To: icn-interest at listserv.netlab.nec.de
Message-ID: <4F05FDB8.4050606 at um.es>
Content-Type: text/plain; charset=UTF-8; format=flowed

Yaogong Wang escribi?:
> Hi all,
>

Hi,

> In a recent paper in HotNets 2011 (
> http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final11.pdf,
> especially Section 4.3), the authors argue that universal/ubiquitous
> caching and locating the nearest copy of a requested content provide
> marginal performance benefit over existing content distribution mechanisms
> like CDN or Web proxies. What do you think about this argument?
>

 From my point of view, the ICN performance benefit is not intended to improve 
the CDN benefits. I think that CDNs will survive with ICN but they can rely on 
a simpler delivery protocol that will increase the overall performance by, at 
least, reducing the steps of a client to reach a content.

Just my two cents.

> Thanks,
> Yaogong
>

Regards,
Pedro

-- 
Pedro Martinez-Julia
Department of Communication and Information Engineering
Faculty of Computer Science
University of Murcia
Email: pedromj at um.es
---------------------------------------------------------
*** Entia non sunt multiplicanda praeter necessitatem ***

------------------------------

Message: 4
Date: Fri, 06 Jan 2012 10:23:23 +0900
From: Ruidong Li <lrd at nict.go.jp>
Subject: Re: [Icn-interest] Universal caching unnecessary?
To: icn-interest at listserv.netlab.nec.de
Message-ID: <4F064D0B.8020506 at nict.go.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi,

Agree with Pedro. The design of ICN has different and much more 
agressive motivations than CDN.
ICN is a balance between in-network caching storage & indexing cost and 
traffic overhead & latency over possible future network.

Best Regards,
Ruidong

Pedro Mart?nez Juli? ????????:
> Yaogong Wang escribi?:
>> Hi all,
>>
>
> Hi,
>
>> In a recent paper in HotNets 2011 (
>> http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final11.pdf,
>> especially Section 4.3), the authors argue that universal/ubiquitous
>> caching and locating the nearest copy of a requested content provide
>> marginal performance benefit over existing content distribution 
>> mechanisms
>> like CDN or Web proxies. What do you think about this argument?
>>
>
> From my point of view, the ICN performance benefit is not intended to 
> improve the CDN benefits. I think that CDNs will survive with ICN but 
> they can rely on a simpler delivery protocol that will increase the 
> overall performance by, at least, reducing the steps of a client to 
> reach a content.
>
> Just my two cents.
>
>> Thanks,
>> Yaogong
>>
>
> Regards,
> Pedro
>

-- 
-----------------------------------------------------------------------
Ruidong Li (Ph. D.)
Network Architecture Labrotary, Photonic Network Research Institute,
National Institute of Information and Communications Technology (NICT),
4-2-1 Nukui-kita Machi, Koganei City, Tokyo, 184-8795, Japan
Tel: +81-42-327-5813 Fax: +81-42-327-6680
Email: lrd at nict.go.jp 
-----------------------------------------------------------------------

------------------------------

_______________________________________________
Icn-interest mailing list
Icn-interest at listserv.netlab.nec.de
https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

End of Icn-interest Digest, Vol 11, Issue 2
*******************************************

From: wygivan at gmail.com (Yaogong Wang)
Date: Fri, 6 Jan 2012 11:29:46 -0500
Subject: [Icn-interest] Universal caching unnecessary?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <CA+y5TP3sKqFdHGPOVc0p3icYK=aUJaw6VRYNZQNM2297=[email-masked]>

That's a very interesting point. One possible publishing model could be
like a seeder in BitTorrent. Once you delivered a full copy of the content
to the network, the publisher may even leave the system. Are there other
models you envision? I think this finally comes to the business model of
ICN. Anyway, someone (the publishers, the users, the ISPs, etc.) needs to
provide the resources to host the contents. It depends on who has the most
incentive to do so.

Regards,
Yaogong

On Fri, Jan 6, 2012 at 10:54 AM, Dirk Trossen <dirk.trossen at cl.cam.ac.uk>wrote:

>  By decoupling the content name from the server location and from the
> authentication, the publishing model of content is fundamentally changed.
>
>
> Now we're coming to a central point! The decoupling aspect has a
> fundamental impact on the models to provide services and content, as you
> rightly point out. Whether or not the operational gains of, e.g., caching
> are comparable depends on whether the models of services are the same -
> that's where it gets tricky and often ends in comparing apple and oranges.
>
>
> -Ashok
>
> On Jan 6, 2012, at 1/6 9:56 AM, Yaogong Wang wrote:
>
> Hi Pedro and Ruidong,
>
> Thanks for sharing your opinions. I understand that ICN is not just
> improving CDN. But it appears to me that, by doing ICN and making each
> content self-contained, we basically make in-network caching easier. This
> would of course make CDN implementation simpler or more natural. But if
> that's all, I don't think there's enough incentive to overhaul the Internet
> architecture. I think the real power of ICN is to enable universal caching.
> But if it turns out that universal caching won't deliver the performance we
> expect and the current method (CDN which caches contents at strategic
> points in the Internet) is about the optimal point to balance between cost
> and benefit, then do we still need to do ICN?
>
> Thanks,
> Yaogong
>
> On Thu, Jan 5, 2012 at 8:23 PM, Ruidong Li <lrd at nict.go.jp> wrote:
>
>> Hi,
>>
>> Agree with Pedro. The design of ICN has different and much more agressive
>> motivations than CDN.
>> ICN is a balance between in-network caching storage & indexing cost and
>> traffic overhead & latency over possible future network.
>>
>> Best Regards,
>> Ruidong
>>
>>
>> Pedro Mart?nez Juli? ????????:
>>
>>  Yaogong Wang escribi?:
>>>
>>>> Hi all,
>>>>
>>>>
>>> Hi,
>>>
>>>  In a recent paper in HotNets 2011 (
>>>> http://conferences.sigcomm.**org/hotnets/2011/papers/**
>>>> hotnetsX-final11.pdf<http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final11.pdf>
>>>> ,
>>>> especially Section 4.3), the authors argue that universal/ubiquitous
>>>> caching and locating the nearest copy of a requested content provide
>>>> marginal performance benefit over existing content distribution
>>>> mechanisms
>>>> like CDN or Web proxies. What do you think about this argument?
>>>>
>>>>
>>> From my point of view, the ICN performance benefit is not intended to
>>> improve the CDN benefits. I think that CDNs will survive with ICN but they
>>> can rely on a simpler delivery protocol that will increase the overall
>>> performance by, at least, reducing the steps of a client to reach a content.
>>>
>>> Just my two cents.
>>>
>>>  Thanks,
>>>> Yaogong
>>>>
>>>>
>>> Regards,
>>> Pedro
>>>
>>>
>>
>> --
>> ------------------------------**------------------------------**
>> -----------
>> Ruidong Li (Ph. D.)
>> Network Architecture Labrotary, Photonic Network Research Institute,
>> National Institute of Information and Communications Technology (NICT),
>> 4-2-1 Nukui-kita Machi, Koganei City, Tokyo, 184-8795, Japan
>> Tel: +81-42-327-5813 Fax: +81-42-327-6680
>> Email: lrd at nict.go.jp ------------------------------**
>> ------------------------------**-----------
>>
>>
>>
>> ______________________________**_________________
>> Icn-interest mailing list
>> Icn-interest at listserv.netlab.**nec.de<Icn-interest at listserv.netlab.nec.de>
>> https://listserv.netlab.nec.**de/mailman/listinfo/icn-**interest<https://listserv.netlab.nec.de/mailman/listinfo/icn-interest>
>>
>
>
>
> --
> ========================
> Yaogong Wang, PhD candidate
> Department of Computer Science
> North Carolina State University
> http://www4.ncsu.edu/~ywang15/
> ========================
>  _______________________________________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest
>
>
> _______________________________________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest
>
>
>
> _______________________________________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest
>
>

-- 
========================
Yaogong Wang, PhD candidate
Department of Computer Science
North Carolina State University
http://www4.ncsu.edu/~ywang15/
========================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120106/a837d7ea/attachment.htm>

From: dirk.trossen at cl.cam.ac.uk (Dirk Trossen)
Date: Fri, 6 Jan 2012 15:54:55 +0000
Subject: [Icn-interest] Universal caching unnecessary?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

>  By decoupling the content name from the server location and from the authentication, the publishing model of content is fundamentally changed. 

Now we're coming to a central point! The decoupling aspect has a fundamental impact on the models to provide services and content, as you rightly point out. Whether or not the operational gains of, e.g., caching are comparable depends on whether the models of services are the same - that's where it gets tricky and often ends in comparing apple and oranges.

> 
> -Ashok
> 
> On Jan 6, 2012, at 1/6 9:56 AM, Yaogong Wang wrote:
> 
>> Hi Pedro and Ruidong,
>> 
>> Thanks for sharing your opinions. I understand that ICN is not just improving CDN. But it appears to me that, by doing ICN and making each content self-contained, we basically make in-network caching easier. This would of course make CDN implementation simpler or more natural. But if that's all, I don't think there's enough incentive to overhaul the Internet architecture. I think the real power of ICN is to enable universal caching. But if it turns out that universal caching won't deliver the performance we expect and the current method (CDN which caches contents at strategic points in the Internet) is about the optimal point to balance between cost and benefit, then do we still need to do ICN?
>> 
>> Thanks,
>> Yaogong
>> 
>> On Thu, Jan 5, 2012 at 8:23 PM, Ruidong Li <lrd at nict.go.jp> wrote:
>> Hi,
>> 
>> Agree with Pedro. The design of ICN has different and much more agressive motivations than CDN.
>> ICN is a balance between in-network caching storage & indexing cost and traffic overhead & latency over possible future network.
>> 
>> Best Regards,
>> Ruidong
>> 
>> 
>> Pedro Mart?nez Juli? ????????:
>> 
>> Yaogong Wang escribi?:
>> Hi all,
>> 
>> 
>> Hi,
>> 
>> In a recent paper in HotNets 2011 (
>> http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final11.pdf,
>> especially Section 4.3), the authors argue that universal/ubiquitous
>> caching and locating the nearest copy of a requested content provide
>> marginal performance benefit over existing content distribution mechanisms
>> like CDN or Web proxies. What do you think about this argument?
>> 
>> 
>> From my point of view, the ICN performance benefit is not intended to improve the CDN benefits. I think that CDNs will survive with ICN but they can rely on a simpler delivery protocol that will increase the overall performance by, at least, reducing the steps of a client to reach a content.
>> 
>> Just my two cents.
>> 
>> Thanks,
>> Yaogong
>> 
>> 
>> Regards,
>> Pedro
>> 
>> 
>> 
>> -- 
>> -----------------------------------------------------------------------
>> Ruidong Li (Ph. D.)
>> Network Architecture Labrotary, Photonic Network Research Institute,
>> National Institute of Information and Communications Technology (NICT),
>> 4-2-1 Nukui-kita Machi, Koganei City, Tokyo, 184-8795, Japan
>> Tel: +81-42-327-5813 Fax: +81-42-327-6680
>> Email: lrd at nict.go.jp -----------------------------------------------------------------------
>> 
>> 
>> 
>> _______________________________________________
>> Icn-interest mailing list
>> Icn-interest at listserv.netlab.nec.de
>> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest
>> 
>> 
>> 
>> -- 
>> ========================
>> Yaogong Wang, PhD candidate
>> Department of Computer Science
>> North Carolina State University
>> http://www4.ncsu.edu/~ywang15/
>> ========================
>> _______________________________________________
>> Icn-interest mailing list
>> Icn-interest at listserv.netlab.nec.de
>> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest
> 
> _______________________________________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120106/0bccdc9a/attachment-0001.htm>

From: ashokn at cisco.com (Ashok Narayanan)
Date: Fri, 6 Jan 2012 10:46:55 -0500
Subject: [Icn-interest] Universal caching unnecessary?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> universal/ubiquitous
> caching and locating the nearest copy of a requested content provide
> marginal performance benefit over existing content distribution mechanisms
> like CDN or Web proxies.

That statement is based on some previous research that is more applicable to a CDN as it pertains to broad caching of all content in order to reduce peering costs; based on the premise that a) content popularity curve is scale-free and therefore carries a lot of energy in a very long tail, b) there's not much content to the left of the "knee" in the popularity curve so you don't need that much cache capacity to store it, and c) it's practically impossible to cache content usefully to the right of the knee even if you try to combine caches from different nodes, so it's not worth doing it. If you consider the model of "universal caching" as simply an extension to today's publishing model then I don't think there is necessarily a significant benefit to ICN. At a micro scale, something like ICN/CCN eases the job of CDN providers; running a CDN today is a bit of a pain at multiple levels, with some manageable hassles and some unsolvable problems. ICN tends to formalize the concept of retrieving content from a nearby proxy/node/router as opposed to always going to the source (kind of like a mandated HTTP proxy), so that is certainly a win.

Perhaps a more interesting improvement IMHO is the possibility to overhaul _publishing_, not caching. An "origin server" provides a known location to receive a trusted content object (since the URL contains a reference to the origin server), but the publisher then has to operate this server and keep it up at all times; and it's possible through some delegation shenanigans to offer some (incomplete) degree of content integrity verification. By decoupling the content name from the server location and from the authentication, the publishing model of content is fundamentally changed. 

-Ashok

On Jan 6, 2012, at 1/6 9:56 AM, Yaogong Wang wrote:

> Hi Pedro and Ruidong,
> 
> Thanks for sharing your opinions. I understand that ICN is not just improving CDN. But it appears to me that, by doing ICN and making each content self-contained, we basically make in-network caching easier. This would of course make CDN implementation simpler or more natural. But if that's all, I don't think there's enough incentive to overhaul the Internet architecture. I think the real power of ICN is to enable universal caching. But if it turns out that universal caching won't deliver the performance we expect and the current method (CDN which caches contents at strategic points in the Internet) is about the optimal point to balance between cost and benefit, then do we still need to do ICN?
> 
> Thanks,
> Yaogong
> 
> On Thu, Jan 5, 2012 at 8:23 PM, Ruidong Li <lrd at nict.go.jp> wrote:
> Hi,
> 
> Agree with Pedro. The design of ICN has different and much more agressive motivations than CDN.
> ICN is a balance between in-network caching storage & indexing cost and traffic overhead & latency over possible future network.
> 
> Best Regards,
> Ruidong
> 
> 
> Pedro Mart?nez Juli? ????????:
> 
> Yaogong Wang escribi?:
> Hi all,
> 
> 
> Hi,
> 
> In a recent paper in HotNets 2011 (
> http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final11.pdf,
> especially Section 4.3), the authors argue that universal/ubiquitous
> caching and locating the nearest copy of a requested content provide
> marginal performance benefit over existing content distribution mechanisms
> like CDN or Web proxies. What do you think about this argument?
> 
> 
> From my point of view, the ICN performance benefit is not intended to improve the CDN benefits. I think that CDNs will survive with ICN but they can rely on a simpler delivery protocol that will increase the overall performance by, at least, reducing the steps of a client to reach a content.
> 
> Just my two cents.
> 
> Thanks,
> Yaogong
> 
> 
> Regards,
> Pedro
> 
> 
> 
> -- 
> -----------------------------------------------------------------------
> Ruidong Li (Ph. D.)
> Network Architecture Labrotary, Photonic Network Research Institute,
> National Institute of Information and Communications Technology (NICT),
> 4-2-1 Nukui-kita Machi, Koganei City, Tokyo, 184-8795, Japan
> Tel: +81-42-327-5813 Fax: +81-42-327-6680
> Email: lrd at nict.go.jp -----------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest
> 
> 
> 
> -- 
> ========================
> Yaogong Wang, PhD candidate
> Department of Computer Science
> North Carolina State University
> http://www4.ncsu.edu/~ywang15/
> ========================
> _______________________________________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120106/3c0e8c04/attachment.htm>

From: wygivan at gmail.com (Yaogong Wang)
Date: Fri, 6 Jan 2012 09:56:15 -0500
Subject: [Icn-interest] Universal caching unnecessary?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Pedro and Ruidong,

Thanks for sharing your opinions. I understand that ICN is not just
improving CDN. But it appears to me that, by doing ICN and making each
content self-contained, we basically make in-network caching easier. This
would of course make CDN implementation simpler or more natural. But if
that's all, I don't think there's enough incentive to overhaul the Internet
architecture. I think the real power of ICN is to enable universal caching.
But if it turns out that universal caching won't deliver the performance we
expect and the current method (CDN which caches contents at strategic
points in the Internet) is about the optimal point to balance between cost
and benefit, then do we still need to do ICN?

Thanks,
Yaogong

On Thu, Jan 5, 2012 at 8:23 PM, Ruidong Li <lrd at nict.go.jp> wrote:

> Hi,
>
> Agree with Pedro. The design of ICN has different and much more agressive
> motivations than CDN.
> ICN is a balance between in-network caching storage & indexing cost and
> traffic overhead & latency over possible future network.
>
> Best Regards,
> Ruidong
>
>
> Pedro Mart?nez Juli? ????????:
>
>  Yaogong Wang escribi?:
>>
>>> Hi all,
>>>
>>>
>> Hi,
>>
>>  In a recent paper in HotNets 2011 (
>>> http://conferences.sigcomm.**org/hotnets/2011/papers/**
>>> hotnetsX-final11.pdf<http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final11.pdf>
>>> ,
>>> especially Section 4.3), the authors argue that universal/ubiquitous
>>> caching and locating the nearest copy of a requested content provide
>>> marginal performance benefit over existing content distribution
>>> mechanisms
>>> like CDN or Web proxies. What do you think about this argument?
>>>
>>>
>> From my point of view, the ICN performance benefit is not intended to
>> improve the CDN benefits. I think that CDNs will survive with ICN but they
>> can rely on a simpler delivery protocol that will increase the overall
>> performance by, at least, reducing the steps of a client to reach a content.
>>
>> Just my two cents.
>>
>>  Thanks,
>>> Yaogong
>>>
>>>
>> Regards,
>> Pedro
>>
>>
>
> --
> ------------------------------**------------------------------**
> -----------
> Ruidong Li (Ph. D.)
> Network Architecture Labrotary, Photonic Network Research Institute,
> National Institute of Information and Communications Technology (NICT),
> 4-2-1 Nukui-kita Machi, Koganei City, Tokyo, 184-8795, Japan
> Tel: +81-42-327-5813 Fax: +81-42-327-6680
> Email: lrd at nict.go.jp ------------------------------**
> ------------------------------**-----------
>
>
>
> ______________________________**_________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.**nec.de<Icn-interest at listserv.netlab.nec.de>
> https://listserv.netlab.nec.**de/mailman/listinfo/icn-**interest<https://listserv.netlab.nec.de/mailman/listinfo/icn-interest>
>

-- 
========================
Yaogong Wang, PhD candidate
Department of Computer Science
North Carolina State University
http://www4.ncsu.edu/~ywang15/
========================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120106/c28e5a87/attachment.htm>

From: lrd at nict.go.jp (Ruidong Li)
Date: Fri, 06 Jan 2012 10:23:23 +0900
Subject: [Icn-interest] Universal caching unnecessary?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

Agree with Pedro. The design of ICN has different and much more 
agressive motivations than CDN.
ICN is a balance between in-network caching storage & indexing cost and 
traffic overhead & latency over possible future network.

Best Regards,
Ruidong

Pedro Mart?nez Juli? ????????:
> Yaogong Wang escribi?:
>> Hi all,
>>
>
> Hi,
>
>> In a recent paper in HotNets 2011 (
>> http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final11.pdf,
>> especially Section 4.3), the authors argue that universal/ubiquitous
>> caching and locating the nearest copy of a requested content provide
>> marginal performance benefit over existing content distribution 
>> mechanisms
>> like CDN or Web proxies. What do you think about this argument?
>>
>
> From my point of view, the ICN performance benefit is not intended to 
> improve the CDN benefits. I think that CDNs will survive with ICN but 
> they can rely on a simpler delivery protocol that will increase the 
> overall performance by, at least, reducing the steps of a client to 
> reach a content.
>
> Just my two cents.
>
>> Thanks,
>> Yaogong
>>
>
> Regards,
> Pedro
>

-- 
-----------------------------------------------------------------------
Ruidong Li (Ph. D.)
Network Architecture Labrotary, Photonic Network Research Institute,
National Institute of Information and Communications Technology (NICT),
4-2-1 Nukui-kita Machi, Koganei City, Tokyo, 184-8795, Japan
Tel: +81-42-327-5813 Fax: +81-42-327-6680
Email: lrd at nict.go.jp 
-----------------------------------------------------------------------

From: pedromj at um.es (=?UTF-8?B?UGVkcm8gTWFydMOtbmV6IEp1bGnDoQ==?=)
Date: Thu, 05 Jan 2012 20:44:56 +0100
Subject: [Icn-interest] Universal caching unnecessary?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Yaogong Wang escribi?:
> Hi all,
>

Hi,

> In a recent paper in HotNets 2011 (
> http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final11.pdf,
> especially Section 4.3), the authors argue that universal/ubiquitous
> caching and locating the nearest copy of a requested content provide
> marginal performance benefit over existing content distribution mechanisms
> like CDN or Web proxies. What do you think about this argument?
>

 From my point of view, the ICN performance benefit is not intended to improve 
the CDN benefits. I think that CDNs will survive with ICN but they can rely on 
a simpler delivery protocol that will increase the overall performance by, at 
least, reducing the steps of a client to reach a content.

Just my two cents.

> Thanks,
> Yaogong
>

Regards,
Pedro

-- 
Pedro Martinez-Julia
Department of Communication and Information Engineering
Faculty of Computer Science
University of Murcia
Email: pedromj at um.es
---------------------------------------------------------
*** Entia non sunt multiplicanda praeter necessitatem ***

From: wygivan at gmail.com (Yaogong Wang)
Date: Thu, 5 Jan 2012 11:49:36 -0500
Subject: [Icn-interest] Universal caching unnecessary?
Message-ID: <[email-masked]>

Hi all,

In a recent paper in HotNets 2011 (
http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final11.pdf,
especially Section 4.3), the authors argue that universal/ubiquitous
caching and locating the nearest copy of a requested content provide
marginal performance benefit over existing content distribution mechanisms
like CDN or Web proxies. What do you think about this argument?

Thanks,
Yaogong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120105/fb358b61/attachment.htm>

From: Dirk.Kutscher at neclab.eu (Dirk Kutscher)
Date: Thu, 5 Jan 2012 12:03:39 +0000
Subject: [Icn-interest] Request for Technical Info
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

In addition, you may find the proceedings and the published material of the 2010 Dagstuhl ICN seminar interesting:

http://www.dagstuhl.de/en/program/calendar/semhp/?semnr=10492

Best regards,
Dirk

From: icn-interest-bounces at listserv.netlab.nec.de [mailto:icn-interest-bounces at listserv.netlab.nec.de] On Behalf Of Bursztynowski Dariusz - Korpo TP
Date: Thu, 05 Jan 2012 10:02:00 +0100
To: icn-interest at listserv.netlab.nec.de
Subject: Re: [Icn-interest] Request for Technical Info

Good hint, I think. Alternatively, you can go directly to the web pages of the most known projects on this topic (in a random order belo :) ):

http://www.4ward-project.eu/ (see publications, and deliverables - WP6 in particular)
http://www.sail-project.eu/ (see publications, and deliverables - D.B.x in particular)
http://www.ccnx.org/ (and references therein)
http://www.fp7-pursuit.eu/PursuitWeb/ and www.psirp.org<http://www.psirp.org/> (although the latter has been unavailable today :( )
http://www.comet-project.org/
http://anr-connect.org/

Cheers,
Darek

________________________________
From: icn-interest-bounces at listserv.netlab.nec.de<mailto:icn-interest-bounces at listserv.netlab.nec.de> [mailto:icn-interest-bounces at listserv.netlab.nec.de]<mailto:[mailto:icn-interest-bounces at listserv.netlab.nec.de]> On Behalf Of Nicola Blefari Melazzi
Sent: Thursday, January 05, 2012 9:50 AM
To: icn-interest at listserv.netlab.nec.de<mailto:icn-interest at listserv.netlab.nec.de>
Subject: Re: [Icn-interest] Request for Technical Info

I would start from papers appeared on the ACM SIGCOMM Workshop on Information-Centric Networking (http://www.neclab.eu/icn-2011/), which quote, I think, most of the papers published on ICN

Nicola

Il 05/01/2012 09:39, Yeoh Chun-Yeow ha scritto:
Hi, all

Where can I find a good source of references related to ICN concept and technologies?
Please advice. Thanks

Regards,
Chun-Yeow

_______________________________________________

Icn-interest mailing list

Icn-interest at listserv.netlab.nec.de<mailto:Icn-interest at listserv.netlab.nec.de>

https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

--

--------------------------------------------------------------------------

Nicola BLEFARI MELAZZI, PhD

Full Professor of Telecommunications

Head of the Department of Electronic Engineering

Dipartimento di Ingegneria Elettronica

Universit? degli Studi di Roma - Tor Vergata

Via del Politecnico, 1

00133 - Roma (Italia)

Ph.:       +39 06 7259 7501

Fax:       +39 06 7259 7435

E-mail:    blefari at uniroma2.it<mailto:blefari at uniroma2.it>

URL:       http://blefari.eln.uniroma2.it/

--------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120105/f4242bf0/attachment.htm>

From: Dariusz.Bursztynowski at telekomunikacja.pl (Bursztynowski Dariusz - Korpo TP)
Date: Thu, 5 Jan 2012 09:01:37 +0000
Subject: [Icn-interest] Request for Technical Info
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Good hint, I think. Alternatively, you can go directly to the web pages of the most known projects on this topic (in a random order belo :) ):

http://www.4ward-project.eu/ (see publications, and deliverables - WP6 in particular)
http://www.sail-project.eu/ (see publications, and deliverables - D.B.x in particular)
http://www.ccnx.org/ (and references therein)
http://www.fp7-pursuit.eu/PursuitWeb/ and www.psirp.org<http://www.psirp.org/> (although the latter has been unavailable today :( )
http://www.comet-project.org/
http://anr-connect.org/

Cheers,
Darek

________________________________
From: icn-interest-bounces at listserv.netlab.nec.de [mailto:icn-interest-bounces at listserv.netlab.nec.de] On Behalf Of Nicola Blefari Melazzi
Sent: Thursday, January 05, 2012 9:50 AM
To: icn-interest at listserv.netlab.nec.de
Subject: Re: [Icn-interest] Request for Technical Info

I would start from papers appeared on the ACM SIGCOMM Workshop on Information-Centric Networking (http://www.neclab.eu/icn-2011/), which quote, I think, most of the papers published on ICN

Nicola

Il 05/01/2012 09:39, Yeoh Chun-Yeow ha scritto:
Hi, all

Where can I find a good source of references related to ICN concept and technologies?
Please advice. Thanks

Regards,
Chun-Yeow

_______________________________________________

Icn-interest mailing list

Icn-interest at listserv.netlab.nec.de<mailto:Icn-interest at listserv.netlab.nec.de>

https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

--

--------------------------------------------------------------------------

Nicola BLEFARI MELAZZI, PhD

Full Professor of Telecommunications

Head of the Department of Electronic Engineering

Dipartimento di Ingegneria Elettronica

Universit? degli Studi di Roma - Tor Vergata

Via del Politecnico, 1

00133 - Roma (Italia)

Ph.:       +39 06 7259 7501

Fax:       +39 06 7259 7435

E-mail:    blefari at uniroma2.it<mailto:blefari at uniroma2.it>

URL:       http://blefari.eln.uniroma2.it/

--------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120105/e778c26a/attachment.htm>

From: blefari at uniroma2.it (Nicola Blefari Melazzi)
Date: Thu, 05 Jan 2012 09:49:31 +0100
Subject: [Icn-interest] Request for Technical Info
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I would start from papers appeared on the ACM SIGCOMM Workshop on 
Information-Centric Networking (http://www.neclab.eu/icn-2011/), which 
quote, I think, most of the papers published on ICN

Nicola

Il 05/01/2012 09:39, Yeoh Chun-Yeow ha scritto:
> Hi, all
>
> Where can I find a good source of references related to ICN concept 
> and technologies?
>
> Please advice. Thanks
>
> Regards,
> Chun-Yeow
>
>
> _______________________________________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

-- 
--------------------------------------------------------------------------
Nicola BLEFARI MELAZZI, PhD
Full Professor of Telecommunications
Head of the Department of Electronic Engineering

Dipartimento di Ingegneria Elettronica
Universit? degli Studi di Roma - Tor Vergata
Via del Politecnico, 1
00133 - Roma (Italia)

Ph.:       +39 06 7259 7501
Fax:       +39 06 7259 7435
E-mail:    blefari at uniroma2.it
URL:       http://blefari.eln.uniroma2.it/
--------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120105/eeac8c1f/attachment.htm>

From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow)
Date: Thu, 5 Jan 2012 16:39:38 +0800
Subject: [Icn-interest] Request for Technical Info
Message-ID: <[email-masked]>

Hi, all

Where can I find a good source of references related to ICN concept and
technologies?

Please advice. Thanks

Regards,
Chun-Yeow
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120105/f01350da/attachment.htm>

Just my two cents.

Thanks,
Yaogong

Regards,
Pedro

--
-----------------------------------------------------------------------
Ruidong Li (Ph. D.)
Network Architecture Labrotary, Photonic Network Research Institute,
National Institute of Information and Communications Technology (NICT),
4-2-1 Nukui-kita Machi, Koganei City, Tokyo, 184-8795, Japan
Tel: +81-42-327-5813<tel:%2B81-42-327-5813> Fax: +81-42-327-6680<tel:%2B81-42-327-6680>
Email: lrd at nict.go.jp<mailto:lrd at nict.go.jp> -----------------------------------------------------------------------

_______________________________________________
Icn-interest mailing list
Icn-interest at listserv.netlab.nec.de<mailto:Icn-interest at listserv.netlab.nec.de>
https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

--
========================
Yaogong Wang, PhD candidate
Department of Computer Science
North Carolina State University
http://www4.ncsu.edu/~ywang15/
========================
_______________________________________________
Icn-interest mailing list
Icn-interest at listserv.netlab.nec.de<mailto:Icn-interest at listserv.netlab.nec.de>
https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

_______________________________________________
Icn-interest mailing list
Icn-interest at listserv.netlab.nec.de<mailto:Icn-interest at listserv.netlab.nec.de>
https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

_______________________________________________
Icn-interest mailing list
Icn-interest at listserv.netlab.nec.de<mailto:Icn-interest at listserv.netlab.nec.de>
https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

--
========================
Yaogong Wang, PhD candidate
Department of Computer Science
North Carolina State University
http://www4.ncsu.edu/~ywang15/
========================
_______________________________________________
Icn-interest mailing list
Icn-interest at listserv.netlab.nec.de<mailto:Icn-interest at listserv.netlab.nec.de>
https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

> 
> Second, I think NDN routing is not as good as IP in adapting to network
> dynamics. Since the Interest and Data packet follow the same path, then if
> some node on the path fails (or if the related PIT entry in a node on the
> path is lost) when the data comes back to content requester(s) , the data
> packet will not be forwarded and the requester(s) have to solicit it again.
> While in IP networking, the routing may adapt to the node failure fast and
> redirect the data packet to the requester. What do you think?

If NDN runs the same routing protocol as IP's, then they converge at the same time (roughly). So what you want to compare is
the packet delivery performance before routing has converged.

In NDN, if a link or node fails, the downstream node will send the interest to other interfaces, and when this interest hits
one of the cached copies of data upstream, it'll bring data back and the downstream node will keep sending interests that way. 
Thus the repair happens inside the network most of the time, and it benefits from NDN's multipath capability and loop prevention.
IP forwards packets using the best path in the routing table, which is in flux during convergence period, and many studies have
shown that there're significant packet losses and delays. There's IP fast rerouting work, which uses backup routes to get around of failures
quickly, but they need pre-configured based on the topology and expected failure scenarios.

Another point is that there're faults that IP routing cannot even see, e.g., during prefix hijacking or congestion, from IP routing's point of view,
everything is fine and it keeps sending traffic to the faulty place. But NDN will notice the problems due to interest timeout and send the interest
to other faces. My view is that NDN will have better packet delivery performance than IP due to naming the packets and maintaining states in the router.
We're doing some simulation studies along this line.

Thanks,

---
beichuan

ps: if this list is not an appropriate place, we can take the discussion offline.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120110/63bc0a89/attachment.htm>