Re: [icnrg] I-D Action: draft-irtf-icnrg-challenges-03.txt

[Dirk Kutscher <[e-mail]>]

Hi all,

we have updated the challenges draft to reflect the comments we received from the IRSG review.

The detailed changes are as follows:


> Meta:
> 
> 1. The document has a heavy caching focus and seems to imply that
>     caching is the main reason to deploy ICNs.  I suggest softening
>     that.  We have seen papers showing that today's Internet infra
>     gets quite close and so this shouldn't be the prime sales argument.
> 
>     I do realize that a lot of research focuses on caching these days
>     but maybe this in particular could encourage the RG to look beyond.
>     It is obviously a decision of the authors and the group where to go
>     but I believe we are missing a bit here.  (I am happy to see that
>     the draft also puts quite some emphasis on naming.)

We have addressed this by removing most of the caching-related text in the introduction. 

We renamed section 2 to " Problems with Host-Centric Communications" (was "Problems with Information Distribution Today") to better reflect the general purpose idea.

We also added the following text as the final paragraph of section 2:
"Host-centric communication systems restrict applications to data transfer between end-hosts only. Naming data directly provides a powerful "hook" for applications to exploit and natively support multi-party communication, e.g., multi-source - multi-destination communication and a ubiquitous information ecosystem that is not restricted to end-host addresses."
 
> 2. The introduction (and a few other places) seem to connect ICN with
>     M2M without too much justification.  While the case for the caching
>     can at least be made -- and is made -- M2M appears like having been
>     dropped in later on.  This isn't round and no real justification is
>     given.  Considering that we do have two drafts that discuss issues
>     with ICN and M2M, I would suggest keeping M2M in the challenges
>     part but removing it from the intro.  On the challenges side, the
>     M2M part is not very strong either, especially since only some
>     minimal (and rather boring) aspects are covered.

We have removed the high-level M2M text from the intro and section 2.


>     Btw, IoT appears to be a different quality of an application
>     compared to, say, video streaming.  So, I would not list this
>     as 4.9.3. but rather similar to wireless networking, so one
>     level up.  Especially since the entire definition of content
>     or functions or whatever for IoT doesn't that easily subsume
>     under the label of an application.


We tried this, but after some discussion, finally reverted to the old structure, because exposing IoT on the higher level (compared to the other application areas) looked strange. However, we have changed the title of section 4.9 from "Application Development" to "ICN Applications", which seems to reflect the content better.


>     And it would be worthwhile to mention a few more of the issues.
>     So how to map physical resources to the ICN space?

Yup, we have added more issues to the Internet of Things section
Concretely: 
[Old]
Moreover, key characteristics of the ICN underlying operation also
   impact important aspects of IoT, such as caching at network
   forwarding entities (which raise issues, e.g., concerning the
   freshness of the information received from the cache in contrast to
   the last value generated by a sensor) as well as pushing content to
   specific nodes (e.g., for controlling them), which requires
   individual addressing for identification.

[New]
   Moreover, key characteristics of the ICN underlying operation also
   impact important aspects of IoT, such as the caching in content
   storage of network forwarding entities.  This allows the
   simplification of ICN-based IoT application development, since the
   network is able to act on named content, generic names provide a way
   to address content independently of the underlying device (and
   access) technology, and bandwidth consumption is optimized due to the
   availability of cached content.  However, these aspect raise
   challenges themselves, concerning the freshness of the information
   received from the cache in contrast to the last value generated by a
   sensor, as well as pushing content to specific nodes (e.g., for
   controlling them), which requires individual addressing for
   identification.  In addition, due to the heterogeneous nature of IoT
   nodes, their processing capabilities might not be able to handle the
   necessary content signing verification procedures.


>     Also: since you mention network management: how close is NM
>     to IoT and where conceptually similar or different?  After all,
>     both deal with sensors and actuators.

We added some text on IoT management to the network management section.


> 3. The document seems to assume that the 1:1 request-response model is
>     the universal abstraction for ICNs.  But this doesn't do all
>     architectures even justice.  We do have native pub/sub architectures
>     that are different (and where you don't have to jump through hoops
>     to build pub/sub on top of req/rsp.  There is support for PUSH
>     style operation in some architectures.  The same holds for request
>     aggregation, which may but need not happen.
> 
>     I don't quite know how to get around the problem that there are
>     notably different systems out there and we try to write a common
>     challenges document.  But let me flag this nevertheless.

The term, request/response, appears in Section 3.2, Section 4.9.1, and Section 4.9.3. Since the comment seems to point out the paragraph in the section 3.2, we revise the paragraph as follows:

[Old]
The request/response model and ubiquitous in-network storage also enable new options for implementing transport services, i.e., reliable transmission, flow control, etc.  First of all, a request/response model can enable receiver-driven transport regimes, i.e., receivers (the requestors of NDOs) can control message sending rates by regulating the request sending rate (assuming that every response message has to be triggered by a request message).  Retransmission would be achieved by resending requests, e.g., after a timeout. Because objects can be replicated, object transmission and transport sessions would not necessarily have end-to-end semantics: requests can be answered by caches, and a node can select one or multiple next-hop destinations for a particular request depending on configuration, observed performance or other criteria.

[New]
ICN potentially retrieves segments of NDOs from multiple data sources, and so only a requestor can determine the completion of a retrieval process, i.e., the retrieval of NDOs or individual segments is typically controlled by a requestor. For this reason, ICN transport protocols are typically based on a receiver-driven mechanism: requestors can control message sending rates by regulating the request sending rate (assuming that every response message has to be triggered by a request message). Retransmission would be achieved by resending requests, e.g., after a timeout. Because objects can be replicated, object transmission and transport sessions would not necessarily have end-to-end semantics: requests can be answered by caches, and a node can select one or multiple next-hop destinations for a particular request depending on
configuration, observed performance or other criteria.	

 
> Smaller:
> 
> 3.2: TCP using ACK clocking seems to be a flavor of the receiver-driven
>       behavior mentioned here that would be enabled.  And there were
>       quite a few transport protocol flavors that explicitly focused on
>       the receiver side being in control.


Certainly, the receiver-driven approach of ICN seems to be from TCP using ACK clocking since several ICN congestion mechanisms adopted TCP like congestion control mechanism, e.g., [HRICP]. 

At the same time, another important reason why ICN is established based on the receiver-driven approach is that ICN potentially retrieves the segments of NDO from multiple data sources, and so only receiver knows the completion of the retrieval. For this reason, the transport protocol of ICN is based on a receiver-driven mechanism.

The paragraph above is already a part of the response to your third comment.

 
> 4.1: The bullet on names for content not generated before refers
>       to "self-certified names as described above".  I don't think that
>       this was actually explained above; rather to the contrary.

We added the following explanation

In Sec 4.1.,
[old]
Self-certifying names are not human readable nor hierarchical. They can however provide some structure for aggregation, for instance, a name part corresponding to a publisher.

[New]
Self-certifying names are not human readable nor hierarchical. They can however provide some structure for aggregation, for instance, a name part corresponding to a publisher. In self-certifying names, the key of the publisher is bound to the name of NDO, and so when a user receives, e.g., the triplet namely [data, key, signature], the user can immediately verify that the data actually are from the publisher, i.e., the origin of the NDO, by cryptographically hashing the received key and the name of NDO, and comparing it with acquainted hashed key. Then, the key can be used to verify the signature, i.e., the integrity and provenance of the NDO.


> 4.3: Somehow the challenges get less and less mature with the evolution
>       of this section.  Isn't there more to say on hybrid routing?
>       4.3.3 appears weak.

OK, we have extended the text on challenges of HR as follows:

[old]
HR combines RBNR and LBNR to benefit from their advantages.  For instance, within a single administrative domain, e.g., an ISP, where scalability issues can be addressed with network planning, RBNR can be adopted to reduce overall latency by omitting the resolution process. On the other hand, LBNR can be used to route between domains which have their own prefix (locator).

A challenge specific to HR is: How can we design a scalable mapping system which, given the name of a data object, should return a destination domain locator so that a user request can be encapsulated and forwarded to the domain?

[new]
HR combines RBNR and LBNR to benefit from their advantages. Within a single administrative domain, e.g., an ISP, where scalability issues can be addressed with network planning, RBNR can be adopted to reduce overall latency by omitting the resolution process. On the other hand, LBNR can be used to route between domains which have their own prefix (locator).

For instance, a request message initially includes the name of NDO for the operation of RBNR, and is forwarded to a cached copy of the NDO or the original server. When the request message fails to find a routing entry in the router, a name resolution step kicks in to translate the name into its locator before forwarding the request message based on the retrieved locator. 

Challenges specified to HR are:

How can we design a scalable mapping system which, given the name of NDO, should return a destination domain locator so that a user request can be encapsulated and forwarded to the domain?

How to secure the mapping information to prevent a malicious router from hijacking the request message by chaining its locator?

How to maintain the bind between the name and the content of NDO for the verification of its origin and integrity when the name changes due to the retrieved locator?


> 4.5: One interesting question could be: how would ICN have been designed
>       if people would have had (only) wireless in mind from the outset?

Interesting question. We'd rather discuss this in another document.


> 4.6: Shameless advertising, but at least the tech report would be
>       worthwhile mentioning as it predates the present ref by one year
>       and it dissects the issue of RTT estimates quite nicely.
> 
>       Somaya Arianfar, Pekka Nikander, Lars Eggert, Jörg Ott, Walter
>       Wong: ConTug: A Receiver-Driven Transport Protocol for Content-
>       Centric Networks. Technical Report, Aalto University Comnet, July
>       2011.

Thanks, we have included the reference.

> 4.6: last para: the req aggregation part just doesn't fit in here.
>       It's important but should move to a different section.  Maybe
>       towards applications or even a layer up?

We removed the last paragraph.

> 
> Nits:
> 
> Abstract: "researcg"

fixed

> Sec 1. I would talk about consistently about named data or data object
>     but not use the qualitative different word "information" in this
>     context.

Fixed (named data)

> Sec 2. Should one mention time-shifted multicast and broadcast due to
>     the caching properties?

Section 2 describes the problems with current information distribution systems, especially due to their overlay style deployment.

In current information distribution systems, time-shifted multicast known as video-on-demand has been achieved either by unicast communications or by distributed local caches where video segments are stored and streamed to the requesting users asynchronously. Since the latter, the caching approach, is realized in an overlay style today, its problems are almost identical to the listed problems in the Section 2.

Thus, we think that we do not need further elaboration regarding the problems of time-shifted multicast support in current information distribution systems.


> Sec 3.1: "interchangeabl_y_"

fixed

> Sec 3.2: ICN supports encryption?  Well, it could, but not by default
>     in many cases.

We agree that it could, but not by default.

In Sec 3.2, it says that

"ICN can support other security services, such as provenance validation, and encryption, depending on the details of naming schemes, object models and assumptions on infrastructure support."

In our view this should be clear.


> Sec 4.1: I don't think that flat name space hve to be self-certifying.

As we described in Sec 4.2.1, there are two main approaches to distribute the key of publisher; one is based on an external third party authority such as hierarchical Public Key Infrastructure (PKI) [RFC5280] and the other is to adapt a self-certifying scheme. Thus, flat name space does not have to be self-certifying.

> Sec 4.7.1: "memories" -> "memory"
>             "which increase" -> "which increases"

fixed

> Sec 4.8: "from which the management process can also leverage upon"
>           "by in"
> 
Fixed


Best regards,
Dirk


> -----Original Message-----
> From: icnrg [mailto:[e-mail]] On Behalf Of internet-
> [e-mail]
> Sent: Dienstag, 15. Dezember 2015 09:16
> To: [e-mail]
> Cc: [e-mail]
> Subject: [icnrg] I-D Action: draft-irtf-icnrg-challenges-03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Information-Centric Networking Working Group
> of the IETF.
> 
>         Title           : ICN Research Challenges
>         Authors         : Dirk Kutscher
>                           Suyong Eum
>                           Kostas Pentikousis
>                           Ioannis Psaras
>                           Daniel Corujo
>                           Damien Saucez
>                           Thomas C. Schmidt
>                           Matthias Waehlisch
> 	Filename        : draft-irtf-icnrg-challenges-03.txt
> 	Pages           : 34
> 	Date            : 2015-12-15
> 
> Abstract:
>    This memo describes research challenges for Information-Centric
>    Networking (ICN), an approach to evolve the Internet infrastructure
>    to directly support information distribution by introducing uniquely
>    named data as a core Internet principle.  Data becomes independent
>    from location, application, storage, and means of transportation,
>    enabling or enhancing a number of desirable features, such as
>    security, user-mobility, multicast and in-network caching.  This
>    document describes the the research challenges in ICN, including
>    naming, security, routing, system scalability, mobility management,
>    wireless networking, transport services, in-network caching, and
>    network management.
> 
>    This document is a product of the IRTF Information-Centric Networking
>    Research Group (ICNRG).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-irtf-icnrg-challenges/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-irtf-icnrg-challenges-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-irtf-icnrg-challenges-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg