Subject: [icnrg] FW: New Version Notification for draft-ren-icn-content-retrieval-00.txt

From: "Will Liu (Shucheng)" <[email-masked]>
Date: Mon, 15 Oct 2012 11:47:51 +0000

Hello,

We have submitted a new draft discussing about content retrieval in ICN. Here, we discussed basic requirements on the basis of previous literatures, the fundamental functionalities required to satisfy the foregoing requirements, and the implementation status of such functionalities in various Information-Centric Network architectures.

Your comments are highly appreciated.

Regards,
Shucheng LIU (Will)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 15, 2012 7:26 PM
To: Will Liu (Shucheng)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: New Version Notification for draft-ren-icn-content-retrieval-00.txt

A new version of I-D, draft-ren-icn-content-retrieval-00.txt
has been successfully submitted by Will Liu and posted to the
IETF repository.

Filename:	 draft-ren-icn-content-retrieval
Revision:	 00
Title:		 On the Content Retrieval In Information-Centric Network
Creation date:	 2012-10-15
WG ID:		 Individual Submission
Number of pages: 11
URL:             http://www.ietf.org/internet-drafts/draft-ren-icn-content-retrieval-00.txt
Status:          http://datatracker.ietf.org/doc/draft-ren-icn-content-retrieval
Htmlized:        http://tools.ietf.org/html/draft-ren-icn-content-retrieval-00

Abstract:
   Information-Centric Network(ICN), as an emerging network
   architecture, focus on delivering content more efficiently.  This
   brief paper discusses some issues about content retrieval in the
   Information-Centric Network.  It first lists a set of basic
   requirements on the basis of previous literatures.  Then, it tries to
   identify the fundamental functionalities required to satisfy the
   foregoing requirements.  Last, it summarizes the implementation
   status of such functionalities in various Information-Centric Network
   architectures.

The IETF Secretariat

---

From: "Will Liu (Shucheng)" <[email-masked]>
Date: Thu, 18 Oct 2012 12:06:40 +0000

Hi all,

We'd like to ask for a time slot to discuss the following submitted new draft, if we could. Thanks.

Regards,
Will

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Will Liu (Shucheng)
> Sent: Monday, October 15, 2012 7:48 PM
> To: [email-masked]
> Subject: [icnrg] FW: New Version Notification for
> draft-ren-icn-content-retrieval-00.txt
> 
> Hello,
> 
> We have submitted a new draft discussing about content retrieval in ICN.
> Here, we discussed basic requirements on the basis of previous literatures,
> the fundamental functionalities required to satisfy the foregoing
> requirements, and the implementation status of such functionalities in
> various Information-Centric Network architectures.
> 
> URL:
> http://www.ietf.org/internet-drafts/draft-ren-icn-content-retrieval-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-ren-icn-content-retrieval
> Htmlized:
> http://tools.ietf.org/html/draft-ren-icn-content-retrieval-00
> 
> 
> Abstract:
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Andrea Detti <[email-masked]>
Date: Fri, 19 Oct 2012 15:05:02 +0200

Dear Will,

I have some comments regarding the CONVERGENCE project, in which I am 
involved.

The CONVERGENCE network (CONET) is similar to CCNx; we complement it 
with some missing functionality or we try to improve its performance, 
e.g. routing [1], named-sap [2], transport, etc..

In what follows I propose some changes to the valuable description 
provided by the draft, regarding how CONVERGENCE deals with the 
following issues:

<Content name resolution>

the draft reports : "Dedicate Name-System-Nodes (similar to DNS) are 
deployed"

This sentence might be understood as: “to forward a content request, a 
CONET node always queries the Name-System-Nodes to resolve the next-hop”.

This is not true since, as CCNx, a CONET node usually resolves the 
names, en-route, by means of a name-based forwarding information base 
(FIB), i.e. without contacting the Name-System-Nodes (or better 
Name-Routing-System nodes, see [1])

However, current fast FIBs (e.g. based on SRAM) have a size unable to 
store all possible name-prefixes.

To cope with this issue, a CONET node uses the FIB as "route cache".

If the node does not have the routing entry necessary to route-by-name 
an Interest message, then the node lookups the routing information in 
the Name-Routing-System and caches the routing entry in the FIB.

Therefore, lookups occur only in cases of route-cache misses, which 
should be a rare event.

Furthermore, as general comment, I think that it could be important to 
specify, for any project, if Content Name Resolution is performed at 
packet-rate or only one-time per download, i.e. at session-rate.

A CONET node performs name resolution at packet-rate by using a FIB and, 
sometimes, by contacting nodes of a Name-Routing-System.

Consequently, I would revise the draft as follows "En-route name 
resolution performed at packet-rate by means of name-based forwarding 
tables, which are used as route-caches. Route-cache misses are resolved 
by means of a dedicated Name-Routing-Sytem node (similar to DNS)."

<k-anycast and multicast>

the draft reports: " Traditional point-to-point sessions between two 
upper layer entities can be supported by coupling the upper layer 
entities with named-service-assess-points. This functionality can be 
extended to support multicast"

I think that this is not completely true. Indeed, named-saps are not 
meant for multicasting purpose, but [2] to support legacy point-to-point 
interactive service sessions, e.g. home banking.

Multicast is achieved in CCNx/CONET by exploiting both en-route 
in-network caching and the mechanism of Pending Interest Table (PIT), as 
described in [NDN].

In case of a multicast service, e.g. video live streaming, many sources 
send the same Interest message, e.g. to request the next video frame. 
Using the PIT mechanism, in case of quite-synchronous Interests, or 
using in-network caching, in case of nearly-synchronous Interest, the 
same content chunk is transferred only one time, on a link of the 
multicast tree rooted at source.

Consequently, regarding multicast, I would revise the draft as follows:

"Receiver-driven multicast based on i) routing information temporary 
left in network nodes (aka Pending Interest Table) and ii) in-network 
caching"

Regarding k-multicast, I would revise the draft as follows 
"Receiver-driven k-multicast, by concurrently fetching different data 
chunks from the different replica Servers"

<Content replication>

it is OK

<In-network cache discovery>

it is OK

Thanks a lot for your effort,

Andrea

[1] A. Detti, M. Pomposini, N. Blefari-Melazzi, S. Salsano, “Supporting 
the Web with an Information Centric Network that Routes by Name”, 
Elsevier Computer Networks, vol. 56, Issue 17, p. 3705–3722 
(http://netgroup.uniroma2.it/Andrea_Detti/Lookup-and-Cache/comnet-web-ICN-ext.pdf)

[2] "D3.1 - Definition of the system services and functional 
components", CONVERGENCE deliverable, see Section 4.1

-- 
---------------------------------------
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: "Will Liu (Shucheng)" <[email-masked]>
Date: Sat, 27 Oct 2012 10:55:55 +0000

Dear Andrea,

Sorry for being late. Many thanks for your valuable comments. 
 
When we were writing this draft, we classified name resolution mechanisms into two categories: route-by-name and DNS-like resolution system. We defined route-by-name as “routers disseminate name-based routing information with each other and forward packets based on the name-based routing table” (sorry that we did not write this definition clearly in the draft). From this point, we considered that CONET does not disseminate routing information, but establishes a DNS-like system. We ignored that CONET also deployed a route-cache mechanism. Thanks for pointing out this. We will rewrite the draft according to your suggestion. 

In conducting the survey of multicast mechanism, we read a few published CONET papers, such as [1][2]. We only find a few sentences about multicast, which stated that named-sap can be extended to multicast (see [1] sec1, [2] sec7.1). 
 
Regarding the PIT, I have a question. In [1] , it says that “This info will be used to find the reverse-path to route the named-data CIU back to the requesting node, in the delivery phase. In [3] the same goal is achieved by maintaining states in network nodes. We propose to use source-routing, being aware of the involved trade-offs, and given that we think that the number of traversed CONET border nodes should be rather limited (e.g. CSSs should coincide with Internet Autonomous Systems).”
 
According to the above information, we think that CONET takes a different way from CCN about multicast. Maybe we have missed some important literatures. Can you give us some references? Thank you so much.

[1]Detti, A., N. B. Melazzi, et al. (2011). CONET: a content centric inter-networking architecture. Proceedings of the ACM SIGCOMM workshop on Information-centric networking. Toronto, Ontario, Canada, ACM: 50-55.
[2]“D3.2 - System architecture”, CONVERGENCE deliverable
[3] V. Jacobson, D. K. Smetters, J. D. Thornton et al., ”Networking named content”, ACM CoNEXT 2009

Regards,
Will

> From: Andrea Detti [mailto:[email-masked]]
> Sent: Friday, October 19, 2012 9:05 PM
> To: [email-masked]; Will Liu (Shucheng)
> Subject: Re: [icnrg] FW: New Version Notification for

---

From: Andrea Detti <[email-masked]>
Date: Wed, 31 Oct 2012 18:19:25 +0100

Dear Will,
thank you for your interest in CONVERGENCE project.

Regarding multicast, we just published the Final Architecture of the
project (see D5.3 on http://www.ict-convergence.eu/deliverables/), where
we state in section 4.2.1

"The Data forwarding process exploits reverse-path information either
temporarily stored in the traversed nodes during the Interest forwarding
process (see Pending
Interest Table of [CCN]), or contained in the header of Data message,
and previously collected in
the Interest message during the forwarding process (see reverse-path
source-routing in [CONET ICN SIGCOM Paper] or
D3.2) "

So, depending on specific deployment choice, the CONET supports both PIT
and reverse-path source-routing Data forwarding mechanisms. In the
former case, we deal with multicast (synchronous and asynchronous, see
later) as CCN. In the second case, we only support "asynchronous"
multicast through in-network caching, as CCN. With the term asynchronous
multicast, I mean the case where requests of a same content object are
issued by different nodes in close, but different, times. In this case,
the first common in-network cache of the multicast tree rooted at source
acts as the splitting point of a multicast distribution tree (e.g. see
http://www.verivue.com/blog/index.php/cdn-architecture/asynchronous-multicast/).

"Receiver-driven multicast based on i) in-network
caching and ii) routing information temporary
left in network nodes (in case of using PIT based reverse-path approach)"

Regards,

Andrea