Subject: [icnrg] Announcing ICNRG @ IETF 85

From: Börje Ohlman <[email-masked]>
Date: Mon, 8 Oct 2012 10:00:00 +0200

The next ICNRG will be held at  IETF 85, Atlanta, Georgia, USA, November 4-9, 2012
      * Meeting time: WEDNESDAY 13.00-15.40 (prel)

The main discussion at the meeting will be the three documents that the RG has set out to produce. 
ICN Survey document
A document that provides a survey of different approaches and techniques
ICN Problem statement
A document that describes the ICN problem statement, the main concepts and research challenges in depth.
ICN Baseline Scenarios
A document that defines reference baseline scenarios to enable performance comparisons between different approaches.
People are encouraged to present their views on what they think should be the contents of these documents. Early contributions (in bullet form or as draft text) are welcome both on the mailing list and the wiki. Presentations of draft material are welcome at the meeting.

Most likely we will also have time to discuss one or two specific technical topics at the meeting. Proposals for such topics as well as presentations are invited.

As we are expected to publish our agenda by 2012-10-24 (Wednesday) we would like to have your input by Sunday 2012-10-21.

	Börje, Dave & Dirk

ICN RG Wiki:
http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg

---

From: Seung-Ik Lee <[email-masked]>
Date: Thu, 18 Oct 2012 10:59:40 +0900

Dear icnrg colleagues,

Regarding the RG documents, don't we touch any issues on ICN deployments?

As we have seen in the presentation by ZTE in Vancouver, ISPs are
interested in the short-term approaches to ICN.
Though the traditional ICN approaches (such as CCN/NDN) have provided
ISPs a ladder out of dumb-pipes, ISPs may have difficulties on
clean-slate approaches of ICN.
IMHO, based on our surveys on ISP R&D approaches to ICN, Korean ISPs
are in the similar situation.

In this motivation, I have interests in ICN deployment strategies
(such as ICN over IP or ICN over SDN as short-term approaches)
but no idea which RG document would cover the deployment issues, even
whether icnrg will cover the deployment issue or not.

2012/10/8 Börje Ohlman <[email-masked]>:
> A document that defines reference baseline scenarios to enable performance
> comparisons between different approaches.
>
> People are encouraged to present their views on what they think should be
> the contents of these documents. Early contributions (in bullet form or as
> draft text) are welcome both on the mailing list and the wiki. Presentations
> of draft material are welcome at the meeting.
>
> Most likely we will also have time to discuss one or two specific technical
> topics at the meeting. Proposals for such topics as well as presentations
> are invited.
>
> As we are expected to publish our agenda by 2012-10-24 (Wednesday) we would
> like to have your input by Sunday 2012-10-21.
>
> Börje, Dave & Dirk
>
>
> ICN RG Wiki:
>
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg
>

-- 
Seung-Ik Lee (이승익)
Standards Research Center, ETRI
Tel.    +82-42-860-1483
Fax.   +82-42-861-5404
Email. [email-masked]

---

From: Dirk Kutscher <[email-masked]>
Date: Thu, 18 Oct 2012 02:44:06 +0000

Hello Seung-Ik Lee,

Yes, that's a good point. How about including that in the problem statement?

Best regards,
Dirk

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Seung-Ik Lee
> Sent: Donnerstag, 18. Oktober 2012 04:00
> To: Börje Ohlman
> Cc: icnrg
> Subject: Re: [icnrg] Announcing ICNRG @ IETF 85
> 
> Dear icnrg colleagues,
> 
> As we have seen in the presentation by ZTE in Vancouver, ISPs are interested
> in the short-term approaches to ICN.
> ISPs a ladder out of dumb-pipes, ISPs may have difficulties on clean-slate
> approaches of ICN.
> IMHO, based on our surveys on ISP R&D approaches to ICN, Korean ISPs are
> in the similar situation.
> 
> In this motivation, I have interests in ICN deployment strategies (such as ICN
> over IP or ICN over SDN as short-term approaches) but no idea which RG
> document would cover the deployment issues, even whether icnrg will cover
> the deployment issue or not.
> 
> 
> > A document that defines reference baseline scenarios to enable
> > performance comparisons between different approaches.
> >
> > People are encouraged to present their views on what they think should
> > be the contents of these documents. Early contributions (in bullet
> > form or as draft text) are welcome both on the mailing list and the
> > wiki. Presentations of draft material are welcome at the meeting.
> >
> > Most likely we will also have time to discuss one or two specific
> > technical topics at the meeting. Proposals for such topics as well as
> > presentations are invited.
> >
> > As we are expected to publish our agenda by 2012-10-24 (Wednesday) we
> > would like to have your input by Sunday 2012-10-21.
> >
> > Börje, Dave & Dirk
> >
> >
> > ICN RG Wiki:
> >

---

From: Börje Ohlman <[email-masked]>
Date: Thu, 18 Oct 2012 02:55:13 +0000

Dear Seung-Ik,

I think you bring up a very good point. I agree that deployment and migration issues are very important. I also agree that they don't seem like a good fit for any of the currently proposed ICNRG documents. 

The three documents listed as current work items are in no way set in stone, they should just be seen as a starting point for our work. If you would like to propose the RG that we should start working on a deployment document you are most welcome to do so, that will most certainly be in scope for our discussion in Atlanta.

As a general comment I also like to mention that we as an RG are not bound by all the rules that apply to IETF WGs, e.g. we are free to discuss late contributions produced after the IETF draft deadlines. So if people find the time to write up some material for the ICNRG after the IETF drafts are done they are welcome to announce it to the ICNRG mailing list. If the group agrees we are free to discuss also such material at our meeting,

     Börje

---

From: "Will Liu (Shucheng)" <[email-masked]>
Date: Thu, 18 Oct 2012 09:07:56 +0000

Hi,

My group are also interested in ICN deployment and have done some survey on this matter. The discussion on ICN deployment is a great topic which ISPs will definitely be interested in. Here are our 2-cents. 

The evolvement of ICN may take the following three implementations: integrated with IP, over IP and over SDN. These strategies all can help the ISP shift from the traditional IP to ICN. The only question is which one is the best choice for large scale deployment? 

Integrated with IP strategy extends the existing IP protocol (IP option) to support ICN. The updated IP router, called content router, will deal with such special packets. However, many routers with no support of such extension may directly drop the packets with an unknown IP option. 

ICN over IP strategy uses an overlay approach. Content-related operation will be performed on the high layer and Content-related information will be sent through a tunnel. Due to the limited knowledge of physical topology and unnecessary packet encapsulation/disconsolation, the efficiency may be limited. 

ICN over SDN strategy exploits SDN controller to perform content-related operation. However, SDN itself is an ongoing approach and is typically used in a local domain. The performance in a large scale deployment is unknown. 

Will

> B?rje Ohlman
> Sent: Thursday, October 18, 2012 10:55 AM
> To: Seung-Ik Lee
> Cc: icnrg
> I think you bring up a very good point. I agree that deployment and
> migration issues are very important. I also agree that they don't seem like a
> good fit for any of the currently proposed ICNRG documents.
> 
> The three documents listed as current work items are in no way set in stone,
> they should just be seen as a starting point for our work. If you would like to
> propose the RG that we should start working on a deployment document
> you are most welcome to do so, that will most certainly be in scope for our
> discussion in Atlanta.
> 
> As a general comment I also like to mention that we as an RG are not bound
> by all the rules that apply to IETF WGs, e.g. we are free to discuss late
> contributions produced after the IETF draft deadlines. So if people find the
> time to write up some material for the ICNRG after the IETF drafts are done
> they are welcome to announce it to the ICNRG mailing list. If the group
> agrees we are free to discuss also such material at our meeting,
> 
>      Börje
> 
> >> The next ICNRG will be held at  IETF 85, Atlanta, Georgia, USA,
> November
> >> 4-9, 2012
> >> The main discussion at the meeting will be the three documents that the
> RG
> >> has set out to produce.
> >>
> >> ICN Survey document
> >>
> >> A document that describes the ICN problem statement, the main
> concepts and
> >> research challenges in depth.
> >>
> >> ICN Baseline Scenarios
> >>
> performance
> be
> would

---

From: Seung-Ik Lee <[email-masked]>
Date: Thu, 18 Oct 2012 18:12:13 +0900

Yes, I think that firstly we need to specify such deployment and
migration issues in the PS document as Dirk proposed.
But I'm not quite sure that the relevant ICN use cases in different
deployment approaches could be included in the scenario document as
Börje pointed out.
Then we may need a separate document for ICN deployment and migration issues.

---

From: Seung-Ik Lee <[email-masked]>
Date: Thu, 18 Oct 2012 18:39:10 +0900

Thank you for the useful information.

I think that the integrated deployment option is not that different
from the clean-slate approach of ICN.

IMHO, overlay approach is most short-term-feasible approach and some
ISPs have deployed their testbeds or some are in use in different
ways.
But what I usually heard about the overlay approach is "what is
different from CDN?". That kind of questions needs to be addressed.

SDN-based approach is quite adorable but, yes, it is in an early stage
yet and we need interworking protocols as done in CDNI.

I think that we can have such problems specified in PS document.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 Oct 2012 10:45:18 +0100

Hi Börje,

> A document that describes the ICN problem statement, the main concepts and research challenges in depth.

Just on a terminology thing, which might be nothing or
might save significant confusion later. (And sorry if
this is a late/repeat comment, I don't recall if this
was discussed or not.)

The term problem statement seems wrong to me here.

In IETF WG's a <foo> problem statement draft is often
used to try make sure everyone's trying to solve the
same problem. (That may or may not be a good or bad
approach, but its sometimes done.)

Here, you seem to want to set out concepts and research
challenges, which seems to me like its a different
beast.

For example, there's nothing to stop folks participating
in ICNRG from working on entirely different problems
so discussion of "the" problem statement may well get
in the way and confuse people into thinking that we
must all work on the same thing and argue that folks
who're working on something different are wrong to
do that.

Bottom line: I'd suggest renaming this document to
"ICN concepts and research challenges" rather than
"ICN problem statement."

Cheers,
S.

---

From: Dirk Trossen <[email-masked]>
Date: Thu, 18 Oct 2012 12:14:20 +0100

The PSIRP project (pre-decessor to the current EU PURSUIT project) has done some incentive and deployment analysis, which looked at the adoption of 'native' vs 'overlaid' deployments, driven by needs of industries demanding these solutions (and these industries are NOT ISPs since they merely fulfil a need). 

It might be helpful for some of the discussion although the modelling part might be harder to digest at places ;-)

The document is available at http://www.psirp.org/files/Deliverables/FP7-INFSO-ICT-216173-PSIRP-D4.6_FinalReportOnDeplIncBusinessModels.pdf

Best,

Dirk

---

From: Damien Saucez <[email-masked]>
Date: Thu, 18 Oct 2012 14:34:58 +0200

> The document is available at http://www.psirp.org/files/Deliverables/FP7-INFSO-ICT-216173-PSIRP-D4.6_FinalReportOnDeplIncBusinessModels.pdf

thank you for the link, this model is interesting.

Sec. 4 of http://hal.inria.fr/docs/00/68/44/58/PDF/paper.pdf can be
read as a mean to deal with ICN islands (here running CCN, but it
can be generalised), inter-connected with IP. The idea is to form
an overlay and the technology we had in mind, even though we
do not name it in the report, is LISP.

Regards,

Damien Saucez

---

From: Börje Ohlman <[email-masked]>
Date: Thu, 18 Oct 2012 15:53:14 +0200

Stephen,

I think you have a good point. I never liked the Problem Statement title anyway, but never  managed to formulate why I didn't like it. I propose we change the title as you propose.

Other views?
Dirk and Dave, what do you think?

	Börje

---

From: David R Oran <[email-masked]>
Date: Thu, 18 Oct 2012 10:34:55 -0700

> Dirk and Dave, what do you think?
I agree with Stephen's assessment. Problem statement is the wrong terminology. I also like the proposed title.

---

From: "Field, Brian" <[email-masked]>
Date: Thu, 18 Oct 2012 18:54:26 +0000

Does anyone (beside me) think that a CDN effectively is already doing "ICN" but tunneled over an HTTP infrastructure (via HTTP/TCP/IP).   I think of CDN and native ICN (where the router is caching and forwarding at the ICN level) nearly identical forwarding paradigms just operating at different levels in the stack.  

There's work in standardizing the intra-CDN  and inter-CDN control plan (in CDN-I and elsewhere).  IMO, it would be useful if we had the same control protocol operating in both the CDN and ICN domains and the "transition" was just changing the layer at which forwarding occurred.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Will Liu (Shucheng)
Sent: Thursday, October 18, 2012 3:08 AM
To: Börje Ohlman; Seung-Ik Lee
Cc: 任婧; icnrg; Jianping Wang
Subject: Re: [icnrg] Announcing ICNRG @ IETF 85

Hi,

Will

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of B?rje Ohlman
> migration issues are very important. I also agree that they don't seem 
> like a good fit for any of the currently proposed ICNRG documents.
> 
> The three documents listed as current work items are in no way set in 
> stone, they should just be seen as a starting point for our work. If 
> you would like to propose the RG that we should start working on a 
> deployment document you are most welcome to do so, that will most 
> certainly be in scope for our discussion in Atlanta.
> 
> As a general comment I also like to mention that we as an RG are not 
> bound by all the rules that apply to IETF WGs, e.g. we are free to 
> discuss late contributions produced after the IETF draft deadlines. So 
> if people find the time to write up some material for the ICNRG after 
> the IETF drafts are done they are welcome to announce it to the ICNRG 
> mailing list. If the group agrees we are free to discuss also such 
> material at our meeting,
> 
>      Börje
> 
> > Though the traditional ICN approaches (such as CCN/NDN) have 
> > provided ISPs a ladder out of dumb-pipes, ISPs may have difficulties 
> > on clean-slate approaches of ICN.
> > (such as ICN over IP or ICN over SDN as short-term approaches) but 
> > no idea which RG document would cover the deployment issues, even 
> >> the contents of these documents. Early contributions (in bullet 
> >> form or as draft text) are welcome both on the mailing list and the wiki.
> Presentations
> >> technical topics at the meeting. Proposals for such topics as well 
> >> as presentations are invited.
> >>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 18 Oct 2012 19:19:12 +0000

> Integrated with IP strategy extends the existing IP protocol (IP option) to support ICN. The updated IP router, called content router, will deal with such special packets. However, many routers wit…

IP-layer information could be carried in IPv6's hop-by-hop option, and is not *supposed* to have that effect. Tying this to IPv4 does' sound like a long term strategy.

---

From: <[email-masked]>
Date: Thu, 18 Oct 2012 20:00:21 +0000

Hi Brian.

You are right that for a subset of cases  it seems like ICN is just CDN, but that would be missing a lot of the picture.

First, can you describe what the properties of native ICN and non-native ICN are?  Is there no "router caching" in non-native ICN?

A few of the things that don't seem to fit into traditional CDNs (with my limited knowledge of state-of-the art CDNs) are:

- Peer-to-peer.  How can CDNs help two nodes communicate without infrastructure?  If two nodes meet in the field (such as in the DARPA CBMEN program, or two phones on a plane or tunnel or ship), how can CDNs help them exchange information?

- Security. How can CDNs ensure the provenance of the data?

- Disruption tolerance. How can CDNs enable data-muling?

- Flow control. How can you change the way we do flow-control using CDNs?

- Lone hit. How can CDNs help distribute data that was previously unknown to the CDN. For example, from a random webpage.

Granted, some of those are somewhat possible using CDNs. Some of those are possible with a little bit of work on CDNs and some are possible with a lot of work.  

Everything is possible.

But, we're going to get to a point where we're changing so much that what we started with is unrecognizable.  Starting with CDNs is limiting what we can do and how we do it.  The model many ICNs take is a clean slate one. And as far as possible, we try to learn the lessons of CDNs, DTNs, IPs, Gnutellas, Multicast, RTPs, IPSecs, TCPs, DNSs, OSPFs, etc.

Caching at the router level is one of the many potentially beneficial (but not-required) characteristics of ICNs.

If we talk about a specific ICN architecture (like CCN) we can talk about specific advantages and disadvantages, tradeoffs made, work done so far, work planned and work yet to be done.

Nacho

--
Nacho (Ignacio) Solis
Senior Research Scientist
Palo Alto Research Center (PARC)
+1(650) 812-4458
[email-masked]

---

From: Spiros Spirou <[email-masked]>
Date: Fri, 19 Oct 2012 10:35:31 +0300

Hi Nacho and Brian,

Good points! In CDNI, the relationship between CDN and ICN was briefly 
discussed in section 3 of the (now expired) 
draft-fmn-cdni-advanced-use-cases. Unfortunately, we never carried this 
work forward.

The draft is available at:
http://tools.ietf.org/id/draft-fmn-cdni-advanced-use-cases-00.txt

Spiros

On 18/10/2012 11:00 μμ, [email-masked] wrote:
>> To: BΓ¶rje Ohlman; Seung-Ik Lee
>> Cc: δ»»ε©§; icnrg; Jianping Wang
>>>      BΓ¶rje
>>>> 2012/10/8 BΓ¶rje Ohlman <[email-masked]>:
>>>>> BΓ¶rje, Dave & Dirk
>>>> Seung-Ik Lee (μ�΄μ�Ήμ�µ)

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Fri, 19 Oct 2012 08:44:10 +0000

|Bottom line: I'd suggest renaming this document to
  |"ICN concepts and research challenges" rather than
  |"ICN problem statement."

I second this too, although the "concepts" part may overlap with the survey document.

Best Regards,

Kostas

---

From: Andrea Detti <[email-masked]>
Date: Fri, 19 Oct 2012 14:56:22 +0200

Dear Will,
regarding the "Integrated with IP" strategy, we proposed in [1], in 2011 
we assessed performance of sending IP packets with a novel IP Option 
(named CONET option [2]) and we found that the most of traversed routers 
did NOT block packets with the, unknown, IP CONET Option. See our 
measurements in section 5.2 of [1].
Have you some novel measurements that motivates your sentence " many 
routers with no support of such extension may directly drop the packets 
with an unknown IP option" ?
Regards,

Andrea

[1] A. DETTI, N. BLEFARI-MELAZZI, S. SALSANO, M. POMPOSINI “ CONET: A 
Content Centric Inter-Networking Architecture”, ACM SIGCOMM 2011, ICN 
workshop, Toronto , Canada, 19 August 2011 
(http://netgroup.uniroma2.it/Andrea_Detti/papers/conferences/CONET.pdf)
[2] https://tools.ietf.org/html/draft-detti-conet-ip-option-02

-- 
---------------------------------------
Andrea Detti, PhD
Dip. Ingegneria Elettronica
Universita' di Roma "Tor Vergata"
Via del Politecnico 1, 00133 Roma, Italy
Tel.: +39-06-7259-7445
Fax : +39-06-7259-7435
Mobile: +39-320-4391909
email: [email-masked]
---------------------------------------

---

From: Paulo Mendes <[email-masked]>
Date: Fri, 19 Oct 2012 22:16:44 +0100

I support the idea of renaming the "problem statement" draft by an "research challenges" draft.. I also agree that "concepts" are more a subject of the survey drafts. Actually IMO these two drafts should really be align, to avoid too much overlapping..

I would say that for a RG (not WG) we need to have a glimpse of the following to start with:
a) Characterization of the major ICN concepts and techniques
b) identification of the major research challenges

So why not to rename the two drafts as:
a) ICN Concepts (instead of he survey one)
b) ICN Research Challenges (instead of the problem statement)

The first one may be used later on to drive some common understanding about an ICN architecture. The second one to drive the identification of specific (protocol) components.

Regards
Paulo

> I second this too, although the "concepts" part may overlap with the survey document.

-------------------------------------------------------------
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: Börje Ohlman <[email-masked]>
Date: Mon, 22 Oct 2012 13:28:37 +0200

I've listed the proposed agenda items on the Wiki, see also below. Please let me know if I missed some proposition or if you have any last minute request before we make the agenda tomorrow, Tuesday.

	Börje

---------------
Proposed agenda items for ICNRG@IETF 85
Discussion ICNRG documents
Discussing who to deal with ICN deployment issues
Proposed inputs:
 http://www.psirp.org/files/Deliverables/FP7-INFSO-ICT-216173-PSIRP-D4.6_FinalReportOnDeplIncBusinessModels.pdf
 http://hal.inria.fr/docs/00/68/44/58/PDF/paper.pdf
Presentation of On the Content Retrieval In Information-Centric Network, http://datatracker.ietf.org/doc/draft-ren-icn-content-retrieval
ICN vs. CDN  http://tools.ietf.org/id/draft-fmn-cdni-advanced-use-cases-00.txt
Presentation of updates to Information-Centric Network in an ISP,  http://tools.ietf.org/html/draft-li-icnrg-icn-isp-01
Planning of interim meeting

---

From: Damien Saucez <[email-masked]>
Date: Mon, 22 Oct 2012 14:54:44 +0200

Hello,

That sounds nice to me.

If we have still time, I would ask for a 5 minute slot regarding
fairness. If so, I will put discussion on the wiki.

Damien Saucez

On 22 Oct 2012, at 13:28, Börje Ohlman <[email-masked]> wrote:

> 	•
> 		• Proposed agenda items for ICNRG@IETF 85
> 			• Discussion ICNRG documents
> 			• Discussing who to deal with ICN deployment issues
> 				• Proposed inputs:
> 					•  http://www.psirp.org/files/Deliverables/FP7-INFSO-ICT-216173-PSIRP-D4.6_FinalReportOnDeplIncBusinessModels.pdf
> 					•  http://hal.inria.fr/docs/00/68/44/58/PDF/paper.pdf
> 			• Presentation of On the Content Retrieval In Information-Centric Network, http://datatracker.ietf.org/doc/draft-ren-icn-content-retrieval
> 			• ICN vs. CDN  http://tools.ietf.org/id/draft-fmn-cdni-advanced-use-cases-00.txt
> 			• Presentation of updates to Information-Centric Network in an ISP,  http://tools.ietf.org/html/draft-li-icnrg-icn-isp-01
> 			• Planning of interim meeting
> 
> 
>> 	• ICN Survey document
>> 		• A document that provides a survey of different approaches and techniques
>> 	• ICN Problem statement
>> 		• A document that describes the ICN problem statement, the main concepts and research challenges in depth.
>> 	• ICN Baseline Scenarios
>> 		• A document that defines reference baseline scenarios to enable performance comparisons between different approaches.
>> 	• http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg

---

From: Bengt Ahlgren <[email-masked]>
Date: Tue, 23 Oct 2012 21:39:41 +0200

I agree with Nacho, but would like to add an angle to this discussion!

CDN, IMO, is more a business model than a particular set of protocols
and services.  CDN operators agree to deliver the content of particular
publishers for a fee at some level of service.  Whether this is done on
an IP network or something else is not really important.

ICN is a different set of protocols and services compared to IP, but not
really a specific business model, although it may change the business
playing field somewhat.  So, even though we can argue that ICN is good
for content distribution, I don't think the CDN business becomes
redundant.  There will still be content publishers that want to make
sure that their content is delivered at some known level of service to
their customers.  The "normal" ICN caching simply corresponds to current
best-effort IP packet forwarding, with similar non-guarantee of service.

Having said that, when the CDN folks now are starting to define
particular protocols and interfaces (e.g., CDNI), they are working on
stuff that touches ICN, but for supporting their particular purpose (the
CDN business model).

Bengt

<[email-masked]> writes:

> Hi Brian.
>
> You are right that for a subset of cases it seems like ICN is just
> CDN, but that would be missing a lot of the picture.
>
> First, can you describe what the properties of native ICN and
> non-native ICN are?  Is there no "router caching" in non-native ICN?
>
> A few of the things that don't seem to fit into traditional CDNs (with
> my limited knowledge of state-of-the art CDNs) are:
>
> - Peer-to-peer.  How can CDNs help two nodes communicate without
> infrastructure?  If two nodes meet in the field (such as in the DARPA
> CBMEN program, or two phones on a plane or tunnel or ship), how can
> CDNs help them exchange information?
>
> - Lone hit. How can CDNs help distribute data that was previously
> unknown to the CDN. For example, from a random webpage.
>
>
> Granted, some of those are somewhat possible using CDNs. Some of those
> are possible with a little bit of work on CDNs and some are possible
> with a lot of work.
>
> Everything is possible.
>
> But, we're going to get to a point where we're changing so much that
> what we started with is unrecognizable.  Starting with CDNs is
> limiting what we can do and how we do it.  The model many ICNs take is
> a clean slate one. And as far as possible, we try to learn the lessons
> of CDNs, DTNs, IPs, Gnutellas, Multicast, RTPs, IPSecs, TCPs, DNSs,
> OSPFs, etc.
>
> Caching at the router level is one of the many potentially beneficial
> (but not-required) characteristics of ICNs.
>
> If we talk about a specific ICN architecture (like CCN) we can talk
> about specific advantages and disadvantages, tradeoffs made, work done
> so far, work planned and work yet to be done.
>
> Nacho
>
>
>
> --
> Nacho (Ignacio) Solis

---

From: Dae Young KIM <[email-masked]>
Date: Wed, 24 Oct 2012 07:47:31 +0900

Hi,

The ultimate criteria might be the level of incentive for end users,
content providers, and ISP's like:

  1. Are there any service differences perceived by the end users?
      o Any advantage/benefit perceived by the users?
      o Any strong incentive for end users to choose ICN against iCDN?

  2. Are there any differences perceived by the content providers?
      o Any strong incentive for content providers to choose ICN against
iCDN?

  3. Are there any incentive for the ISP's to provide the same content
delivery service by choosing the infrastructure of ICN against iCDN?

If the differential incentives are not strong enough, iCDN will only be a
pastime game.

On Wed, Oct 24, 2012 at 4:39 AM, Bengt Ahlgren <[email-masked]> wrote:

> >> Does anyone (beside me) think that a CDN effectively is already doing
> "ICN" but tunneled over an HTTP infrastructure (via HTTP/TCP/IP).   I think
> of CDN and native ICN (where the router is caching and forwarding at the
> ICN level) nearly identical forwarding paradigms just operating at
> different levels in the stack.
> >>
> >> There's work in standardizing the intra-CDN  and inter-CDN control plan
> (in CDN-I and elsewhere).  IMO, it would be useful if we had the same
> control protocol operating in both the CDN and ICN domains and the
> "transition" was just changing the layer at which forwarding occurred.
> >>
> >> Brian
> >>
> >>
> Of Will Liu (Shucheng)
> >> My group are also interested in ICN deployment and have done some
> survey on this matter. The discussion on ICN deployment is a great topic
> which ISPs will definitely be interested in. Here are our 2-cents.
> >>
> >> The evolvement of ICN may take the following three implementations:
> integrated with IP, over IP and over SDN. These strategies all can help the
> ISP shift from the traditional IP to ICN. The only question is which one is
> the best choice for large scale deployment?
> >>
> >> Integrated with IP strategy extends the existing IP protocol (IP
> option) to support ICN. The updated IP router, called content router, will
> deal with such special packets. However, many routers with no support of
> such extension may directly drop the packets with an unknown IP option.
> >>
> >> ICN over IP strategy uses an overlay approach. Content-related
> operation will be performed on the high layer and Content-related
> information will be sent through a tunnel. Due to the limited knowledge of
> physical topology and unnecessary packet encapsulation/disconsolation, the
> efficiency may be limited.
> >>
> >> ICN over SDN strategy exploits SDN controller to perform
> content-related operation. However, SDN itself is an ongoing approach and
> is typically used in a local domain. The performance in a large scale
> deployment is unknown.
> >>
> >> Will
> >>
> wiki.

-- 
DY

---

From: Spiros Spirou <[email-masked]>
Date: Wed, 24 Oct 2012 12:14:10 +0300

Hi Bengt!

If ICN does not provide any sort of better-than-best-effort delivery, 
then it seems (to me at least) that neither ISPs nor content providers 
have any significant incentive to adopt ICN. They can simply stick with 
the entrenched CDN technology and business model where all stekeholders 
(end-users, ISPs, CDN operators, and content providers/owners) seem to 
be happy enough.

If, on the other hand, ICN does provide guarantees in delivery, then ICN 
and CDN seem likely to become competitors, as they would be offering a 
very similar service. The question for me is why would ISPs risk losing 
existing revenue from CDN operators in favor of capital expenditure for 
deploying ICN? There's of course the hope that content providers would 
be lured away from CDN, but this seems realistic only if ICN is cheaper 
or somehow better than CDN.

Spiros

---

From: "David Lake (dlake)" <[email-masked]>
Date: Wed, 24 Oct 2012 10:13:00 +0000

Spiros

I completely agree, but I suspect we will need some kind of merging of ICN and SDN to achieve that. 

The comments from a few SPs at the World SDN/Openflow congress this week in Frankfurt was most enlightening - yes, there is revenue from the CDN providers, but there is also substantial operational cost and excessive complexity plus sub-optimal use of underlying network resources.

One aspect that was specifically called-out was the OTT CDN network.   Your phrase " seem to be happy enough" did not apply !!!!

Regards

David

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spiros Spirou
Sent: Wednesday, October 24, 2012 11:14 AM
To: Bengt Ahlgren
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [icnrg] Announcing ICNRG @ IETF 85

Hi Bengt!

If ICN does not provide any sort of better-than-best-effort delivery, then it seems (to me at least) that neither ISPs nor content providers have any significant incentive to adopt ICN. They can simply stick with the entrenched CDN technology and business model where all stekeholders (end-users, ISPs, CDN operators, and content providers/owners) seem to be happy enough.

If, on the other hand, ICN does provide guarantees in delivery, then ICN and CDN seem likely to become competitors, as they would be offering a very similar service. The question for me is why would ISPs risk losing existing revenue from CDN operators in favor of capital expenditure for deploying ICN? There's of course the hope that content providers would be lured away from CDN, but this seems realistic only if ICN is cheaper or somehow better than CDN.

Spiros

On 23/10/2012 10:39 μμ, Bengt Ahlgren wrote:
> and services.  CDN operators agree to deliver the content of 
> particular publishers for a fee at some level of service.  Whether 
> this is done on an IP network or something else is not really important.
>
> ICN is a different set of protocols and services compared to IP, but 
> not really a specific business model, although it may change the 
> business playing field somewhat.  So, even though we can argue that 
> ICN is good for content distribution, I don't think the CDN business 
> becomes redundant.  There will still be content publishers that want 
> to make sure that their content is delivered at some known level of 
> service to their customers.  The "normal" ICN caching simply 
> corresponds to current best-effort IP packet forwarding, with similar non-guarantee of service.
>
> stuff that touches ICN, but for supporting their particular purpose 
> (the CDN business model).
>
> Bengt
>
>> A few of the things that don't seem to fit into traditional CDNs 
>> (with my limited knowledge of state-of-the art CDNs) are:
>>
>> Granted, some of those are somewhat possible using CDNs. Some of 
>> those are possible with a little bit of work on CDNs and some are 
>> possible with a lot of work.
>>
>> Everything is possible.
>>
>> limiting what we can do and how we do it.  The model many ICNs take 
>> is a clean slate one. And as far as possible, we try to learn the 
>> lessons of CDNs, DTNs, IPs, Gnutellas, Multicast, RTPs, IPSecs, TCPs, 
>> DNSs, OSPFs, etc.
>>
>> about specific advantages and disadvantages, tradeoffs made, work 
>> done so far, work planned and work yet to be done.
>>
>> Nacho
>>
>>
>>
>> --
>> Nacho (Ignacio) Solis
>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>> Behalf Of B?rje Ohlman
>>>> migration issues are very important. I also agree that they don't 
>>>> seem like a good fit for any of the currently proposed ICNRG documents.
>>>>
>>>> The three documents listed as current work items are in no way set 
>>>> in stone, they should just be seen as a starting point for our 
>>>> work. If you would like to propose the RG that we should start 
>>>> working on a deployment document you are most welcome to do so, 
>>>> that will most certainly be in scope for our discussion in Atlanta.
>>>>
>>>> As a general comment I also like to mention that we as an RG are 
>>>> not bound by all the rules that apply to IETF WGs, e.g. we are free 
>>>> to discuss late contributions produced after the IETF draft 
>>>> deadlines. So if people find the time to write up some material for 
>>>> the ICNRG after the IETF drafts are done they are welcome to 
>>>> announce it to the ICNRG mailing list. If the group agrees we are 
>>>> free to discuss also such material at our meeting,
>>>>
>>>>      BΓ¶rje
>>>>
>>>>> provided ISPs a ladder out of dumb-pipes, ISPs may have 
>>>>> difficulties on clean-slate approaches of ICN.
>>>>> IMHO, based on our surveys on ISP R&D approaches to ICN, Korean 
>>>>> ISPs are in the similar situation.
>>>>>
>>>>>> technical topics at the meeting. Proposals for such topics as 
>>>>>> well as presentations are invited.
>>>>>>

---

From: <[email-masked]>
Date: Wed, 24 Oct 2012 15:56:03 +0000

"Best-effort" for some ICNs has different characteristics that IP best-effort, so comparing it directly might not be accurate.   For all we know ICNs best-effort is better-than-IP-best-effort.

I don't think that everybody is happy-enough, after all, everybody wants to be happier.

I think the points I made are still unanswered.  It's probably true that many of those are not the biggest pain points for ISPs, but ISPs are not the only stakeholders (device manufacturers? IoT companies? OS vendors? open source projects? Companies that don't want to depend on others to provide CDN like service and need to build their own? Internal enterprise services? Datacenter communications?)

Finally, as stated by others, I don't think there is a direct competition between ICN and CDNs.  One is a set of protocols and the other is a service/business model.  The functions provided by CDNs are still needed in a world with ICN.  Content providers will still require help distributing their content, pre-placing it, monitoring it, accounting for usage, storing it.  Part of this can be done by a CDN-company directly. Another part can potentially be brokered via a CDN. CDNs could potentially buy ICN-storage from ISPs and resell to clients as they see fit.  ISPs could provide APIs, storage and certain guarantees to CNDs.  (Yes, yes, I'm waving my hands through net neutrality issues). 

We don't know what the world could look like because we haven't finished developing the ICN architectures and protocols.  Maybe this is not the right model.

I'm not sure what your definition of guarantees in delivery is, but under some definition TCP would also fit and it doesn't compete. Also, why would ISPs risk loosing revenue by not selling potential ICN services to CDNs and others?

Nacho

---

From: Ioannis Psaras <[email-masked]>
Date: Wed, 24 Oct 2012 16:58:17 +0100

Hi Spiros,

I don't think ICN (caching in particular) and the CDN model have conflicting goals: there is (and will always be) a need for permanently storing content. Whether performance can improve due to caching is a different discussion IMO and not necessarily in the interest of CDNs. This is (part of) the reason why we have CDNs anyway - otherwise ISPs could deploy their own servers/CDNs (which they do to an extend, but always within their own domain).

ICN (caching) may improve performance and this is where ISPs should focus on to see whether it's good/profitable for them to deploy.

Regards,
Yiannis.

---

From: Damien Saucez <[email-masked]>
Date: Wed, 24 Oct 2012 22:41:16 +0200

Hello,

> "Best-effort" for some ICNs has different characteristics that IP best-effort, so comparing it directly might not be accurate.   For all we know ICNs best-effort is better-than-IP-best-effort.

How do you define better-than? What is the metric? Which criterion?

Thank you in advance for the clarification.

Damien Saucez

---

From: <[email-masked]>
Date: Wed, 24 Oct 2012 21:14:54 +0000

> Thank you in advance for the clarification.

That is exactly my question, we haven't defined that.

How is multicast best-effort different than non-multicast best effort?  You can't compare easily.  This was exactly my point to the critique of:  "If ICN does not provide any sort of better-than-best-effort delivery, then it seems (to me at least) that neither ISPs nor content providers have any significant incentive to adopt ICN." that Spiros brought up. I was commenting on the better-than-best-effort qualification.

I could construct scenarios where best effort ICN (CCN in my example) can achieve better-than-IP-best-effort for delivery, delay and availability.  I could also construct scenarios where IP might have less overhead. I was just pointing out that comparing "best-efforts" in a general is not trivial.

ICN is still a research topic. It doesn't have all the answers and there are many open questions. Yes, there is some overlap with CDNs, but they are not in direct competition.

Nacho

---

From: Börje Ohlman <[email-masked]>
Date: Thu, 25 Oct 2012 10:00:53 +0200

Some comments on this discussion. It is clearly important to define metrics for comparing the how efficiently content can be distributed using different solutions. We should make sure to do it in such a way, that in addition to compare a specific ICN technology with existing CDN solutions, we are also able to compare different ICN solutions with each other. That is what we are aiming for with the 'ICN Baseline Scenarios' document.

A second comment is that, even if providing inherent CDN functionality is a key feature of ICN, I don't think it is the most important feature of ICN. To me the idea of an application independent naming scheme for information/data objects bears even greater potential, especially for application developers that more easily can reuse information bases from one application to another. Also having the pub/sub like API to ICN opens the door to include a lot of nice features into the network in a way that is transparent to the application developers. Examples of such features include p2p-functionality, seamless mobility, DTN-functionality, ...

	Börje

---

From: David R Oran <[email-masked]>
Date: Sat, 27 Oct 2012 10:41:29 -0400

On Oct 24, 2012, at 11:58 AM, Ioannis Psaras <[email-masked]> wrote:

> Hi Spiros,
> 
> I don't think ICN (caching in particular) and the CDN model have conflicting goals: there is (and will always be) a need for permanently storing content.
Please define "permanent".

> Whether performance can improve due to caching is a different discussion IMO and not necessarily in the interest of CDNs. This is (part of) the reason why we have CDNs anyway - otherwise ISPs could deploy their own servers/CDNs (which they do to an extend, but always within their own domain).
> 
ICN ≠ caching

---

From: "David Lake (dlake)" <[email-masked]>
Date: Sat, 27 Oct 2012 14:46:22 +0000

Please correct me if I'm wrong, but I thought that ICN was to do with a new way of locating content and the distribution mechanism associated with that, not content storage ?

David

Sent from my iPhone

---

From: David R Oran <[email-masked]>
Date: Sat, 27 Oct 2012 10:48:21 -0400

Some definitions that might be pertinent to the discussion:

"Best Effort" - up to a higher level to decide if something worked or not. It is not a measure of relative quality of a service compared to a service which claims to have stronger semantics.

"Guaranteed delivery" - a service which makes more than minimal effort to tell you when it is broken. It is not a measure of actually working any better than a service with weaker semantics.

DaveO.

---

From: Ioannis Psaras <[email-masked]>
Date: Sun, 28 Oct 2012 22:48:07 +0000

Hi David,

> Please define "permanent".

I mean a CDN-like service.

Caching cannot guarantee that something will be found after some time in that place. Permanent storage guarantees that content will be there until some other agreement is made between the storage provider (CDN in this case) and the content provider.

>> ICN (caching) may improve performance and this is where ISPs should focus on to see whether it's good/profitable for them to deploy.

Absolutely!

Regards,
Yiannis.