Subject: [icnrg] test -- do not reply

From: Dirk Kutscher <[email-masked]>
Date: Mon, 23 Apr 2012 17:03:51 +0000

Testing...

--
Dirk

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 24 Apr 2012 01:05:35 +0800

test

-----原始邮件----- 
From: Dirk Kutscher
Sent: Tuesday, April 24, 2012 1:03 AM
To: [email-masked]
Subject: [icnrg] test -- do not reply

Testing...

--
Dirk
_______________________________________________
icnrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/icnrg 

From: paulo.mendes at ulusofona.pt (Paulo Mendes)
Date: Wed, 18 Apr 2012 10:29:56 +0100
Subject: [Icn-interest] Updated charter text for proposed IRTF ICNRG
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Dave

I agree with your suggestion to update the charter. As for the objectives section, IMO that does not need to be changed.

Paulo

On Apr 14, 2012, at 1:35 PM, Dave Oran (oran) wrote:

> 
> On Apr 13, 2012, at 11:47 AM, Paulo Mendes wrote:
> 
>> Hello
>> 
>> I do not see the need to go into details here, since cache strategies (as mentioned in the charter) need for sure to be about in-network caching and coordination of caches... If it was only about node dependent cache strategies, we will not need to have  any standard method.
>> 
>> But just to make it clear, I also agree that cooperation/coordination about in-network caches is a major issue for standardization :)
>> 
> I'm happy to somewhat expand the scope on caching as long as we remain focused on ICN-related aspects and don't wander off into generic cache management research, for example things that are in the scope of CDNI, or are generic to any data caching schemes such as we see with today's web caching designs.
> 
> This will be a tricky line to walk, but trying to nail down the line in the charter is even trickier and likely to be a waste of time and energy.
> 
> That said, I like your suggested wording pretty much.
> 
> How about we expand the relevant paragraph in the research challenges section a bit, to say:
> 
> "Accessing copies of named content enables new data transport concepts, such as receiver-oriented (pull-based) transport protocols. Caches in the network may play an active role in transport sessions, enabling shorter feedback loops and specific transport protocol features in challenged networks, quite different from end-to-end transport as in TCP today. Leveraging the existence of multiple copies of each object enables new transport strategies such as parallel interaction with multiple caches. ICN may provide opportunities for better cache coordination and global management of the storage resources of multiple caches. On the other hand, once a named data object exists in multiple caches, consistent and coherent update semantics and supporting protocols have to be defined, dealing with, e.g., multiple writers updating a named object at the time when only connected via a challenged network.
> 
> I'm not sure it's necessary to expand the objectives section, as it basically refers back the research challenges section while initially focusing the group on a particular subset of the research challenges, one of which is caching.
> 
> DaveO.
> 
>> Paulo
>> 
>> On Apr 13, 2012, at 1:56 PM, Diego Perino wrote:
>> 
>>> Dear all,
>>> 
>>> I went through the charter and I have some comments, especially related to the caching part.
>>> 
>>> 1) in the "Research challenges" section, where caching is mentioned, the focus is mostly on the interaction of caching with transport and routing. These are surely key issues, but I would also put some emphasis on problems related to caching strategies themselves, as one of the main research areas of the RG mentioned in the charter is "caching strategies". I would add a couple of sentences dealing with ICN specific caching issues, and more specifically related to problems that could require standardization. For instance, we could mention the need of mechanisms to coordinate caches in a network, or schemes to manage storage resources at network level by combining replication/caching techniques at different nodes.
>>> 
>>> 2) in the "ICNRG objectives" section I would slightly modify the "caching strategies" item, in order to be more consistent with the rest of the charter. We could talk more about in-network caching and replication, and add the interaction with transport and routing that are relevant and can require some standardization.
>>> 
>>> Best Regards,
>>> Diego
>>> 
>>> 
>>> 
>>> On 10/04/2012 14:07, Dirk Kutscher wrote:
>>>> Dear all,
>>>> 
>>>> Thanks again for your interest in the ICN side meeting at IETF-83 and the constructive suggestions for the ICNRG charter.
>>>> 
>>>> Based on your input B?rje, Dave and I have edited the draft charter, specifically with regard to:
>>>> 
>>>> - put emphasis on continuous activities with relevance to Internet evolution (to avoid becoming a home for rejected workshop papers ;-)
>>>> - explicitly mentioned two first initial topic areas (name resolution&  routing scalability and caching strategies)
>>>> -  included reference baseline scenarios for performance comparison&  information sharing on initial deployments
>>>> - clarified relationship to possibly related IETF groups (avoiding overlap, but ensuring information exchange)
>>>> - some shortening
>>>> 
>>>> The updated charter text available athttp://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg
>>>> 
>>>> We invite interested people to review this and share their comments. Please let us have your comments before 2012-04-14 EOB PDT.
>>>> 
>>>> Thanks,
>>>> B?rje, Dave, Dirk
>>>> 
>>>> --
>>>> Dr. Dirk Kutscher | NEC Laboratories Europe
>>>> phone: +49 6221 4342 203 | fax: +49 6221 4342 155 | webpage:www.neclab.eu
>>>> 
>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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
>> 
>> -------------------------------------------------------------
>> Paulo Mendes, Ph.D
>> Scientific Director for Innovation of the Research Unit in Informatics Systems and Technologies (SITI)
>> Coordinator of the Internet Architecture and Networking Lab (IAN Lab)
>> Secretary of the ACM SIGCOMM Chapter - Portugal
>> University Lusofona, Portugal
>> paulo.mendes at ulusofona.pt
>> http://siti.ulusofona.pt/~pmendes
>> Tel.: 217 515 500 Fax: 21 757 7006
>> 
> 

-------------------------------------------------------------
Paulo Mendes, Ph.D
Scientific Director for Innovation of the Research Unit in Informatics Systems and Technologies (SITI)
Coordinator of the Internet Architecture and Networking Lab (IAN Lab)
Secretary of the ACM SIGCOMM Chapter - Portugal
University Lusofona, Portugal
paulo.mendes at ulusofona.pt
http://siti.ulusofona.pt/~pmendes
Tel.: 217 515 500 Fax: 21 757 7006

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120418/5133382e/attachment-0001.html>

From: diego.perino at alcatel-lucent.com (Diego Perino)
Date: Mon, 16 Apr 2012 14:48:54 +0200
Subject: [Icn-interest] Updated charter text for proposed IRTF ICNRG
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello,

I agree to expand the caching paragraph as you suggested.
As concern the objectives section we can probably just slightly modify 
it to "Storage management strategies and corresponding performance 
optimizations". And then this objective refers back to the related 
paragraph.

Best Regards,
Diego

On 14/04/2012 14:39, David R Oran wrote:
>
> On Apr 13, 2012, at 11:47 AM, Paulo Mendes wrote:
>
>> Hello
>>
>> I do not see the need to go into details here, since cache strategies 
>> (as mentioned in the charter) need for sure to be about in-network 
>> caching and coordination of caches... If it was only about node 
>> dependent cache strategies, we will not need to have any standard method.
>>
>> But just to make it clear, I also agree that cooperation/coordination 
>> about in-network caches is a major issue for standardization :)
>>
> I'm happy to somewhat expand the scope on caching as long as we remain 
> focused on ICN-related aspects and don't wander off into generic cache 
> management research, for example things that are in the scope of CDNI, 
> or are generic to any data caching schemes such as we see with today's 
> web caching designs.
>
> This will be a tricky line to walk, but trying to nail down the line 
> in the charter is even trickier and likely to be a waste of time and 
> energy.
>
> That said, I like your suggested wording pretty much.
>
> How about we expand the relevant paragraph in the research challenges 
> section a bit, to say:
>
> "Accessing copies of named content enables new data transport 
> concepts, such as receiver-oriented (pull-based) transport protocols. 
> Caches in the network may play an active role in transport sessions, 
> enabling shorter feedback loops and specific transport protocol 
> features in challenged networks, quite different from end-to-end 
> transport as in TCP today. Leveraging the existence of multiple copies 
> of each object enables new transport strategies such as parallel 
> interaction with multiple caches. ICN may provide opportunities for 
> better cache coordination and global management of the storage 
> resources of multiple caches. On the other hand, once a named data 
> object exists in multiple caches, consistent and coherent update 
> semantics and supporting protocols have to be defined, dealing with, 
> e.g., multiple writers updating a named object at the time when only 
> connected via a challenged network.
>
> I'm not sure it's necessary to expand the objectives section, as it 
> basically refers back the research challenges section while initially 
> focusing the group on a particular subset of the research challenges, 
> one of which is caching.
>
> DaveO.
>
>> Paulo
>>
>> On Apr 13, 2012, at 1:56 PM, Diego Perino wrote:
>>
>>> Dear all,
>>>
>>> I went through the charter and I have some comments, especially 
>>> related to the caching part.
>>>
>>> 1) in the "Research challenges" section, where caching is mentioned, 
>>> the focus is mostly on the interaction of caching with transport and 
>>> routing. These are surely key issues, but I would also put some 
>>> emphasis on problems related to caching strategies themselves, as 
>>> one of the main research areas of the RG mentioned in the charter is 
>>> "caching strategies". I would add a couple of sentences dealing with 
>>> ICN specific caching issues, and more specifically related to 
>>> problems that could require standardization. For instance, we could 
>>> mention the need of mechanisms to coordinate caches in a network, or 
>>> schemes to manage storage resources at network level by combining 
>>> replication/caching techniques at different nodes.
>>>
>>> 2) in the "ICNRG objectives" section I would slightly modify the 
>>> "caching strategies" item, in order to be more consistent with the 
>>> rest of the charter. We could talk more about in-network caching and 
>>> replication, and add the interaction with transport and routing that 
>>> are relevant and can require some standardization.
>>>
>>> Best Regards,
>>> Diego
>>>
>>>
>>>
>>> On 10/04/2012 14:07, Dirk Kutscher wrote:
>>>> Dear all,
>>>>
>>>> Thanks again for your interest in the ICN side meeting at IETF-83 
>>>> and the constructive suggestions for the ICNRG charter.
>>>>
>>>> Based on your input B?rje, Dave and I have edited the draft 
>>>> charter, specifically with regard to:
>>>>
>>>> - put emphasis on continuous activities with relevance to Internet 
>>>> evolution (to avoid becoming a home for rejected workshop papers ;-)
>>>> - explicitly mentioned two first initial topic areas (name 
>>>> resolution&  routing scalability and caching strategies)
>>>> -  included reference baseline scenarios for performance 
>>>> comparison&  information sharing on initial deployments
>>>> - clarified relationship to possibly related IETF groups (avoiding 
>>>> overlap, but ensuring information exchange)
>>>> - some shortening
>>>>
>>>> The updated charter text available 
>>>> athttp://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg
>>>>
>>>> We invite interested people to review this and share their 
>>>> comments. Please let us have your comments before 2012-04-14 EOB PDT.
>>>>
>>>> Thanks,
>>>> B?rje, Dave, Dirk
>>>>
>>>> --
>>>> Dr. Dirk Kutscher | NEC Laboratories Europe
>>>> phone: +49 6221 4342 203 | fax: +49 6221 4342 155 | 
>>>> webpage:www.neclab.eu
>>>>
>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, 
>>>> London W3 6BL | Registered in England 2832014
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> -------------------------------------------------------------
>> Paulo Mendes, Ph.D
>> Scientific Director for Innovation of the Research Unit in 
>> Informatics Systems and Technologies (SITI)
>> Coordinator of the Internet Architecture and Networking Lab (IAN Lab)
>> Secretary of the ACM SIGCOMM Chapter - Portugal
>> University Lusofona, Portugal
>> paulo.mendes at ulusofona.pt <mailto:paulo.mendes at ulusofona.pt>
>> http://siti.ulusofona.pt/~pmendes <http://siti.ulusofona.pt/%7Epmendes>
>> Tel.: 217 515 500 Fax: 21 757 7006
>>
>

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

From: daveoran at orandom.net (David R Oran)
Date: Sat, 14 Apr 2012 08:39:38 -0400
Subject: [Icn-interest] Updated charter text for proposed IRTF ICNRG
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Apr 13, 2012, at 11:47 AM, Paulo Mendes wrote:

> Hello
> 
> I do not see the need to go into details here, since cache strategies (as mentioned in the charter) need for sure to be about in-network caching and coordination of caches... If it was only about node dependent cache strategies, we will not need to have any standard method.
> 
> But just to make it clear, I also agree that cooperation/coordination about in-network caches is a major issue for standardization :)
> 
I'm happy to somewhat expand the scope on caching as long as we remain focused on ICN-related aspects and don't wander off into generic cache management research, for example things that are in the scope of CDNI, or are generic to any data caching schemes such as we see with today's web caching designs.

This will be a tricky line to walk, but trying to nail down the line in the charter is even trickier and likely to be a waste of time and energy.

That said, I like your suggested wording pretty much.

How about we expand the relevant paragraph in the research challenges section a bit, to say:

"Accessing copies of named content enables new data transport concepts, such as receiver-oriented (pull-based) transport protocols. Caches in the network may play an active role in transport sessions, enabling shorter feedback loops and specific transport protocol features in challenged networks, quite different from end-to-end transport as in TCP today. Leveraging the existence of multiple copies of each object enables new transport strategies such as parallel interaction with multiple caches. ICN may provide opportunities for better cache coordination and global management of the storage resources of multiple caches. On the other hand, once a named data object exists in multiple caches, consistent and coherent update semantics and supporting protocols have to be defined, dealing with, e.g., multiple writers updating a named object at the time when only connected via a challenged network.

I'm not sure it's necessary to expand the objectives section, as it basically refers back the research challenges section while initially focusing the group on a particular subset of the research challenges, one of which is caching.

DaveO.

> Paulo
> 
> On Apr 13, 2012, at 1:56 PM, Diego Perino wrote:
> 
>> Dear all,
>> 
>> I went through the charter and I have some comments, especially related to the caching part.
>> 
>> 1) in the "Research challenges" section, where caching is mentioned, the focus is mostly on the interaction of caching with transport and routing. These are surely key issues, but I would also put some emphasis on problems related to caching strategies themselves, as one of the main research areas of the RG mentioned in the charter is "caching strategies". I would add a couple of sentences dealing with ICN specific caching issues, and more specifically related to problems that could require standardization. For instance, we could mention the need of mechanisms to coordinate caches in a network, or schemes to manage storage resources at network level by combining replication/caching techniques at different nodes.
>> 
>> 2) in the "ICNRG objectives" section I would slightly modify the "caching strategies" item, in order to be more consistent with the rest of the charter. We could talk more about in-network caching and replication, and add the interaction with transport and routing that are relevant and can require some standardization.
>> 
>> Best Regards,
>> Diego
>> 
>> 
>> 
>> On 10/04/2012 14:07, Dirk Kutscher wrote:
>>> Dear all,
>>> 
>>> Thanks again for your interest in the ICN side meeting at IETF-83 and the constructive suggestions for the ICNRG charter.
>>> 
>>> Based on your input B?rje, Dave and I have edited the draft charter, specifically with regard to:
>>> 
>>> - put emphasis on continuous activities with relevance to Internet evolution (to avoid becoming a home for rejected workshop papers ;-)
>>> - explicitly mentioned two first initial topic areas (name resolution&  routing scalability and caching strategies)
>>> -  included reference baseline scenarios for performance comparison&  information sharing on initial deployments
>>> - clarified relationship to possibly related IETF groups (avoiding overlap, but ensuring information exchange)
>>> - some shortening
>>> 
>>> The updated charter text available athttp://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg
>>> 
>>> We invite interested people to review this and share their comments. Please let us have your comments before 2012-04-14 EOB PDT.
>>> 
>>> Thanks,
>>> B?rje, Dave, Dirk
>>> 
>>> --
>>> Dr. Dirk Kutscher | NEC Laboratories Europe
>>> phone: +49 6221 4342 203 | fax: +49 6221 4342 155 | webpage:www.neclab.eu
>>> 
>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> -------------------------------------------------------------
> Paulo Mendes, Ph.D
> Scientific Director for Innovation of the Research Unit in Informatics Systems and Technologies (SITI)
> Coordinator of the Internet Architecture and Networking Lab (IAN Lab)
> Secretary of the ACM SIGCOMM Chapter - Portugal
> University Lusofona, Portugal
> paulo.mendes at ulusofona.pt
> http://siti.ulusofona.pt/~pmendes
> Tel.: 217 515 500 Fax: 21 757 7006
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120414/7c2693b7/attachment.html>

From: paulo.mendes at ulusofona.pt (Paulo Mendes)
Date: Fri, 13 Apr 2012 16:47:35 +0100
Subject: [Icn-interest] Updated charter text for proposed IRTF ICNRG
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Lars

This "all related topics by default" for IRTF is clear, but if I was one of the RG chair, besides a charter that would allow me to defend the need to have the RG in relation to other, I would like to have a charter that will point out to some major topics in order to keep the work focus to reach results as soon as possible (it is not motivating to see a RG just as a repository of articles/technical reports/ draft related to the topic).

So, I would make it clear the "all related topics by default" policy and I would identify the major topics that are expected to produce the first results (input for IETF?). 

In this sense I think that the charter is clear, giving examples of ICN related issues and pointing out to two major topics.

Paulo

On Apr 13, 2012, at 3:32 PM, Eggert, Lars wrote:

> On Apr 13, 2012, at 15:52, Stephen Farrell wrote:
>> I would assume the charter is to guide whoever ends up as RG
>> chairs, in case there's overlap with other potential RGs, and
>> to help attract more good input, and is much less of a
>> scope-limiting text. (This not being an IETF WG.)
> 
> +1
> 
> Unless the charter specifically highlights topics as out-of-scope, participants should assume that an ICN topic is *in* scope. We can't enumerate what's in scope like we often do it on the IETF side, because this is research and we don't know a priori.
> 
> Lars_______________________________________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

-------------------------------------------------------------
Paulo Mendes, Ph.D
Scientific Director for Innovation of the Research Unit in Informatics Systems and Technologies (SITI)
Coordinator of the Internet Architecture and Networking Lab (IAN Lab)
Secretary of the ACM SIGCOMM Chapter - Portugal
University Lusofona, Portugal
paulo.mendes at ulusofona.pt
http://siti.ulusofona.pt/~pmendes
Tel.: 217 515 500 Fax: 21 757 7006

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120413/3fbb28d9/attachment-0001.html>

From: paulo.mendes at ulusofona.pt (Paulo Mendes)
Date: Fri, 13 Apr 2012 16:47:16 +0100
Subject: [Icn-interest] Updated charter text for proposed IRTF ICNRG
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello

I do not see the need to go into details here, since cache strategies (as mentioned in the charter) need for sure to be about in-network caching and coordination of caches... If it was only about node dependent cache strategies, we will not need to have any standard method.

But just to make it clear, I also agree that cooperation/coordination about in-network caches is a major issue for standardization :)

Paulo

On Apr 13, 2012, at 1:56 PM, Diego Perino wrote:

> Dear all,
> 
> I went through the charter and I have some comments, especially related to the caching part.
> 
> 1) in the "Research challenges" section, where caching is mentioned, the focus is mostly on the interaction of caching with transport and routing. These are surely key issues, but I would also put some emphasis on problems related to caching strategies themselves, as one of the main research areas of the RG mentioned in the charter is "caching strategies". I would add a couple of sentences dealing with ICN specific caching issues, and more specifically related to problems that could require standardization. For instance, we could mention the need of mechanisms to coordinate caches in a network, or schemes to manage storage resources at network level by combining replication/caching techniques at different nodes.
> 
> 2) in the "ICNRG objectives" section I would slightly modify the "caching strategies" item, in order to be more consistent with the rest of the charter. We could talk more about in-network caching and replication, and add the interaction with transport and routing that are relevant and can require some standardization.
> 
> Best Regards,
> Diego
> 
> 
> 
> On 10/04/2012 14:07, Dirk Kutscher wrote:
>> Dear all,
>> 
>> Thanks again for your interest in the ICN side meeting at IETF-83 and the constructive suggestions for the ICNRG charter.
>> 
>> Based on your input B?rje, Dave and I have edited the draft charter, specifically with regard to:
>> 
>> - put emphasis on continuous activities with relevance to Internet evolution (to avoid becoming a home for rejected workshop papers ;-)
>> - explicitly mentioned two first initial topic areas (name resolution&  routing scalability and caching strategies)
>> -  included reference baseline scenarios for performance comparison&  information sharing on initial deployments
>> - clarified relationship to possibly related IETF groups (avoiding overlap, but ensuring information exchange)
>> - some shortening
>> 
>> The updated charter text available athttp://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg
>> 
>> We invite interested people to review this and share their comments. Please let us have your comments before 2012-04-14 EOB PDT.
>> 
>> Thanks,
>> B?rje, Dave, Dirk
>> 
>> --
>> Dr. Dirk Kutscher | NEC Laboratories Europe
>> phone: +49 6221 4342 203 | fax: +49 6221 4342 155 | webpage:www.neclab.eu
>> 
>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
>> 
>> 
>> _______________________________________________
>> 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

-------------------------------------------------------------
Paulo Mendes, Ph.D
Scientific Director for Innovation of the Research Unit in Informatics Systems and Technologies (SITI)
Coordinator of the Internet Architecture and Networking Lab (IAN Lab)
Secretary of the ACM SIGCOMM Chapter - Portugal
University Lusofona, Portugal
paulo.mendes at ulusofona.pt
http://siti.ulusofona.pt/~pmendes
Tel.: 217 515 500 Fax: 21 757 7006

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120413/1840ff36/attachment.html>

From: lars at netapp.com (Eggert, Lars)
Date: Fri, 13 Apr 2012 14:32:33 +0000
Subject: [Icn-interest] Updated charter text for proposed IRTF ICNRG
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Apr 13, 2012, at 15:52, Stephen Farrell wrote:
> I would assume the charter is to guide whoever ends up as RG
> chairs, in case there's overlap with other potential RGs, and
> to help attract more good input, and is much less of a
> scope-limiting text. (This not being an IETF WG.)

+1

Unless the charter specifically highlights topics as out-of-scope, participants should assume that an ICN topic is *in* scope. We can't enumerate what's in scope like we often do it on the IETF side, because this is research and we don't know a priori.

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4361 bytes
Desc: not available
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120413/aabb82bc/attachment-0001.bin>

From: ashokn at cisco.com (Ashok Narayanan)
Date: Fri, 13 Apr 2012 10:04:46 -0400
Subject: [Icn-interest] Updated charter text for proposed IRTF ICNRG
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I'm sold.

-Ashok

On Apr 13, 2012, at 4/13 9:52 AM, Stephen Farrell wrote:

> 
> Hi,
> 
> (Not really related to Ashok's mail directly, but more to
> the general charter-text wordsmithing...)
> 
> I'm not sure I get the concern here. Is there really an intent
> to say to people "hey, that ICN stuff of yours is not mentioned
> in the charter so go away"?
> 
> I would assume the charter is to guide whoever ends up as RG
> chairs, in case there's overlap with other potential RGs, and
> to help attract more good input, and is much less of a
> scope-limiting text. (This not being an IETF WG.)
> 
> As I said at the Paris lunchtime slot, the DTNRG charter must
> be an incredibly dusty piece of digital text because we never
> really look at it, nor have we needed to that I recall over
> the last 7 or 8 years or however long its been. To be fair,
> ICN is closer to the market, so the same might not apply, but
> I don't think we need a perfect charter to have a great ICNRG.
> 
> S.
> 
> On 04/13/2012 02:26 PM, Ashok Narayanan wrote:
>> The concern here is whether this RG is formed for _routing_ related investigations into ICN (as an arm of IRTF) or _general_ investigation into ICN. Local or global caching strategies seems like something of great interest to ICN but perhaps peripheral interest to ICN routing.
>> 
>> -Ashok
>> 
>> On Apr 13, 2012, at 4/13 8:56 AM, Diego Perino wrote:
>> 
>>> Dear all,
>>> 
>>> I went through the charter and I have some comments, especially related to the caching part.
>>> 
>>> 1) in the "Research challenges" section, where caching is mentioned, the focus is mostly on the interaction of caching with transport and routing. These are surely key issues, but I would also put some emphasis on problems related to caching strategies themselves, as one of the main research areas of the RG mentioned in the charter is "caching strategies". I would add a couple of sentences dealing with ICN specific caching issues, and more specifically related to problems that could require standardization. For instance, we could mention the need of mechanisms to coordinate caches in a network, or schemes to manage storage resources at network level by combining replication/caching techniques at different nodes.
>>> 
>>> 2) in the "ICNRG objectives" section I would slightly modify the "caching strategies" item, in order to be more consistent with the rest of the charter. We could talk more about in-network caching and replication, and add the interaction with transport and routing that are relevant and can require some standardization.
>>> 
>>> Best Regards,
>>> Diego
>>> 
>>> 
>>> 
>>> On 10/04/2012 14:07, Dirk Kutscher wrote:
>>>> Dear all,
>>>> 
>>>> Thanks again for your interest in the ICN side meeting at IETF-83 and the constructive suggestions for the ICNRG charter.
>>>> 
>>>> Based on your input B?rje, Dave and I have edited the draft charter, specifically with regard to:
>>>> 
>>>> - put emphasis on continuous activities with relevance to Internet evolution (to avoid becoming a home for rejected workshop papers ;-)
>>>> - explicitly mentioned two first initial topic areas (name resolution&  routing scalability and caching strategies)
>>>> -  included reference baseline scenarios for performance comparison&  information sharing on initial deployments
>>>> - clarified relationship to possibly related IETF groups (avoiding overlap, but ensuring information exchange)
>>>> - some shortening
>>>> 
>>>> The updated charter text available athttp://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg
>>>> 
>>>> We invite interested people to review this and share their comments. Please let us have your comments before 2012-04-14 EOB PDT.
>>>> 
>>>> Thanks,
>>>> B?rje, Dave, Dirk
>>>> 
>>>> --
>>>> Dr. Dirk Kutscher | NEC Laboratories Europe
>>>> phone: +49 6221 4342 203 | fax: +49 6221 4342 155 | webpage:www.neclab.eu
>>>> 
>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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
>> 
> _______________________________________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

From: stephen.farrell at cs.tcd.ie (Stephen Farrell)
Date: Fri, 13 Apr 2012 14:52:46 +0100
Subject: [Icn-interest] Updated charter text for proposed IRTF ICNRG
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

(Not really related to Ashok's mail directly, but more to
the general charter-text wordsmithing...)

I'm not sure I get the concern here. Is there really an intent
to say to people "hey, that ICN stuff of yours is not mentioned
in the charter so go away"?

I would assume the charter is to guide whoever ends up as RG
chairs, in case there's overlap with other potential RGs, and
to help attract more good input, and is much less of a
scope-limiting text. (This not being an IETF WG.)

As I said at the Paris lunchtime slot, the DTNRG charter must
be an incredibly dusty piece of digital text because we never
really look at it, nor have we needed to that I recall over
the last 7 or 8 years or however long its been. To be fair,
ICN is closer to the market, so the same might not apply, but
I don't think we need a perfect charter to have a great ICNRG.

S.

On 04/13/2012 02:26 PM, Ashok Narayanan wrote:
> The concern here is whether this RG is formed for _routing_ related investigations into ICN (as an arm of IRTF) or _general_ investigation into ICN. Local or global caching strategies seems like something of great interest to ICN but perhaps peripheral interest to ICN routing.
> 
> -Ashok
> 
> On Apr 13, 2012, at 4/13 8:56 AM, Diego Perino wrote:
> 
>> Dear all,
>>
>> I went through the charter and I have some comments, especially related to the caching part.
>>
>> 1) in the "Research challenges" section, where caching is mentioned, the focus is mostly on the interaction of caching with transport and routing. These are surely key issues, but I would also put some emphasis on problems related to caching strategies themselves, as one of the main research areas of the RG mentioned in the charter is "caching strategies". I would add a couple of sentences dealing with ICN specific caching issues, and more specifically related to problems that could require standardization. For instance, we could mention the need of mechanisms to coordinate caches in a network, or schemes to manage storage resources at network level by combining replication/caching techniques at different nodes.
>>
>> 2) in the "ICNRG objectives" section I would slightly modify the "caching strategies" item, in order to be more consistent with the rest of the charter. We could talk more about in-network caching and replication, and add the interaction with transport and routing that are relevant and can require some standardization.
>>
>> Best Regards,
>> Diego
>>
>>
>>
>> On 10/04/2012 14:07, Dirk Kutscher wrote:
>>> Dear all,
>>>
>>> Thanks again for your interest in the ICN side meeting at IETF-83 and the constructive suggestions for the ICNRG charter.
>>>
>>> Based on your input B?rje, Dave and I have edited the draft charter, specifically with regard to:
>>>
>>> - put emphasis on continuous activities with relevance to Internet evolution (to avoid becoming a home for rejected workshop papers ;-)
>>> - explicitly mentioned two first initial topic areas (name resolution&  routing scalability and caching strategies)
>>> -  included reference baseline scenarios for performance comparison&  information sharing on initial deployments
>>> - clarified relationship to possibly related IETF groups (avoiding overlap, but ensuring information exchange)
>>> - some shortening
>>>
>>> The updated charter text available athttp://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg
>>>
>>> We invite interested people to review this and share their comments. Please let us have your comments before 2012-04-14 EOB PDT.
>>>
>>> Thanks,
>>> B?rje, Dave, Dirk
>>>
>>> --
>>> Dr. Dirk Kutscher | NEC Laboratories Europe
>>> phone: +49 6221 4342 203 | fax: +49 6221 4342 155 | webpage:www.neclab.eu
>>>
>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
>>>
>>>
>>> _______________________________________________
>>> 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
> 

From: ashokn at cisco.com (Ashok Narayanan)
Date: Fri, 13 Apr 2012 09:26:49 -0400
Subject: [Icn-interest] Updated charter text for proposed IRTF ICNRG
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

The concern here is whether this RG is formed for _routing_ related investigations into ICN (as an arm of IRTF) or _general_ investigation into ICN. Local or global caching strategies seems like something of great interest to ICN but perhaps peripheral interest to ICN routing.

-Ashok

On Apr 13, 2012, at 4/13 8:56 AM, Diego Perino wrote:

> Dear all,
> 
> I went through the charter and I have some comments, especially related to the caching part.
> 
> 1) in the "Research challenges" section, where caching is mentioned, the focus is mostly on the interaction of caching with transport and routing. These are surely key issues, but I would also put some emphasis on problems related to caching strategies themselves, as one of the main research areas of the RG mentioned in the charter is "caching strategies". I would add a couple of sentences dealing with ICN specific caching issues, and more specifically related to problems that could require standardization. For instance, we could mention the need of mechanisms to coordinate caches in a network, or schemes to manage storage resources at network level by combining replication/caching techniques at different nodes.
> 
> 2) in the "ICNRG objectives" section I would slightly modify the "caching strategies" item, in order to be more consistent with the rest of the charter. We could talk more about in-network caching and replication, and add the interaction with transport and routing that are relevant and can require some standardization.
> 
> Best Regards,
> Diego
> 
> 
> 
> On 10/04/2012 14:07, Dirk Kutscher wrote:
>> Dear all,
>> 
>> Thanks again for your interest in the ICN side meeting at IETF-83 and the constructive suggestions for the ICNRG charter.
>> 
>> Based on your input B?rje, Dave and I have edited the draft charter, specifically with regard to:
>> 
>> - put emphasis on continuous activities with relevance to Internet evolution (to avoid becoming a home for rejected workshop papers ;-)
>> - explicitly mentioned two first initial topic areas (name resolution&  routing scalability and caching strategies)
>> -  included reference baseline scenarios for performance comparison&  information sharing on initial deployments
>> - clarified relationship to possibly related IETF groups (avoiding overlap, but ensuring information exchange)
>> - some shortening
>> 
>> The updated charter text available athttp://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg
>> 
>> We invite interested people to review this and share their comments. Please let us have your comments before 2012-04-14 EOB PDT.
>> 
>> Thanks,
>> B?rje, Dave, Dirk
>> 
>> --
>> Dr. Dirk Kutscher | NEC Laboratories Europe
>> phone: +49 6221 4342 203 | fax: +49 6221 4342 155 | webpage:www.neclab.eu
>> 
>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
>> 
>> 
>> _______________________________________________
>> 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

From: diego.perino at alcatel-lucent.com (Diego Perino)
Date: Fri, 13 Apr 2012 14:56:02 +0200
Subject: [Icn-interest] Updated charter text for proposed IRTF ICNRG
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Dear all,

I went through the charter and I have some comments, especially related 
to the caching part.

1) in the "Research challenges" section, where caching is mentioned, the 
focus is mostly on the interaction of caching with transport and 
routing. These are surely key issues, but I would also put some emphasis 
on problems related to caching strategies themselves, as one of the main 
research areas of the RG mentioned in the charter is "caching 
strategies". I would add a couple of sentences dealing with ICN specific 
caching issues, and more specifically related to problems that could 
require standardization. For instance, we could mention the need of 
mechanisms to coordinate caches in a network, or schemes to manage 
storage resources at network level by combining replication/caching 
techniques at different nodes.

2) in the "ICNRG objectives" section I would slightly modify the 
"caching strategies" item, in order to be more consistent with the rest 
of the charter. We could talk more about in-network caching and 
replication, and add the interaction with transport and routing that are 
relevant and can require some standardization.

Best Regards,
Diego

On 10/04/2012 14:07, Dirk Kutscher wrote:
> Dear all,
>
> Thanks again for your interest in the ICN side meeting at IETF-83 and the constructive suggestions for the ICNRG charter.
>
> Based on your input B?rje, Dave and I have edited the draft charter, specifically with regard to:
>
> - put emphasis on continuous activities with relevance to Internet evolution (to avoid becoming a home for rejected workshop papers ;-)
> - explicitly mentioned two first initial topic areas (name resolution&  routing scalability and caching strategies)
> -  included reference baseline scenarios for performance comparison&  information sharing on initial deployments
> - clarified relationship to possibly related IETF groups (avoiding overlap, but ensuring information exchange)
> - some shortening
>
> The updated charter text available athttp://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg
>
> We invite interested people to review this and share their comments. Please let us have your comments before 2012-04-14 EOB PDT.
>
> Thanks,
> B?rje, Dave, Dirk
>
> --
> Dr. Dirk Kutscher | NEC Laboratories Europe
> phone: +49 6221 4342 203 | fax: +49 6221 4342 155 | webpage:www.neclab.eu
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
>
>
> _______________________________________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest
>

From: paulo.mendes at ulusofona.pt (Paulo Mendes)
Date: Thu, 12 Apr 2012 11:36:39 +0100
Subject: [Icn-interest] Updated charter text for proposed IRTF ICNRG
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Boerje

See my comments inline....

On Apr 12, 2012, at 8:31 AM, B?rje Ohlman wrote:

> Hi Paulo,
> 
> Thanks for your comments. Here is my view on these issues:
> 
> On 10 apr 2012, at 16:40, Paulo Mendes wrote:
> 
>> My first set of comment on the charter are:
>> 
>> a) It is good to make it precise and focus on 2 major topics (name resolution & routing scalability; caching strategies). However, the description of the chapter has one paragraph about a third important issue: security/trust/privacy. IMO, this topic should be added to the list or this paragraph should be removed form the charter, in order to avoid misunderstandings about the propose of the group.
> 
> I think you have a good point here. It is also not good to have things in the charter that quickly will get outdated. I support removing the paragraph. I think it is better not to make topics explicit in the charter but just have a general statement stating that 'the RG will decide on a few research topics to focus on initially', this could be documented on the RG Wiki where we can keep it updated at all times.

Agree

> 
>> b) ICNRG and scientific papers: I do not envision a lot of confusion here, if we all agree that any draft to be accepted should provide a reasonable specification of the proposed solution (proven based on a implementation if possible, and not on simulations)... As we know workshop papers are normally lacking a detailed specification and are normally based on simulations. As I see it, a contribution to the ICNRG may however be supported by one of more already published articles.
> 
> I'm not sure what part of the charter this refers to and what modifications you would like to see.

Not from the charter directly, but from your email, where you mention "put emphasis on continuous activities with relevance to Internet evolution (to avoid becoming a home for rejected workshop papers ;-)". Just wanted to emphasize that this IMO is a non problem, unless people misinterpret the role of IRTF.

> 
>> c) As for the short-term goals, I would add an informative document to describe the relationship with other IETF groups. As for the problem statement, this document may become quite large, with several contributors, depending on the baseline scenarios that will be considered.
> 
> I think such a document could be useful in my opinion. I don't think we should add it to the charter as an explicit deliverable. But if someone takes the initiative to such an document it will definitely have my support.

Good.. I'm not sure how many people have potential contributions for us to cover an interesting set of WGs. Here at SITI, we are working in a document that could be useful to analyze the relationship between ICNRG and DTNRG. If this is of interest a first version could be presented as soon as the ICNRG is opened.

> 
>> d) We should include a roadmap in the charter. Since, for instance, the problem statement will depend on the baseline scenarios, maybe this document should be produced first. Then, we need to check how many identified problems can be solved by work done in other ietf/irtf groups in order to focus on the novel issues...
> 
> I don't think this is a good idea, might just lead to that we spend a lot of time discussing what we should discuss instead of spending the time actually making progress on research issues. An RG will anyway be contribution driven, so what people actually are willing to contribute will determine the real focus. If we get too many contributions we might like to do this at a later stage, but I don't think we should start here.

Agree.. Lets keep a specific roadmap for later on, if needed to keep the focus of the RG.

Paulo

> 
> 	B?rje
> 
>> 
>> For now these are my 2cents
>> 
>> Paulo
>> 
>> 
>> On Apr 10, 2012, at 1:07 PM, Dirk Kutscher wrote:
>> 
>>> Dear all,
>>> 
>>> Thanks again for your interest in the ICN side meeting at IETF-83 and the constructive suggestions for the ICNRG charter.
>>> 
>>> Based on your input B?rje, Dave and I have edited the draft charter, specifically with regard to:
>>> 
>>> - put emphasis on continuous activities with relevance to Internet evolution (to avoid becoming a home for rejected workshop papers ;-)
>>> - explicitly mentioned two first initial topic areas (name resolution & routing scalability and caching strategies)
>>> -  included reference baseline scenarios for performance comparison & information sharing on initial deployments
>>> - clarified relationship to possibly related IETF groups (avoiding overlap, but ensuring information exchange)
>>> - some shortening
>>> 
>>> The updated charter text available at http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg
>>> 
>>> We invite interested people to review this and share their comments. Please let us have your comments before 2012-04-14 EOB PDT.
>>> 
>>> Thanks,
>>> B?rje, Dave, Dirk
>>> 
>>> --
>>> Dr. Dirk Kutscher | NEC Laboratories Europe
>>> phone: +49 6221 4342 203 | fax: +49 6221 4342 155 | webpage: www.neclab.eu
>>> 
>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
>>> 
>>> 
>>> _______________________________________________
>>> Icn-interest mailing list
>>> Icn-interest at listserv.netlab.nec.de
>>> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest
>> 
>> -------------------------------------------------------------
>> Paulo Mendes, Ph.D
>> Scientific Director for Innovation of the Research Unit in Informatics Systems and Technologies (SITI)
>> Coordinator of the Internet Architecture and Networking Lab (IAN Lab)
>> Secretary of the ACM SIGCOMM Chapter - Portugal
>> University Lusofona, Portugal
>> paulo.mendes at ulusofona.pt
>> http://siti.ulusofona.pt/~pmendes
>> Tel.: 217 515 500 Fax: 21 757 7006
>> 
>> _______________________________________________
>> Icn-interest mailing list
>> Icn-interest at listserv.netlab.nec.de
>> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest
> 

-------------------------------------------------------------
Paulo Mendes, Ph.D
Scientific Director for Innovation of the Research Unit in Informatics Systems and Technologies (SITI)
Coordinator of the Internet Architecture and Networking Lab (IAN Lab)
Secretary of the ACM SIGCOMM Chapter - Portugal
University Lusofona, Portugal
paulo.mendes at ulusofona.pt
http://siti.ulusofona.pt/~pmendes
Tel.: 217 515 500 Fax: 21 757 7006

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

From: Borje.Ohlman at ericsson.com (=?iso-8859-1?Q?B=F6rje_Ohlman?=)
Date: Thu, 12 Apr 2012 09:31:39 +0200
Subject: [Icn-interest] Updated charter text for proposed IRTF ICNRG
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Paulo,

Thanks for your comments. Here is my view on these issues:

On 10 apr 2012, at 16:40, Paulo Mendes wrote:

> My first set of comment on the charter are:
> 
> a) It is good to make it precise and focus on 2 major topics (name resolution & routing scalability; caching strategies). However, the description of the chapter has one paragraph about a third important issue: security/trust/privacy. IMO, this topic should be added to the list or this paragraph should be removed form the charter, in order to avoid misunderstandings about the propose of the group.

I think you have a good point here. It is also not good to have things in the charter that quickly will get outdated. I support removing the paragraph. I think it is better not to make topics explicit in the charter but just have a general statement stating that 'the RG will decide on a few research topics to focus on initially', this could be documented on the RG Wiki where we can keep it updated at all times.

> b) ICNRG and scientific papers: I do not envision a lot of confusion here, if we all agree that any draft to be accepted should provide a reasonable specification of the proposed solution (proven based on a implementation if possible, and not on simulations)... As we know workshop papers are normally lacking a detailed specification and are normally based on simulations. As I see it, a contribution to the ICNRG may however be supported by one of more already published articles.

I'm not sure what part of the charter this refers to and what modifications you would like to see.

> c) As for the short-term goals, I would add an informative document to describe the relationship with other IETF groups. As for the problem statement, this document may become quite large, with several contributors, depending on the baseline scenarios that will be considered.

I think such a document could be useful in my opinion. I don't think we should add it to the charter as an explicit deliverable. But if someone takes the initiative to such an document it will definitely have my support.

> d) We should include a roadmap in the charter. Since, for instance, the problem statement will depend on the baseline scenarios, maybe this document should be produced first. Then, we need to check how many identified problems can be solved by work done in other ietf/irtf groups in order to focus on the novel issues...

I don't think this is a good idea, might just lead to that we spend a lot of time discussing what we should discuss instead of spending the time actually making progress on research issues. An RG will anyway be contribution driven, so what people actually are willing to contribute will determine the real focus. If we get too many contributions we might like to do this at a later stage, but I don't think we should start here.

	B?rje

> 
> For now these are my 2cents
> 
> Paulo
> 
> 
> On Apr 10, 2012, at 1:07 PM, Dirk Kutscher wrote:
> 
>> Dear all,
>> 
>> Thanks again for your interest in the ICN side meeting at IETF-83 and the constructive suggestions for the ICNRG charter.
>> 
>> Based on your input B?rje, Dave and I have edited the draft charter, specifically with regard to:
>> 
>> - put emphasis on continuous activities with relevance to Internet evolution (to avoid becoming a home for rejected workshop papers ;-)
>> - explicitly mentioned two first initial topic areas (name resolution & routing scalability and caching strategies)
>> -  included reference baseline scenarios for performance comparison & information sharing on initial deployments
>> - clarified relationship to possibly related IETF groups (avoiding overlap, but ensuring information exchange)
>> - some shortening
>> 
>> The updated charter text available at http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg
>> 
>> We invite interested people to review this and share their comments. Please let us have your comments before 2012-04-14 EOB PDT.
>> 
>> Thanks,
>> B?rje, Dave, Dirk
>> 
>> --
>> Dr. Dirk Kutscher | NEC Laboratories Europe
>> phone: +49 6221 4342 203 | fax: +49 6221 4342 155 | webpage: www.neclab.eu
>> 
>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
>> 
>> 
>> _______________________________________________
>> Icn-interest mailing list
>> Icn-interest at listserv.netlab.nec.de
>> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest
> 
> -------------------------------------------------------------
> Paulo Mendes, Ph.D
> Scientific Director for Innovation of the Research Unit in Informatics Systems and Technologies (SITI)
> Coordinator of the Internet Architecture and Networking Lab (IAN Lab)
> Secretary of the ACM SIGCOMM Chapter - Portugal
> University Lusofona, Portugal
> paulo.mendes at ulusofona.pt
> http://siti.ulusofona.pt/~pmendes
> Tel.: 217 515 500 Fax: 21 757 7006
> 
> _______________________________________________
> 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/20120412/945fb8b4/attachment.html>

From: paulo.mendes at ulusofona.pt (Paulo Mendes)
Date: Tue, 10 Apr 2012 15:40:18 +0100
Subject: [Icn-interest] Updated charter text for proposed IRTF ICNRG
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Dirk

My first set of comment on the charter are:

a) It is good to make it precise and focus on 2 major topics (name resolution & routing scalability; caching strategies). However, the description of the chapter has one paragraph about a third important issue: security/trust/privacy. IMO, this topic should be added to the list or this paragraph should be removed form the charter, in order to avoid misunderstandings about the propose of the group.

b) ICNRG and scientific papers: I do not envision a lot of confusion here, if we all agree that any draft to be accepted should provide a reasonable specification of the proposed solution (proven based on a implementation if possible, and not on simulations)... As we know workshop papers are normally lacking a detailed specification and are normally based on simulations. As I see it, a contribution to the ICNRG may however be supported by one of more already published articles.

c) As for the short-term goals, I would add an informative document to describe the relationship with other IETF groups. As for the problem statement, this document may become quite large, with several contributors, depending on the baseline scenarios that will be considered.

d) We should include a roadmap in the charter. Since, for instance, the problem statement will depend on the baseline scenarios, maybe this document should be produced first. Then, we need to check how many identified problems can be solved by work done in other ietf/irtf groups in order to focus on the novel issues...

For now these are my 2cents

Paulo

On Apr 10, 2012, at 1:07 PM, Dirk Kutscher wrote:

> Dear all,
> 
> Thanks again for your interest in the ICN side meeting at IETF-83 and the constructive suggestions for the ICNRG charter.
> 
> Based on your input B?rje, Dave and I have edited the draft charter, specifically with regard to:
> 
> - put emphasis on continuous activities with relevance to Internet evolution (to avoid becoming a home for rejected workshop papers ;-)
> - explicitly mentioned two first initial topic areas (name resolution & routing scalability and caching strategies)
> -  included reference baseline scenarios for performance comparison & information sharing on initial deployments
> - clarified relationship to possibly related IETF groups (avoiding overlap, but ensuring information exchange)
> - some shortening
> 
> The updated charter text available at http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg
> 
> We invite interested people to review this and share their comments. Please let us have your comments before 2012-04-14 EOB PDT.
> 
> Thanks,
> B?rje, Dave, Dirk
> 
> --
> Dr. Dirk Kutscher | NEC Laboratories Europe
> phone: +49 6221 4342 203 | fax: +49 6221 4342 155 | webpage: www.neclab.eu
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
> 
> 
> _______________________________________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

-------------------------------------------------------------
Paulo Mendes, Ph.D
Scientific Director for Innovation of the Research Unit in Informatics Systems and Technologies (SITI)
Coordinator of the Internet Architecture and Networking Lab (IAN Lab)
Secretary of the ACM SIGCOMM Chapter - Portugal
University Lusofona, Portugal
paulo.mendes at ulusofona.pt
http://siti.ulusofona.pt/~pmendes
Tel.: 217 515 500 Fax: 21 757 7006

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120410/2eaa83a6/attachment.html>

From: Dirk.Kutscher at neclab.eu (Dirk Kutscher)
Date: Tue, 10 Apr 2012 12:07:24 +0000
Subject: [Icn-interest] Updated charter text for proposed IRTF ICNRG
Message-ID: <[email-masked]>

Dear all,

Thanks again for your interest in the ICN side meeting at IETF-83 and the constructive suggestions for the ICNRG charter.

Based on your input B?rje, Dave and I have edited the draft charter, specifically with regard to:

- put emphasis on continuous activities with relevance to Internet evolution (to avoid becoming a home for rejected workshop papers ;-)
- explicitly mentioned two first initial topic areas (name resolution & routing scalability and caching strategies)
-  included reference baseline scenarios for performance comparison & information sharing on initial deployments
- clarified relationship to possibly related IETF groups (avoiding overlap, but ensuring information exchange)
- some shortening

The updated charter text available at http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg

We invite interested people to review this and share their comments. Please let us have your comments before 2012-04-14 EOB PDT.

Thanks,
B?rje, Dave, Dirk

--
Dr. Dirk Kutscher | NEC Laboratories Europe
phone: +49 6221 4342 203 | fax: +49 6221 4342 155 | webpage: www.neclab.eu

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

From: andrea.detti at uniroma2.it (Andrea Detti)
Date: Tue, 10 Apr 2012 11:16:58 +0200
Subject: [Icn-interest] follow up of a talk at the ICNRG side meeting at IETF-83
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Dear All,
as anticipated in my previous mail, I analyzed a clear HTTP trace that, 
unfortunately, I can not release for privacy reason.

The traffic trace was collected in 2010 from a Point-Of-Presence 
backbone of a relatively small (regional) operator.
The analysis results are:

total number of HTTP request to Web Servers: 521315
total number of involved domain names: 8567
total number of unique IP addresses: 6292
Rate R = 8567/6292 = 1.36

Therefore, due to this third evidence, my feeling is that: _within HTTP 
Internet traces,_ there is a quite similarity between i) the number of 
involved domain-names and ii) the number of unique IP addresses of 
involved HTTP servers.

This conjecture, on the one hand, makes reasonable my analysis on route 
caching feasibility and, on the other hand, offers a new instrument for 
deriving a quite tight lower bound of the number of  domain-names 
contained in a HTTP trace, meanwhile using anonymized IP traces where 
only unique IP addresses can be counted.

Regards,

Andrea

On 04/02/2012 12:51 PM, Andrea Detti wrote:
> Dear Thomas, Ashok, All
>
> I understand your concerns and try to summarize the situation.
>
> The problem is that the route caching feasibility check I carried out 
> is reasonable if _within HTTP Internet traces_ of tier-1 nodes there 
> is a quite similarity between i) the number of involved domain-names 
> and ii) the number of unique IP addresses of involved HTTP servers. We 
> refer the ratio between these two numbers (i / ii) as R.
>
> I point out that I am NOT sustaining that this similarity is true for 
> the whole set of domain-names; indeed, thousand of  unpopular 
> domain-names are hosted by a same server. I am only sustaining that 
> the similarity should be reasonable _within HTTP traces_.
>
> Obviously, if I could analyze tier-1 HTTP traces with clear GETs (i.e. 
> not anonymized or removed) then I could easily assess the truth. 
> Unfortunately I have not (yet) found in the WEB such traces for tier-1 
> nodes. If someone of the ICN RG community has these traces, please 
> provide me with the URL.
>
> It worth to report the upper and lower bound of the problem. In the 
> Equinix-Sanjose trace (tier-1), I measured an average number of IP 
> active-routes (/32) in the order of 3.000. I am sustaining that this 
> value is close to the number of ICN active-routes that we would obtain 
> if, instead of using /32 IP addresses, we use domain-names.
>
> Also in the Equinix-Sanjose trace, I measured an average number of IP 
> active-flows in the order of 30.000, where a flow is a single 
> interaction between a client and a HTTP server on a specific client port.
>
> Therefore, the expected number of ICN active-routes is bounded between 
> 30.000 and 3.000. The upper bound of 30.000 is reached when each time 
> different and concurrent flows end to a same IP addresses, then these 
> flows surely refer to a different domain-name. Conversely, the lower 
> bound 3.000 is reached when these flows surely refer to a same 
> domain-name. Obviously the truth is in the middle; anyhow it is 
> important to observe that we are discussing of a value of R roughly 
> ranging from 1 to 10. So neither 1.000 nor 100, but at most R=10 for 
> this tier-1 trace, that is the worst I have.
>
> This said, I wish to give my opinion on your reasonable concerns. Then 
> I will discuss two recent measurements on this topic and my future works.
>
> Both Thomas and Ashok observe that the ratio of 1.2 I measured on the 
> first 100.000 top domain is optimistic, since I am only considering 
> popular domains and not the unpopular web. I agree with this 
> observation, nevertheless my feeling is that within a HTTP trace, the 
> popular WEB represents the most of traffic. Therefore, albeit this 
> fact increases the number of ICN active-route respect to the lower 
> bound of 3.000, I think that the gap could be limited, i.e. R should 
> remain close to 1.
>
> Thomas observe that some sites like facebook.com initially resolve to 
> facebook servers, but all the static subcontent (using dedicated 
> names/URLs) is delivered via Akamai. I agree and I made some 
> measurement on this, see later.
>
> Thomas note that for CDN-supported domains, DSN resolution depends on 
> "where" is the requesting host, indeed a same domain-name is 
> associated to more IP addresses. On my opinion this enforces my 
> results, rather than contrasts them. Indeed it tends to "decrease" the 
> number of ICN active-routes respect to the number of /32 IP active-routes.
>
> Now I report 2 novel measurements I made in the weekend.
>
> 1)    I increased the number of tested domain-names from 100.000 to 
> 700.000 and the ratio between number of domain-names and unique IP 
> addresses is now 1.5564.
>
> 2)    Since I do not have public HTTP traces, I realized a quick and 
> dirty test by producing a 1 hr trace. I fetched the following contents:
> 20 Google searches
> 20 YouTube videos
> 20 Facebook pages
> 10 News. starting Google news
> 10 Ebay searches
> 10 Wikipedia searches
> 10 pages of Microsoft.com
>
> Using Wireshark, I measured the number of involved domain-names 
> (including the dedicated names/URLs that Thomas rightly observed and 
> that appear after the first contact , e.g. with youtube) and the 
> number of unique IP addresses of HTTP servers. The number of involved 
> domain-names is 267, the number of involved IP addresses is 210. So, 
> the ratio R is about 1.27. Of course, this is just a case where my 
> thesis seems reasonable.
>
> Summarizing, now I have two facts  (analysis of 700.000 DNS names and 
> my trace) that support my thesis. As I said before, it could be very 
> useful if the community could provide me with some pcap trace where 
> HTTP GETs are clear. From my side, I am trying to get such a trace on 
> the gateway of my University of Rome. I will inform you about the 
> analysis on this new trace.
>
> Thanks a lot for your interest,
>
> Regards
>
> Andrea
>
>
>
> On 03/30/2012 07:37 PM, Ashok Narayanan wrote:
>> I think also part of the issue is your selection of domain names. Selecting the top 100000 means you are self-selecting customers who have an interest in dedicated hosting. The issue is with the _bottom_ 500,000 who are likely to have virtual hosting purchased from common providers like Godaddy.
>>
>> -Ashok
>>
>> On Mar 30, 2012, at 3/30 7:15 AM, Thomas C. Schmidt wrote:
>>
>>> Dear Andrea,
>>>
>>> together with Dave, I was one of the two persons ...
>>>
>>> Thanks for looking at it again.
>>>
>>> However, I believe the matter is slightly more complicated. Whenever you look at CDN-supported domains, DNS is twisted by the request routing system and you normally don't get answers like your list suggests: multiple IP addresses are normal and the answers depend on your topological position, the time of resolution request, ... etc.
>>> There is no one-to-one mapping between those sites and IP-Addresses.
>>>
>>> You might want to check using a bunch of different DNS resolvers.
>>>
>>> In addition, you have sites like facebook.com that initially resolve to facebook servers, but all the static subcontent (using dedicated names/URLs) is delivered via Akamai.
>>>
>>>
>>> Whenever you look at smaller sites (less popular domains), you will increasingly find virtualization, large collections of names that correspond to virtual Web serves running on one physical instance (or distributed behind a load balancer) using one IP-for-all. Some people also use these cloud-thingies ... and there are - last but not least - DNS aliases.
>>>
>>> Personally, I would doubt that this argument is easy to heal ... and in any case would expect some orders of magnitude between IP and Name traces.
>>>
>>> Best regards,
>>>
>>> Thomas
>>>
>>> On 30.03.2012 12:41, Andrea Detti wrote:
>>>> Dear all,
>>>> this is a follow up of my talk on "Route caching: a technique to improve
>>>> the scalability of ICN", given at the ICNRG side meeting @ IETF-83 in
>>>> Paris (http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg).
>>>>
>>>> As regards the feasibility evaluation, two persons in the room pointed
>>>> out that the same IP address may serve more than one domain-name; this
>>>> was in contrast with my assumption of a "one-to-one" relationship
>>>> between an IP address and a domain-name.
>>>>
>>>> Once home, I made some measurements to evaluate the impact of this fact.
>>>>
>>>> I resolved the IP addresses of the top 100 000 domain names
>>>> (http://s3.amazonaws.com/alexa-static/top-1m.csv.zip) and measured the
>>>> ratio between the number of those domain-names (100000) and the number
>>>> of unique IP addresses. This ratio is about 1.2 (see
>>>> http://netgroup.uniroma2.it/Andrea_Detti/Lookup-and-Cache/Feasibility-check/domain-name-2-ip.txt).
>>>>
>>>>
>>>> This means that my result on the number of active-routes (i.e. between
>>>> 10^3 and 10^4) should be corrected by this factor.
>>>>
>>>> However, it seems to me that the overall conclusion on the feasibility
>>>> check remains valid, as the order of magnitude of the number of
>>>> active-routes does not change and remains well below the current FIB
>>>> storage capacity (10^6 routes).
>>>>
>>>> Kind regards
>>>> Andrea
>>>>
>>> -- 
>>>
>>> Prof. Dr. Thomas C. Schmidt
>>> ? Hamburg University of Applied Sciences                   Berliner Tor 7 ?
>>> ? Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany ?
>>> ?http://www.haw-hamburg.de/inet                    Fon: +49-40-42875-8452 ?
>>> ?http://www.informatik.haw-hamburg.de/~schmidt     Fax: +49-40-42875-8409 ?
>>> _______________________________________________
>>> 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
>>
>>
>
>
> -- 
> ---------------------------------------
>   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:andrea.detti at uniroma2.it
> ---------------------------------------
>
>
> _______________________________________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

-- 
---------------------------------------
  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: andrea.detti at uniroma2.it
---------------------------------------

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

From: Dirk.Kutscher at neclab.eu (Dirk Kutscher)
Date: Thu, 5 Apr 2012 21:52:39 +0000
Subject: [Icn-interest] Updated version of draft-farrell-decade-ni
Message-ID: <[email-masked]>

Hi,

We have submitted an update of  draft-farrell-decade-ni: 

http://tools.ietf.org/html/draft-farrell-decade-ni-02

The changes from the previous version include a binary format and a human-readable format of NI names.

This has been originally been submitted to DECADE, so we expect that most of the discussion will take place there:
https://www.ietf.org/mailman/listinfo/decade

Best regards,
Dirk

From: Dirk.Kutscher at neclab.eu (Dirk Kutscher)
Date: Thu, 5 Apr 2012 12:41:04 +0000
Subject: [Icn-interest] Minutes of ICN side meeting @ IETF-83
Message-ID: <[email-masked]>

Dear all,

Thanks again for attending and engaging in the ICN side meeting at IETF-83. It was great to see that many of you (we had 53 names on the "white sheet") despite the slightly inconvenient time slot.

Special thanks to the presenters -- we had four interesting presentations that initiated good discussions, also after the meeting, and we hope to continue working on those topics with you.

We have added the presentation slides and some meeting minutes to the Wiki page now:

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

---++ Summary
The ICN side meeting at IETF-83 in Paris was attended by 53
people. There were four 10 minutes presentations, largely focused on
ICN caching topics, followed by a discussion on next steps towards
forming an IRTF research group. Many people expressed interest in
having such a group. A few people commented on specific objectives
that could be mentioned in a charter for the group, and it was
concluded that such objectives should be added soon so that a group
can be formed and have its first meeting in summer 2012.

Best regards,
Dirk

--
Dr. Dirk Kutscher | NEC Laboratories Europe
phone: +49 6221 4342 203 | fax: +49 6221 4342 155 | webpage: www.neclab.eu

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

From: hkarl at mail.uni-paderborn.de (Holger Karl)
Date: Thu, 5 Apr 2012 13:40:59 +0200
Subject: [Icn-interest] Deadline extension for Elsevier ComCom ICN special issue
Message-ID: <[email-masked]>

Dear colleagues, 

due to several requests and the persistent hints about Easter holidays, we decided to extend the deadline for the Elsevier ComCom special issue on Information Centric Networking. 

The new deadline: 		May 15th, 2012 

Please submit via the Elsevier website. Use the FINAL layout in the Elsevier LaTeX style (no preprint option). Maximum page length is 14 pages. 

http://www.journals.elsevier.com/computer-communications/call-for-papers/special-issue-on-information-centric-networking/

Best regards, 

Holger 

---
Prof. Dr. Holger Karl
Computer Networks group - http://wwwcs.upb.de/cs/ag-karl/
Chairman of the board of the 
Paderborn Center for Parallel Computing - http://wwwcs.upb.de/pc2/
Universit?t Paderborn
Tel.: (05251) 60-5375 FAX: (05251)60-5377
Need to talk to me? -  http://doodle.com/hkarl 

--------------------------------------------
Q: Why is this email five sentences or less?
A: http://five.sentenc.es

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

From: myeong.jang at samsung.com (=?euc-kr?B?wOW47b/t?=)
Date: Wed, 04 Apr 2012 12:00:08 +0000 (GMT)
Subject: [Icn-interest] A follow up of my presentation at the ICNRG side meeting at IETF-83
Message-ID: <1355139.323641333540807890.JavaMail.weblogic@epml23>

Dear all,

This is a follow up of my talk on "ICN for VPC" at the ICNRG side meeting at IETF-83 in Paris.
My presentation slides did not give any information about my paper and contact point.
Please check the below Web site.

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5722896
      Jaehoon Kim, Myeong-wuk Jang, Byoung-Joon Lee, Kiho Kim, 
      ?Content Centric Network-based Virtual Private Community,? 
      The IEEE International Conference on Consumer Electronics (ICCE), 
      pp. 843-844, Las Vegas, Nevada, 
      January 9-12, 2011.

Also, if you have any questions regarding my presentation and papers, please let me know.

Best regards,

Myeong.
----------------------------------------
Myeong-Wuk Jang
Principal Researcher / Ph.D.
SAMSUNG Electronics, Co., Ltd.
Tel: +82-31-280-9624
EMail: myeong.jang at samsung.com
----------------------------------------

From: andrea.detti at uniroma2.it (Andrea Detti)
Date: Tue, 03 Apr 2012 10:41:25 +0200
Subject: [Icn-interest] About dataset for content names in ICN
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Faizul,
I don't know the existence of such a dataset.
Nevertheless, I like to share some stuff on this issue

First of all, IMHO, the dataset depends on :
1) which is the ICN deployment scenario you are considering;
2) the selected naming scheme;
3) which performance you want to evaluate with your simulator, e.g. 
routing scalability, caching performance, etc.

in case your deployment scenario envisage to use a ICN to fetch current 
WEB contents and in case you use a hierarchical naming scheme such as 
the CCN one, then I guess that you can use as dataset the actual URLs, 
excluding the initial scheme part; i.e. content-name=domain-name/path

Regarding how to obtain this dataset, I can only suggest you that the 
list of 1M top domain-names is available here 
http://s3.amazonaws.com/alexa-static/top-1m.csv.zip. This list could be 
enough if, as in my work on "route" caching (see 
http://trac.tools.ietf.org/group/irtf/trac/attachment/wiki/icnrg/RouteCachingDettiMorabitoV2.pdf), 
you are considering routing issues, and hence you likely need only 
name-prefixes, rather than full content-names.
Conversely if you focus on "content" caching performance, I guess that 
you should use a list of full URLs (i.e. domain-name/path) and you have 
also to weight these content-names with a popularity function, e.g. Zipf.

My two cents.

Andrea

On 04/03/2012 05:50 AM, faizul bari wrote:
> Hello,
>
> Is there any existing dataset on content names that can be used as a 
> sample for ICN content names? If not can anyone suggest me how to 
> build such a dataset what will be suitable for simulation?
>
>
> Regards
> ----------------------
> Md. Faizul Bari
>
> PhD Student
> David R. Cheriton School of Computer Science
> University of Waterloo
> {http://www.cs.uwaterloo.ca/~mfbari 
> <http://www.cs.uwaterloo.ca/%7Emfbari>}
> [May 'The Google' be with U]
>
>
> _______________________________________________
> Icn-interest mailing list
> Icn-interest at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/icn-interest

-- 
---------------------------------------
  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: andrea.detti at uniroma2.it
---------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120403/8e549fe5/attachment.html>

From: faizulbari at gmail.com (faizul bari)
Date: Mon, 2 Apr 2012 23:50:35 -0400
Subject: [Icn-interest] About dataset for content names in ICN
Message-ID: <[email-masked]>

Hello,

Is there any existing dataset on content names that can be used as a sample
for ICN content names? If not can anyone suggest me how to build such a
dataset what will be suitable for simulation?

Regards
----------------------
Md. Faizul Bari

PhD Student
David R. Cheriton School of Computer Science
University of Waterloo
{http://www.cs.uwaterloo.ca/~mfbari}
[May 'The Google' be with U]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.netlab.nec.de/mailman/private/icn-interest/attachments/20120402/a179a5cc/attachment-0001.html>

From: andrea.detti at uniroma2.it (Andrea Detti)
Date: Mon, 02 Apr 2012 12:51:38 +0200
Subject: [Icn-interest] follow up of a talk at the ICNRG side meeting at IETF-83
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Dear Thomas, Ashok, All

I understand your concerns and try to summarize the situation.

The problem is that the route caching feasibility check I carried out is 
reasonable if _within HTTP Internet traces_ of tier-1 nodes there is a 
quite similarity between i) the number of involved domain-names and ii) 
the number of unique IP addresses of involved HTTP servers. We refer the 
ratio between these two numbers (i / ii) as R.

I point out that I am NOT sustaining that this similarity is true for 
the whole set of domain-names; indeed, thousand of  unpopular 
domain-names are hosted by a same server. I am only sustaining that the 
similarity should be reasonable _within HTTP traces_.

Obviously, if I could analyze tier-1 HTTP traces with clear GETs (i.e. 
not anonymized or removed) then I could easily assess the truth. 
Unfortunately I have not (yet) found in the WEB such traces for tier-1 
nodes. If someone of the ICN RG community has these traces, please 
provide me with the URL.

It worth to report the upper and lower bound of the problem. In the 
Equinix-Sanjose trace (tier-1), I measured an average number of IP 
active-routes (/32) in the order of 3.000. I am sustaining that this 
value is close to the number of ICN active-routes that we would obtain 
if, instead of using /32 IP addresses, we use domain-names.

Also in the Equinix-Sanjose trace, I measured an average number of IP 
active-flows in the order of 30.000, where a flow is a single 
interaction between a client and a HTTP server on a specific client port.

Therefore, the expected number of ICN active-routes is bounded between 
30.000 and 3.000. The upper bound of 30.000 is reached when each time 
different and concurrent flows end to a same IP addresses, then these 
flows surely refer to a different domain-name. Conversely, the lower 
bound 3.000 is reached when these flows surely refer to a same 
domain-name. Obviously the truth is in the middle; anyhow it is 
important to observe that we are discussing of a value of R roughly 
ranging from 1 to 10. So neither 1.000 nor 100, but at most R=10 for 
this tier-1 trace, that is the worst I have.

This said, I wish to give my opinion on your reasonable concerns. Then I 
will discuss two recent measurements on this topic and my future works.

Both Thomas and Ashok observe that the ratio of 1.2 I measured on the 
first 100.000 top domain is optimistic, since I am only considering 
popular domains and not the unpopular web. I agree with this 
observation, nevertheless my feeling is that within a HTTP trace, the 
popular WEB represents the most of traffic. Therefore, albeit this fact 
increases the number of ICN active-route respect to the lower bound of 
3.000, I think that the gap could be limited, i.e. R should remain close 
to 1.

Thomas observe that some sites like facebook.com initially resolve to 
facebook servers, but all the static subcontent (using dedicated 
names/URLs) is delivered via Akamai. I agree and I made some measurement 
on this, see later.

Thomas note that for CDN-supported domains, DSN resolution depends on 
"where" is the requesting host, indeed a same domain-name is associated 
to more IP addresses. On my opinion this enforces my results, rather 
than contrasts them. Indeed it tends to "decrease" the number of ICN 
active-routes respect to the number of /32 IP active-routes.

Now I report 2 novel measurements I made in the weekend.

1)    I increased the number of tested domain-names from 100.000 to 
700.000 and the ratio between number of domain-names and unique IP 
addresses is now 1.5564.

2)    Since I do not have public HTTP traces, I realized a quick and 
dirty test by producing a 1 hr trace. I fetched the following contents:
20 Google searches
20 YouTube videos
20 Facebook pages
10 News. starting Google news
10 Ebay searches
10 Wikipedia searches
10 pages of Microsoft.com

Using Wireshark, I measured the number of involved domain-names 
(including the dedicated names/URLs that Thomas rightly observed and 
that appear after the first contact , e.g. with youtube) and the number 
of unique IP addresses of HTTP servers. The number of involved 
domain-names is 267, the number of involved IP addresses is 210. So, the 
ratio R is about 1.27. Of course, this is just a case where my thesis 
seems reasonable.

Summarizing, now I have two facts  (analysis of 700.000 DNS names and my 
trace) that support my thesis. As I said before, it could be very useful 
if the community could provide me with some pcap trace where HTTP GETs 
are clear. From my side, I am trying to get such a trace on the gateway 
of my University of Rome. I will inform you about the analysis on this 
new trace.

Thanks a lot for your interest,

Regards

Andrea

On 03/30/2012 07:37 PM, Ashok Narayanan wrote:
> I think also part of the issue is your selection of domain names. Selecting the top 100000 means you are self-selecting customers who have an interest in dedicated hosting. The issue is with the _bottom_ 500,000 who are likely to have virtual hosting purchased from common providers like Godaddy.
>
> -Ashok
>
> On Mar 30, 2012, at 3/30 7:15 AM, Thomas C. Schmidt wrote:
>
>> Dear Andrea,
>>
>> together with Dave, I was one of the two persons ...
>>
>> Thanks for looking at it again.
>>
>> However, I believe the matter is slightly more complicated. Whenever you look at CDN-supported domains, DNS is twisted by the request routing system and you normally don't get answers like your list suggests: multiple IP addresses are normal and the answers depend on your topological position, the time of resolution request, ... etc.
>> There is no one-to-one mapping between those sites and IP-Addresses.
>>
>> You might want to check using a bunch of different DNS resolvers.
>>
>> In addition, you have sites like facebook.com that initially resolve to facebook servers, but all the static subcontent (using dedicated names/URLs) is delivered via Akamai.
>>
>>
>> Whenever you look at smaller sites (less popular domains), you will increasingly find virtualization, large collections of names that correspond to virtual Web serves running on one physical instance (or distributed behind a load balancer) using one IP-for-all. Some people also use these cloud-thingies ... and there are - last but not least - DNS aliases.
>>
>> Personally, I would doubt that this argument is easy to heal ... and in any case would expect some orders of magnitude between IP and Name traces.
>>
>> Best regards,
>>
>> Thomas
>>
>> On 30.03.2012 12:41, Andrea Detti wrote:
>>> Dear all,
>>> this is a follow up of my talk on "Route caching: a technique to improve
>>> the scalability of ICN", given at the ICNRG side meeting @ IETF-83 in
>>> Paris ( http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg).
>>>
>>> As regards the feasibility evaluation, two persons in the room pointed
>>> out that the same IP address may serve more than one domain-name; this
>>> was in contrast with my assumption of a "one-to-one" relationship
>>> between an IP address and a domain-name.
>>>
>>> Once home, I made some measurements to evaluate the impact of this fact.
>>>
>>> I resolved the IP addresses of the top 100 000 domain names
>>> (http://s3.amazonaws.com/alexa-static/top-1m.csv.zip) and measured the
>>> ratio between the number of those domain-names (100000) and the number
>>> of unique IP addresses. This ratio is about 1.2 (see
>>> http://netgroup.uniroma2.it/Andrea_Detti/Lookup-and-Cache/Feasibility-check/domain-name-2-ip.txt).
>>>
>>>
>>> This means that my result on the number of active-routes (i.e. between
>>> 10^3 and 10^4) should be corrected by this factor.
>>>
>>> However, it seems to me that the overall conclusion on the feasibility
>>> check remains valid, as the order of magnitude of the number of
>>> active-routes does not change and remains well below the current FIB
>>> storage capacity (10^6 routes).
>>>
>>> Kind regards
>>> Andrea
>>>
>> -- 
>>
>> Prof. Dr. Thomas C. Schmidt
>> ? Hamburg University of Applied Sciences                   Berliner Tor 7 ?
>> ? Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany ?
>> ? http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 ?
>> ? http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 ?
>> _______________________________________________
>> 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
>
>

-- 
---------------------------------------
  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: andrea.detti at uniroma2.it
---------------------------------------

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