wiki:IcnProblemStatement

Version 22 (modified by dcorujo@…, 7 years ago) (diff)

--

ICN Research Challenges

Objective of this document: To describe the ICN problem statement, the main concepts and research challenges in depth.

Editor(s): NN
Responsible ICNRG chair: Dirk Kutscher

This page is used for getting this document started. The intention is to collect ideas, references to relevant related material and to agree on an outline of the document. It can also be used to record the status and progress of the work as well as to keep track of who is responsible for which sections.

Document outline

  1. Introduction
  2. Next section
    1. Subsection
  3. ...
  4. Conclusion

Proposed sections - not yet included in the document outline

  • problem statement about ICN operation in dynamic networks (including comparison with DTN operation) /Paulo Mendes
    • a potentially nice starting point might be Kevin Fall's presentation from last year's Global FI summit of the AsiaFI initiative. He presented a nice comparison between DTN and ICN concepts, also considering differences in ICN proposals. /Dirk Trossen
  • instrumentation, monitoring and management: how do these look like in an ICN? Essential monitoring and management tools and protocols came at least 10 years after TCP/IP was put into actual use. We should avoid this with ICN.
  • Naming guideline for different ICN platforms (e.g., CCN, NetInf, etc.): The guideline should admit principles of different platforms but help prevent the excessive divergence of different names. / Myeong
  • Mobility support: The location of a content will be changed. A device requesting a content can move while downloading the content. A device serving a content also can move. / Myeong
  • Cache management
  • Traffic engineering
  • QoS
  • ICN over native L2
  • H/W & S/W architecture of ICN router (Reality Check)
  • Compatibility with IP (or HTTP)
  • Security

Discussion on outline and overall contents of document

  • Please remove this comment when you've written the first real comment. / Börje
  • ...

Fairness Discussion

[SGB12] shows that a blind use of the Additive Increase Multiplicative Decrease (AIMD) congestion control algorithm in ICN may cause fairness issues. When AIMD is used in an ICN network less popular content throughput is massively penalised whilst the individual gain for popular content is negligible. Indeed, with AIMD, the throughput is inversely proportional to the round-trip time (RTT) and popular contents are cached closer to consumers than less popular contents hence have a shorter delay. As a result, most of the capacity is shared among the very popular contents and only a little remains for the less popular contents.

[CGM12] propose ICP, a congestion control protocol for ICN that is provably fair in term of bandwidth sharing among flows.

However, we would like to broaden ICN congestion control discussion. For that, we believe the first step is to clearly define the notion of fairness. Indeed, to properly design a congestion control mechanism for ICN, we first have to define what fairness is in an ICN network. The related work [BDA+12] proposes different fairness perspectives for multipath environments. So in the following, we start a brief discussion on fairness.

  1. Flow fairness: bandwidth allocation is identical for every flow (router/link level).
  2. Content fairness: bandwidth allocation is identical for every content (router/link level).
  3. Customer fairness: bandwidth allocation is identical for every customer, independently of its demands (router/link level).
  4. Link/interface fairness: bandwidth allocation is identical for every "demand link" (router/link level). For example, if a router receives demands on two interfaces and have one outgoing interface, all the demands from one in-interface obtain half of the capacity of the out-interface.
  5. Network fairness: bandwidth allocation is identical for every flow on a path (path level).

There are two classes of techniques for congestion control. Either the rate is controlled directly by the consumer (i.e., the client) (or the producer (i.e., the server)). Or the rate is controlled at the network level by the intermediate nodes or routers. Both solutions have their pros and cons and a solution might be to combine both techniques. For example, in most of ICN proposals, it is challenging for a router to determine the real number of flows or consumers hidden behind a demand as demands might have been aggregated earlier on the path. On the contrary, it is hard for a consumer to determine delay or to figure out where congestion occurs.

But maybe the first step is to define flow!

slides: [20121107_fairness_discussion_icnrg.pdf]

Links and references to material relevant to this document

  • [BDA+12] M. Becke, T. Dreibholz, H. Adhari, and E. P. Rathgeb. On the Fairness of Transport Protocols in a Multi-Path Environment. In IEEE ICC, 2012.
  • [CGM12] G. Carofiglio, M. Gallo, and L. Muscariello. ICP: Design and evaluation of an interest control protocol for content-centric networking. In IEEE INFOCOM, NOMEN Worshop, 2012.
  • [SGB12] D. Saucez, L. A. Grieco, and C. Barakat. AIMD and CCN: past and novel acronyms working together in the Future Internet. In ACM CoNEXT 2012, CSWS Workshop, 2012.

People interested in contributing to this document

Name E-mail Interest/Topic
Börje Ohlman Borje.Ohlman at ericsson.com What can ICN do for applications
Damien Saucez damien.saucez at inria.fr Congestion/fairness, Routing, Security
Kostas Pentikousis k.pentikousis at huawei.com Instrumentation/monitoring/management
Myeong-Wuk Jang myeong.jang at samsung.com ICN platform/services
Suyong Eum suyong at nict.go.jp ICN routing / caching
Daniel Corujo dcorujo at av.it.pt management/monitoring/IoT
NN NN at foo.com xxx

Return to the main ICNRG Wiki

The official ICNRG web page can be found at http://irtf.org/icnrg

Attachments (1)

Download all attachments as: .zip