IcnBaselineScenarios: draft-pentikousis-icn-scenarios-00.txt

File draft-pentikousis-icn-scenarios-00.txt, 24.4 KB (added by k.pentikousis@…, 10 years ago)

First draft proposal for the ICN baseline scenarios

Line 
1 
2
3
4
5ICNRG                                                     K. Pentikousis
6Internet-Draft                                                    Huawei
7Intended Status: Informational                                 B. Ohlman
8Expires: May 2, 2013                                            Ericsson
9                                                        October 29, 2012
10
11
12                        ICN Baseline Scenarios
13                   draft-pentikousis-icn-scenarios-00
14
15
16Abstract
17
18   This document presents scenarios for information-centric networking
19   (ICN) which can be used to establish a common understanding about
20   potential experimental setups where different approaches can be
21   tested and compared against each other.  The scenarios are primarily
22   based on published literature, that is, they have all been considered
23   in one or more performance evaluation studies, which are already
24   available to the community.  The scenarios selected for inclusion in
25   this first draft aim to exercise a variety of aspects that an ICN
26   solution can address.  They include a) general aspects, such as,
27   network efficiency, mobility support, multicast and caching
28   performance, real-time communication efficacy, disruption and delay
29   tolerance; and b) ICN-specific aspects, such as, information security
30   and trust, persistence, availability, provenance, and location
31   independence.
32
33
34Status of this Memo
35
36   This Internet-Draft is submitted to IETF in full conformance with the
37   provisions of BCP 78 and BCP 79.
38
39   Internet-Drafts are working documents of the Internet Engineering
40   Task Force (IETF), its areas, and its working groups.  Note that
41   other groups may also distribute working documents as
42   Internet-Drafts.
43
44   Internet-Drafts are draft documents valid for a maximum of six months
45   and may be updated, replaced, or obsoleted by other documents at any
46   time.  It is inappropriate to use Internet-Drafts as reference
47   material or to cite them other than as "work in progress."
48
49   The list of current Internet-Drafts can be accessed at
50   http://www.ietf.org/1id-abstracts.html
51
52   The list of Internet-Draft Shadow Directories can be accessed at
53 
54
55
56Pentikousis & Ohlman      Expires May 2, 2013                   [Page 1]
57
58INTERNET DRAFT           ICN Baseline Scenarios         October 29, 2012
59
60
61   http://www.ietf.org/shadow.html
62
63
64Copyright and License Notice
65
66   Copyright (c) 2012 IETF Trust and the persons identified as the
67   document authors. All rights reserved.
68
69   This document is subject to BCP 78 and the IETF Trust's Legal
70   Provisions Relating to IETF Documents
71   (http://trustee.ietf.org/license-info) in effect on the date of
72   publication of this document. Please review these documents
73   carefully, as they describe your rights and restrictions with respect
74   to this document.
75
76
77
78Table of Contents
79
80   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  2
81   2  ICN Baseline Scenarios  . . . . . . . . . . . . . . . . . . . .  3
82     2.1  Social Networking . . . . . . . . . . . . . . . . . . . . .  3
83     2.2  Real-time A/V Communications  . . . . . . . . . . . . . . .  4
84     2.3  Mobile Networking . . . . . . . . . . . . . . . . . . . . .  5
85     2.4  Infrastructure Sharing  . . . . . . . . . . . . . . . . . .  6
86     2.5  Content Dissemination . . . . . . . . . . . . . . . . . . .  7
87     2.6  Energy Efficiency . . . . . . . . . . . . . . . . . . . . .  8
88     2.7  Delay and Disruption Tolerance  . . . . . . . . . . . . . .  8
89   3  Security Considerations . . . . . . . . . . . . . . . . . . . .  8
90   4  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  8
91   5  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .  8
92   6  Informative References  . . . . . . . . . . . . . . . . . . . .  9
93   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
94
95
96
971  Introduction
98
99   Information-centric networking (ICN) marks a fundamental shift in
100   communications and networking.  In contrast with the omnipresent, and
101   very successful we may add, host-centric paradigm, based on perpetual
102   connectivity and the end-to-end principle, ICN changes the focal
103   point of the network architecture from the "end host" to
104   "information" (or content, or data).  In this paradigm, connectivity
105   can be intermittent in general; end-host and in-network storage can
106   be capitalized upon transparently as bits in the network and on some
107   storage device have exactly the same value; mobility, multicasting
108   and multiaccess are supported by default; and energy efficiency is a
109 
110
111
112Pentikousis & Ohlman      Expires May 2, 2013                   [Page 2]
113
114INTERNET DRAFT           ICN Baseline Scenarios         October 29, 2012
115
116
117   design consideration from the beginning. 
118
119   Although interest in ICN is growing rapidly, ongoing work on
120   different architectures, such as, for example, NetInf [NetInf], CCN
121   and NDN [CCN], the publish-subscribe Internet (PSI) architecture
122   [PSI], and the data-oriented architecture [DONA] is far from being
123   completed.  The increasing interest and the plethora of ICN
124   approaches make this a very active research area but, on the
125   downside, it makes it more difficult to compare different proposals
126   on an equal ground.
127
128   It is not uncommon that different researchers select different
129   performance evaluation scenarios in order to highlight the advantages
130   of their approach.  This is reasonable and should be expected to some
131   degree.  As Ahlgren et al. note [SoA], describing these architectures
132   is akin to shooting a moving target.  We find that comparing these
133   different approaches is often even more tricky.  Nevertheless,
134   certain scenarios seem to emerge where said ICN architectures could
135   showcase their superiority over current systems, in general, and
136   against each other, in particular.
137
138   This document collects several scenarios from the published ICN
139   literature and aims to use them as foundation for the baseline
140   scenarios to be considered by the IRTF Information-Centric Networking
141   Research Group (ICNRG) in its future work.  The list of scenarios can
142   obviously change, as input from the research group is received.
143
144
1452  ICN Baseline Scenarios
146
147   This section presents a number of scenarios grouped into several
148   categories.  Note that certain evaluation scenarios span across these
149   categories, so the boundaries between them should not be considered
150   rigid and inflexible.  The goal is that each scenario should be
151   described at a sufficient level of detail so that it can serve as the
152   base for comparative evaluations of different approaches.  This will
153   need to include reference configurations, specifications of traffic
154   mixes and traffic loads.  These specifications/configurations should
155   preferably come as sets that describe extremes as well as "typical"
156   usage scenarios.
157
158
1592.1  Social Networking
160
161   Social networking applications proliferated over the past decade
162   based on overlay content dissemination systems that require large
163   infrastructure investments to rollout and maintain.  Content
164   dissemination is at the heart of the ICN paradigm and, therefore, we
165 
166
167
168Pentikousis & Ohlman      Expires May 2, 2013                   [Page 3]
169
170INTERNET DRAFT           ICN Baseline Scenarios         October 29, 2012
171
172
173   would expect that they are a "natural fit" for showcasing the
174   superiority of ICN over traditional client-server TCP/IP-based
175   systems.
176
177   Mathieu et al. [ICN-SN], for instance, illustrate how an ISP can
178   capitalize on CCN to deploy a short-message service akin to Twitter
179   at a fraction of the complexity of today's systems.  Their key
180   observation is that such a service can be seen as a combination of
181   multicast delivery and caching.  That is, a single user addresses a
182   large number of recipients, some of which receive the new message
183   immediately as they are online at that instant, while others receive
184   the message whenever they connect to the networks.
185
186   Earlier work by Arianfar et al. [CCR] considers a similar pull-based
187   content retrieval scenario using a different architecture, pointing
188   to significant performance advantages.  Although the authors consider
189   a different network topology and do not explicitly say that their
190   evaluation scenario is addressing social networking, the similarities
191   are easy to spot: "followers" obtain content put "on the network" by
192   a single user relying solely on network primitives.  That is, in both
193   evaluations there is no need for a classic client-server architecture
194   (let alone a cloud-based infrastructure) to intermediate between
195   content providers and consumers.
196
197   This scenario aims to exercise each ICN architecture in terms of
198   network efficiency, multicast support, and caching performance.
199
200
2012.2  Real-time A/V Communications
202
203   Real-time audio and video (A/V) communications include an array of
204   services ranging from one-to-one voice calls to multi-party multi-
205   media conferences with video and whiteboard support to augmented
206   reality.  Real-time communications have been studied (and deployed
207   widely) in the context of packet- and circuit-switched networks for
208   decades.  The stringent quality of service requirements that this
209   type of communication imposes on network infrastructure is well-
210   known.  However, the ICN community has, so far, only scratched the
211   surface of this area with respect to illustrating the benefits of
212   adopting an information-centric approach as opposed to a host-centric
213   one.
214
215   Notably,  Jacobson et al. [VoCCN] presented an early evaluation where
216   the performance of a VoIP call over an information-centric approach
217   was compared with that of an off-the-shelf VoIP implementation using
218   RTP/UTP.  The results indicated that despite the extra cost of adding
219   security support in the former case, performance was virtually
220   identical in the two cases evaluated in a testbed.  However, the
221 
222
223
224Pentikousis & Ohlman      Expires May 2, 2013                   [Page 4]
225
226INTERNET DRAFT           ICN Baseline Scenarios         October 29, 2012
227
228
229   experimental setup was was quite rudimentary and the evaluation
230   considered a single voice call only.  This scenario does illustrate
231   that VoIP is feasible with at least one ICN approach, but it would
232   need to be further enhanced to include more comprehensive metrics as
233   well as standardized call arrival patterns, for example, following
234   well-established methodologies from the quality of service/experience
235   (QoS/QoE) evaluation toolbox.
236
237   Given the wide-spread deployment of real-time A/V communications, an
238   ICN approach should show not only feasibility but highlight that
239   complexity is significantly reduced when compared to a classic IP-
240   based A/V application.  For example, with respect to multimedia
241   conferencing, Zhu et al. [ACT] describe the design of a distributed
242   audio conference tool based on NDN.  The design includes ICN-based
243   conference discovery, speakers discovery and voice data distribution.
244   The reported evaluation results point to gains in scalability and
245   security.  Moreover, Chen et al. [G-COPSS] explore the feasibility of
246   implementing a Massively Multiplayer Online Role Playing Game
247   (MMORPG) based on CCNx and show that stringent temporal requirements
248   can be met while scalability is significantly improved when compared
249   to an IP client-server system.
250
251   In short, scenarios in this category should illustrate not only
252   feasibility but increased scalability, reliability, and capacity to
253   meet stringent QoS/QoE requirements when compared to established
254   host-centric solutions.
255
256
2572.3  Mobile Networking
258
259   IP mobility management relies on mobility anchors to provide
260   ubiquitous connectivity to end-hosts as well as moving networks.
261   This is a natural choice for a host-centric paradigm that requires
262   end-to-end connectivity and continuous network presence [SCES].  An
263   implicit assumption in host-centric mobility management frameworks is
264   that the mobile node aims at connecting to a particular peer, not at
265   retrieving information [EEMN].  However, with ICN new ideas about
266   mobility management should come to the forefront, which capitalize on
267   the different nature of the paradigm.
268
269   For example, Dannewitz et al. [N-Scen], consider a scenario where a
270   multiaccess end-host can retrieve email securely using a combination
271   of cellular and wireless local area network connectivity.  This
272   scenario borrows elements from previous work, e.g. [DTI], and
273   develops them further with respect to multiaccess.  Unfortunately,
274   Dannewitz et al. [N-Scen] do not present any results demonstrating
275   that an ICN approach is indeed better.  That said, the scenario is
276   interesting as it considers content specific to a single user (i.e.
277 
278
279
280Pentikousis & Ohlman      Expires May 2, 2013                   [Page 5]
281
282INTERNET DRAFT           ICN Baseline Scenarios         October 29, 2012
283
284
285   her mailbox) and does point to a decrease in complexity.  It is also
286   compatible with recent work in the Distributed Mobility Management
287   (DMM) Working Group within the IETF.  Finally, Xylomenos et al.
288   [PSIMob] as well as [EEMN] argue that an information-centric
289   architecture can avoid the complexity of having to manage tunnels to
290   maintain end-to-end connectivity as is the case with mobile anchor-
291   based protocols such as Mobile IP (and its variants).
292
293   Overall, mobile networking scenarios have not been developed in
294   detail, let alone evaluated in a wide scale.  We expect that in the
295   coming period more papers will address this topic, each perhaps
296   proposing its own evaluation scenario.  The scenarios in mobile
297   networking will be naturally coupled with those discussed in the
298   previous sections as more users access social networking and A/V
299   applications through mobile devices.
300
301   Mobile networking scenarios should aim to exercise service continuity
302   for those applications that require it, decrease complexity and
303   control signaling for the network infrastructure, as well as increase
304   wireless capacity utilization by taking advantage of the broadcast
305   nature of the medium. 
306
307
3082.4  Infrastructure Sharing
309
310   A key idea in ICN is that the network should secure information
311   objects per se, not the communications channel that they are
312   delivered over.  This means that hosts attached to an information-
313   centric network can share resources in an unprecedented scale,
314   especially when compared to what is possible in an IP network.  All
315   devices with network access and storage capacity can contribute their
316   resources increasing the value of an information-centric network
317   (perhaps) much faster than Metcalfe's law.
318
319   For example, Jacobson et al. [CBIS] argue that in ICN the "where and
320   how" to obtain information are new degrees of freedom.  They
321   illustrate this with a scenario involving a photo sharing application
322   which takes advantage of whichever access network connectivity is
323   available at the moment (WLAN, Bluetooth, and even SMS) without
324   requiring a centralized infrastructure to synchronize between
325   numerous devices.  It is important to highlight that since the focus
326   of the communication changes, keep-alives in this scenario are simply
327   unnecessary, as devices participating in the testbed network
328   contribute resources in order to maintain user content consistency,
329   not link state information as is the case in the host-centric
330   paradigm.  This means that the notion of "infrastructure" may be
331   completely different in the future.
332
333 
334
335
336Pentikousis & Ohlman      Expires May 2, 2013                   [Page 6]
337
338INTERNET DRAFT           ICN Baseline Scenarios         October 29, 2012
339
340
341   Carofiglio et al., for instance, present early work on an analytical
342   framework that attempts to capture the storage/bandwidth tradeoff and
343   can be used as a basis for a network planning tool [SHARE].  In
344   addition, Chai et al. [CL4M] explore the benefits of ubiquitous
345   caching throughout an information-centric network and argue that
346   "caching less can actually achieve more."  These two papers indicate
347   that there is a lot of work to be done in the area of how to use
348   optimally all resources that end hosts bring into the network.
349
350   Scenarios in this category, therefore, would cover the
351   communication/computation/storage tradeoffs that an ICN network
352   deployment must consider, including network planning, perhaps
353   capitalizing on user-provided resources, as well as operational and
354   economical aspects to illustrate the superiority of ICN over other
355   approaches, including federations of IP-based CDNs.
356
357
3582.5  Content Dissemination
359
360   Content dissemination has attracted more attention than other aspects
361   of ICN, perhaps due to a misunderstanding of what the first "C" in
362   CCN stands for.  Decentralized content dissemination with on-the-fly
363   aggregation of information sources was envisaged in [N-Scen] where
364   information objects can be dynamically assembled based on
365   hierarchically structured subcomponents.  For example, a video stream
366   could be associated with different audio streams and subtitle sets,
367   which all can be obtained from different sources.  Semantics and
368   content negotiation, on behalf of the user was also considered, e.g.
369   for the case of popular tunes.  Effectively this scenario has the
370   information consumer issuing independent requests for content based
371   on information identifiers, and stitching the pieces together
372   irrespective of "where" or "how" they were obtained.
373
374   Content dissemination scenarios have a large overlap with the
375   scenarios described above [DONA, PSI, PSI-Mob, NetInf, CCN, CBIS,
376   CCR], just to name a few.  In addition, Chai et al. present a hop-by-
377   hop hierarchical content resolution approach [CURLING], which employs
378   receiver-driven multicast over multiple domains, advocating another
379   content dissemination approach.
380
381   Scenarios in this category abound in the literature, including stored
382   and streaming A/V distribution, file distribution, mirroring and bulk
383   transfers, SVN-type of services, as well as traffic aggregation.  We
384   expect that in particular for content dissemination both extreme as
385   well as typical scenarios can be specified drawing data from current
386   CDN deployments.
387
388
389 
390
391
392Pentikousis & Ohlman      Expires May 2, 2013                   [Page 7]
393
394INTERNET DRAFT           ICN Baseline Scenarios         October 29, 2012
395
396
3972.6  Energy Efficiency
398
399   As mentioned earlier, energy efficiency can be tackled by ICN in ways
400   that it cannot in a host-centric paradigm.  For example, the work by
401   Guan et al. [EECCN] indicates that CCN may be much more energy-
402   efficient that traditional CDNs for delivering popular content given
403   the current networking equipment energy consumption levels. 
404
405   Evaluating energy efficiency does not require the definition of new
406   scenarios, but does require the establishment of clear guidelines so
407   that different ICN approaches can be compared not only in terms of
408   scalability, for example, but also in terms to power consumption.
409
410
4112.7  Delay and Disruption Tolerance
412
413   Delay Tolerant Networking (DTN) [DTN] was originally designed for
414   special use cases, such as interstellar networking, use of data
415   mules, and so on.  With the advent of sensor networks and peer-to-
416   peer (P2P) networking between mobile nodes, DTN is becoming a more
417   commonplace type of networking.  ICN does not build on the familiar
418   communication abstraction of end-to-end connectivity between a set of
419   nodes.  This makes it possible to include DTN support in ICN
420   natively.  Thus it is of interest to evaluate to which extent
421   different ICN technologies can support DTN scenarios.
422
423   Important aspects to be evaluated with respect to delay and
424   disruption tolerance include, but are not limited to, name
425   resolution, routing and forwarding in disconnected parts of the
426   network; support for unidirectional links; number of round trips
427   needed to complete a data transfer, and so on.
428
429
4303  Security Considerations
431
432   TBD
433
434
4354  IANA Considerations
436
437   This document presents no IANA considerations.
438
439
4405  Acknowledgments
441
442   TBD
443
444
445 
446
447
448Pentikousis & Ohlman      Expires May 2, 2013                   [Page 8]
449
450INTERNET DRAFT           ICN Baseline Scenarios         October 29, 2012
451
452
4536  Informative References
454
455   [NetInf]   Ahlgren, B. et al., "Design considerations for a network
456              of information", Proc. CoNEXT Re-Arch Workshop. ACM, 2008.
457
458   [CCN]      Jacobson, V. et al., "Networking Named Content", Proc.
459              CoNEXT. ACM, 2009.
460
461   [PSI]      Trossen, D. and Parisis, G., "Designing and realizing an
462              information-centric internet", IEEE Commun. Mag., vol. 50,
463              no. 7, July 2012.
464
465   [DONA]     Koponen, T. et al., "A Data-Oriented (and Beyond) Network
466              Architecture", Proc. SIGCOMM. ACM, 2007.
467
468   [SoA]      Ahlgren, B. et al., "A survey of information-centric
469              networking", IEEE Commun. Mag., vol. 50, no. 7, July 2012.
470
471   [ICN-SN]   Mathieu, B. et al., "Information-centric networking: a
472              natural design for social network applications", IEEE
473              Commun. Mag., vol. 50, no. 7, July 2012.
474
475   [CCR]      Arianfar, S. et al., "On content-centric router design and
476              implications", Proc. CoNEXT Re-Arch Workshop. ACM, 2010.
477
478   [VoCCN]    Jacobson, V. et al., "VoCCN: Voice-over Content-Centric
479              Networks", Proc. CoNEXT Re-Arch Workshop. ACM, 2009.
480
481   [ACT]      Zhu, Z. et al., "ACT: Audio Conference Tool Over Named
482              Data Networking", Proc. SIGCOMM ICN Workshop. ACM, 2011.
483
484   [G-COPSS]  Chen, J. et al., "G-COPSS: A Content Centric Communication
485              Infrastructure for Gaming Applications", Proc. ICDCS.
486              IEEE, 2012.
487
488   [SCES]     Allman, M. et al., "Enabling an Energy-Efficient Future
489              Internet through Selectively Connected End Systems", Proc.
490              HotNets-VI. ACM, 2007.
491
492   [EEMN]     Pentikousis, K., "In Search of Energy-Efficient Mobile
493              Networking", IEEE Commun. Mag., vol. 48, no. 1, Jan. 2010.
494
495   [N-Scen]   Dannewitz, C. et al., "Scenarios and research issues for a
496              Network of Information", Proc. MobiMedia. ICST, 2012.
497
498   [DTI]      Ott, J. and Kutscher, D., "Drive-thru Internet: IEEE
499              802.11b for 'automobile' users", Proc. INFOCOM. IEEE,
500              2004.
501 
502
503
504Pentikousis & Ohlman      Expires May 2, 2013                   [Page 9]
505
506INTERNET DRAFT           ICN Baseline Scenarios         October 29, 2012
507
508
509   [PSIMob]   Xylomenos, G. et al., "Caching and Mobility Support in a
510              Publish-Subscribe Internet Architecture", IEEE Commun.
511              Mag., vol. 50, no. 7, July 2012.
512
513   [CBIS]     Jacobson, V. et al., "Custodian-Based Information
514              Sharing", IEEE Commun. Mag., vol. 50, no. 7, July 2012.
515
516   [SHARE]    Carofiglio, G. et al., "Bandwidth and storage sharing
517              performance in information centric networking", Proc.
518              SIGCOMM ICN Workshop. ACM, 2011.
519
520   [CL4M]     Chai, W. K. et al., "Cache 'Less for More' in Information-
521              centric Networks", Proc. Networking. IFIP, 2012.
522
523   [CURLING]  Chai, W. K. et al., "CURLING: Content-Ubiquitous
524              Resolution and Delivery Infrastructure for Next-Generation
525              Services", IEEE Commun. Mag., vol. 49, no. 3, Mar. 2011.
526
527   [EECCN]    Guan, K.  et al., "On the Energy Efficiency of Content
528              Delivery Architectures ", Proc. ICC Workshops. IEEE, 2011.
529
530   [DTN]      Fall, K., "A delay-tolerant network architecture for
531              challenged internets", Proc. SIGCOMM. ACM, 2003.
532
533
534Authors' Addresses
535
536
537   Kostas Pentikousis
538   Huawei Technologies
539   Carnotstrasse 4
540   10587 Berlin
541   Germany
542
543   Email: k.pentikousis@huawei.com
544
545   Borje Ohlman
546   Ericsson Research
547   S-16480 Stockholm
548   Sweden
549
550   Email: Borje.Ohlman@ericsson.com
551
552
553
554
555
556
557
558
559
560Pentikousis & Ohlman      Expires May 2, 2013                  [Page 10]