idnits 2.17.1 draft-jiachen-icn-pubsub-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2015) is 3338 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Fenner2005' is defined on line 523, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG M. Arumaithurai 3 Internet-Draft J. Chen 4 Intended status: Informational X. Fu 5 Expires: September 6, 2015 University of Goettingen 6 K. Ramakrishnan 7 University of California, Riverside 8 J. Seedorf 9 NEC 10 March 5, 2015 12 Enabling Publish/Subscribe in ICN 13 draft-jiachen-icn-pubsub-01 15 Abstract 17 Information-Centric Networks (ICN) provide substantial flexibility 18 for users to obtain information without regard to the source of the 19 information or its current location. Publish/subscribe (pub/sub) 20 systems have gained popularity in society to provide the convenience 21 of removing the temporal dependency of the user having to indicate an 22 interest each time he or she wants to receive a particular piece of 23 related information. Such an "information-centric" communication 24 model should be supported in the new ICN network paradigm. This 25 document outlines some research directions for ICN with respect to 26 enhancing the inherently pull-based ICN approaches for achieving 27 efficient pub/sub capability. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 6, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Pub/Sub Communication . . . . . . . . . . . . . . . . . . . . 3 65 3. Scenarios of Pub/Sub Architecture . . . . . . . . . . . . . . 4 66 3.1. Online Social Networks and RSS Feeds . . . . . . . . . . 4 67 3.2. Online Gaming and Audio/Video Conferencing . . . . . . . 4 68 3.3. Notification Systems in Disaster . . . . . . . . . . . . 5 69 4. Requirements of an Efficient Pub/Sub Architecture . . . . . . 5 70 5. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5.1. IP/Overlay Multicast . . . . . . . . . . . . . . . . . . 7 72 5.2. Named-Data Networking (NDN) . . . . . . . . . . . . . . . 8 73 5.3. CCN . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 5.4. Content-Oriented Publish/Subscribe(COPSS) . . . . . . . . 9 75 5.5. PSIRP Project . . . . . . . . . . . . . . . . . . . . . . 9 76 5.6. NetInf Project (http://www.netinf.org) . . . . . . . . . 9 77 5.7. Pursuit Project (http://www.fp7-pursuit.eu/) . . . . . . 9 78 5.8. Other Related Works . . . . . . . . . . . . . . . . . . . 9 79 6. Standardisation Considerations . . . . . . . . . . . . . . . 10 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 7.2. Informative References . . . . . . . . . . . . . . . . . 11 83 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 This document points out the need to support publish/subscribe (pub/ 89 sub) capabilities in ICN and the problems with the existing 90 solutions. Further, the document discusses potential directions for 91 enhancing Information Centric Networking (ICN) to achieve efficient 92 pub/sub. 94 Section 2 describes the pub/sub systems and the challenges of such 95 systems to the current Internet. Section 3 demonstrates the use of 96 pub/sub systems in different scenarios. Section 4 outlines the 97 requirements of an efficient pub/sub architecture and Section 5 98 discusses the related works and some possible shortcomings. In 99 Section 6 we brief our standardisation considerations. 101 2. Pub/Sub Communication 103 Users increasingly desire access to information, ranging from news, 104 financial markets, healthcare, to disaster relief and beyond, 105 independent of who published it, where it is located, and often, when 106 it was published. Typical representation of these usages are 107 microblogs, RSS feed, social network, search engines, etc. A 108 consumer may not wish (or it may even be infeasible) to receive all 109 of the "channels" belonging to a myriad of information providers that 110 disseminate items of interest, either on demand (such as web, 111 twitter, blogs and social networks), or tune to a broadcast channel 112 (e.g., television, radio, newspaper). In these cases, the consumer 113 would rather prefer obtaining the data based on Content Descriptors 114 (CD) such as a keyword, a tag, or a property of the content 115 (publisher identity, published date etc.). 117 Publish/subscribe (pub/sub) systems are particularly suited for such 118 kind of large scale content-oriented information dissemination, and 119 provide the exibility for users to subscribe to information of 120 interest, without being intimately tied to when that information is 121 made available by publishers. With the use of an appropriate 122 interface, users can select and filter the information desired so 123 that they receive only what they are interested in, often 124 irrespective of the publisher. 126 Intelligent end-systems and information aggregators (e.g., Google 127 News and Yahoo! News, cable and satellite providers) have 128 increasingly adapted their interfaces to provide a content-oriented 129 pub/sub-based delivery method. However, these mechanisms are built 130 on top of a centralized server based framework and can also result in 131 a waste of network resources as shown in 132 [Ramasubramanian2006][Katsaros2011], since the Internet protocol 133 suite is focused on end-to-end delivery of data. Furthermore, issues 134 of "coverage" and "timeliness" still exist in such forms of 135 dissemination, where the aggregator may be selective in what 136 information is made available. 138 Information-Centric Networks (ICN) is a new network paradigm that 139 intendeds to achieve large scale data delivery with greater ease for 140 users, greater scalability in terms of the amount of information 141 disseminated as well as number of producers and consumers of 142 information, and greater efficiency in terms of network and server 143 resource utilization. 145 It is also desirable for such a network to assist the pub/sub 146 communication model that delivers the information from any of the 147 producers to all subscribers. Moreover, it is desirable for the 148 network to assist in delivering fine-grained information to the 149 subscriber. 151 Recently, works such as 152 [Schmidt2012],[Carzaniga2011],[Chen2011],[Chen2012] have also 153 highlighted the need for ICN to support a pub/sub like communication 154 model. 156 3. Scenarios of Pub/Sub Architecture 158 In this section, we list several use cases of pub/sub architectures 159 in ICN. They help us to understand the requirements of an efficient 160 pub/sub architecture and why the existing solutions fall short. 162 3.1. Online Social Networks and RSS Feeds 164 Online social networks (e.g., Twitter, Facebook, etc.) and Rich Site 165 Summary (RSS) feeds are typical use cases for a content-centric pub/ 166 sub system. In such systems, the receivers receive messages either 167 from friends, followees, or from some information aggregators. They 168 do not care which exact machine is sending the message (content- 169 centric), nor do they know when and what is the name of the next 170 message they are going to receive (temporal separation). 172 To prevent the receivers from polling all the possible providers, 173 existing systems use web servers as rendezvous points: the publishers 174 send new messages to the servers and the receivers/subscribers poll 175 the server periodically. This still causes great wastage for the 176 (HTTP) servers answering "304 - Not Modified" repeatedly since the 177 message update frequency is usually lower than the polling frequency. 179 3.2. Online Gaming and Audio/Video Conferencing 181 Massively multiplayer online role-playing games (MMORPGs, e.g., 182 Counter-Strike, Quake, World of Warcraft, etc.) and audio/video 183 conferencing (e.g., Skype meeting, Web Whiteboard, Etherpad, etc.) is 184 another kind of content-centric pub/sub systems. Similar to the 185 social network scenario, users in such systems only care about the 186 content, either the area of interest (AoI) or the conference 187 partners, and they do not know when and from where the next message 188 will come. But different from the previous scenario, such systems 189 require real-time update (message) delivery and these messages are 190 usually smaller in size compared to the online social networks. 192 Many of these systems choose to use HTTPS or direct TCP connection 193 between the server and the users to enable the capability of server 194 "pushing" the updates to the user. But maintaining such links are 195 costly. MMORPGs usually limit the number of players in a same game 196 which greatly reduces the interesting of these games. 198 3.3. Notification Systems in Disaster 200 Disasters have often disrupted communications because of damages to 201 critical infrastructure. For instance in the aftermath of the 202 Japanese Earthquake in 2011, approximately 1,200,000 fixed telephone 203 lines and 15,000 base-stations were not functioning. On average, 22% 204 (with peaks up to 65% in some areas) of the base-stations had to shut 205 down due to the lack of power or damages to the infrastructure. 207 Contradictory to the loss of available hardware capacity, during and 208 in the aftermath of a disaster, there is a substantial increase in 209 the amount of traffic generated because of the natural anxiety and 210 panic among people and the need to organize rescue and emergency 211 services. Many of these traffic are in the form of a pub/sub 212 communication model, e.g., the government needs to publish some 213 notifications (recovery status, new shelter locations, etc.), the 214 refugees need to notify their friends about their safety, or people 215 needs to ask for help from ambulances or fire brigade. In the 216 Japanese case, the congestion caused by such traffic resulted in 217 restrictions in voice traffic up to 95%, including emergency priority 218 calls. 220 4. Requirements of an Efficient Pub/Sub Architecture 222 Given a pub/sub communication model as described in Section 2, on a 223 high-level one can derive the following (incomplete) list of basic 224 requirements: 226 o Decouple publishers and subscribers: In an ideal pub/sub 227 environment, publishers only focus on their core task of 228 publishing while not having to maintain membership status, and 229 subscribers receive content from a multitude of sources without 230 having to worry about maintaining a list of publishers and 231 frequently polling them for the availability of fresh data. 232 Moreover, a consumer may not wish (and it may even be infeasible) 233 to subscribe to all of the channels belonging to a myriad of 234 information providers that disseminate items of interest, either 235 on demand (such as web, twitter, blogs and social networks), or 236 tune to a broadcast channel (e.g., television, radio, newspaper). 238 In these cases, support should be provided to the consumer who 239 would prefer obtaining the data based on descriptors such as 240 keywords, tags, or other properties of the published data. 242 o Push enabled dissemination: The ability to exploit push-based 243 delivery is a key to achieving timeliness and to avoid wasting 244 server and network resources because of redundant polls. 245 Therefore, an efficient pub/sub architecture must provide the 246 capability for publishers to push information to online 247 subscribers interested in it. Such timely dissemination is 248 necessary in many scenarios such as disaster (e.g., Tsunami) 249 warnings, stock market information, news and gaming. 251 o Scalability: The target architecture should be able to accommodate 252 a large number of subscribers as well as publishers (often 253 subscribers are also publishers as user-generated content becomes 254 common). Therefore, it should minimize the amount of states 255 maintained in the network, ensure the load on the publisher grows 256 slowly (sublinearly) with the number of subscribers. The load on 257 the subscribers should also grow slowly with the number of 258 publishers (e.g., dealing with the burden of duplicate 259 elimination). Importantly, the load on the network should not 260 grow significantly with the growth in the number of publishers and 261 subscribers. There is also a need to accommodate a very large 262 range in the amount of information that may be disseminated, and 263 the need for all elements of the pub/sub framework in a content- 264 centric environment to scale in a manageable way. 266 o Efficiency: The architecture should enable a nearly unlimited 267 amount of information being generated by publishers, allow for 268 delivery of information related to subscriptions independent of 269 the frequency at which that information is generated by 270 publishers. The architecture must utilize network and server 271 resources efficiently. It is desirable that content is not 272 transmitted multiple times by a server or on a link. Furthermore, 273 the overhead on publisher and subscriber end-points to query 274 unnecessarily for information must be minimized. 276 o Dynamicity: The architecture should be able to deal with the 277 substantial churn in subscription state, allowing a large number 278 of users to join, leave and frequently change their subscriptions. 279 The topics of interest may change frequently as well (e.g., in a 280 Twitter-like publishing environment, where the popular topics 281 change frequently). 283 Additionally, to support a full-fledge pub-sub environment, it is 284 desirable that the target system support the following additional 285 features: 287 o Support hierarchies and context in naming content: It is desirable 288 to be able to exploit both context and hierarchies in identifying 289 content. Hierarchical naming has been recognized by NDN as well. 290 Exploiting context enables a richer identification of content (in 291 both subscriptions and published information), as noted in the 292 database community. 294 o Support two-step dissemination for policy control and user 295 interest: There is a need for pub/sub environments to support a 296 two-step dissemination process both for reasons of policy and 297 access control at the publisher as well as managing delivery of 298 large volume content. In such a scenario, the pub/sub framework 299 would be designed to publish only a snippet of the data 300 (containing a description of the content and the method how to 301 obtain it) to subscribers. The subscribers then request for the 302 content based on their interest and allowance. 304 o Subscriber offline support: Another typical characteristic of pub- 305 sub environments is that subscribers could be offline at the time 306 the data is published. There is clearly a need for asynchronous 307 delivery of information in a pub/sub environment in an efficient, 308 seamless and scalable manner. The system needs to allow users who 309 were online to retrieve the data that they have missed. It should 310 also allow new subscribers to retrieve previously published 311 content that they are interested in. We envisage a server that 312 stores all the content published. 314 o Prevent Spam/DoS: Spam and DoS attacks are security issues that 315 concern push based pub/sub mechanisms. Efforts to mitigate this 316 at the network layer as well as at the application layer should be 317 considered. 319 Additionally, it will be desirable to have the following features to 320 support a (limited) pub-sub environment in a disaster affected 321 scneario: 323 o TBD 325 o TBD 327 5. Related Work 329 5.1. IP/Overlay Multicast 331 IP multicast [RFC1112] is a candidate solution for efficiently 332 delivering content to multiple receivers. A sender sends data to a 333 multicast group address that subscribers could join. Multicast 334 routing protocols such as PIM-SM [RFC4601] construct and maintain a 335 tree from each sender to all receivers of a multicast group. 336 However, IP multicast isn't an efficient pub/sub delivery mechanism 337 for several reasons: 1) IP multicast is designed for delivery of 338 packets to connected end-points. Dealing with disconnected operation 339 (when subscribers are online) would have to be an application layer 340 issue. Overlay multicast solutions such as 341 [Jannotti2000][Chu2002][Banerjee2002] are agnostic of the underlying 342 network topology, usually relying on multiple unicasts in the 343 underlay path and are therefore also inefficient as a pub/sub 344 delivery mechanism. 2) The somewhat limited multicast group address 345 space makes it difficult to support a direct mapping of CDs to IP 346 multicast addresses. 3) Current IP multicast is not able to exploit 347 relationships between information elements, such as CDs. CDs may be 348 hierarchical or may have a contextual relationship, which enables 349 multiple CDs to be mapped to a group. For example, consider a 350 publisher that sends a message to all the subscribers interested in 351 football, and subscribers who are interested in receiving messages 352 about all sports. The message from the publisher will have to be 353 sent to two distinct IP multicast groups. If there happens to be a 354 subscriber of messages on sports and football, (s)he will receive the 355 same message twice and will have to perform redundancy elimination in 356 the application layer. The result is a waste in network traffic and 357 processing at both ends. 359 5.2. Named-Data Networking (NDN) 361 NDN has limited intrinsic support for pub/sub systems, a critical 362 need in a content centric environment. The aggregation of pending 363 Interests at routers achieves efficient dissemination of information 364 from NDN nodes. But this aggregation is similar to a cache hit in a 365 content distribution network (CDN) cache, which occurs only if 366 subscribers send their Interests with some temporal locality. Thus 367 it avoids multiple Interest queries having to be processed directly 368 by the content provider. Note however that this is still a pull- 369 based information delivery method and depends both on temporal 370 locality of interests and a large enough cache to achieve effective 371 caching in the (content centric) network. On the other hand, native 372 multicast support allows for a much more scalable push-based pub/sub 373 environment, since it is not sensitive to issues such as the cycling 374 of the cache when a large amount of information is disseminated. 376 TBD: Update it based on recent modifications by the NDN team 378 5.3. CCN 380 TBD: Update it based on recent modifications by the CCN team 382 5.4. Content-Oriented Publish/Subscribe(COPSS) 384 COPSS enhances CCN/NDN with a push-based delivery mechanism using 385 multicast in a content-centric framework. It is designed to satisfy 386 the requirements mentioned above, especially to provide temporal 387 separation between subscription (or expression of Interest) and 388 publication. At the content-centric network layer, COPSS uses a 389 multiple-sender, multiple-receiver multicast capability, in much the 390 same manner as PIM-SM. 392 5.5. PSIRP Project 394 TBD 396 5.6. NetInf Project (http://www.netinf.org) 398 TBD 400 5.7. Pursuit Project (http://www.fp7-pursuit.eu/) 402 TBD 404 5.8. Other Related Works 406 Here we list the other related works we are considering. The list 407 might not be complete and we intend to add to it based on feedback 408 received in further revisions. 410 o A. Carzaniga, M. Rutherford, A. Wolf, A routing scheme for 411 content-based networking, in: INFOCOM, 2004. 413 o B. Segall, D. Arnold, J. Boot, M. Henderson, T. Phelps, 414 Content Based Routing with Elvin, in: AUUG2K, 2000. 416 o C. Esteve, F. Verdi, M. Magalhaes, Towards a new generation of 417 information-oriented Internetworking architectures, in: ReArch, 418 2008. 420 o G. Chockler, R. Melamed, Y. Tock, R. Vitenberg, SpiderCast: a 421 scalable interest-aware overlay for topic-based pub/sub 422 communication, in: DEBS, 2007. 424 o H. Eriksson, Mbone: the multicast backbone, Commun. ACM 37 (8) 425 (1994) 54-60. 427 o M. Ott, L. French, R. Mago, D. Makwana, Xml-based semantic 428 multicast routing: an overlay network architecture for future 429 information services, in: GLOBECOM, 2004. 431 o P. T. Eugster, P. A. Felber, R. Guerraoui, A.-M. Kermarrec, 432 The many faces of publish/subscribe, ACM Comput. Surv. 35 (2) 433 (2003) 114-131. 435 o R. Baldoni, R. Beraldi, V. Quema, L. Querzoni, S. Tucci- 436 Piergiovanni, TERA: topic-based event routing for peer-to-peer 437 architectures, in: DEBS, 2007. 439 o R. V. Renesse, K. P. Birman, W. Vogels, Astrolabe: A Robust 440 and Scalable Technology for Distributed System Monitoring, 441 Management, and Data Mining, ACM TOCS 21 (2001) 66-85. 443 o S. Voulgaris, E. Riviere, A.-M. Kermarrec, M. Van Steen, Sub- 444 2-Sub: Self-Organizing Content-Based Publish and Subscribe for 445 Dynamic and Large Scale Collaborative Networks, Research report, 446 INRIA (December 2005). 448 o T. Koponen, M. Chawla, B.-G. Chun, A. Ermolinskiy, K. H. 449 Kim, S. Shenker, I. Stoica, A data-oriented (and beyond) network 450 architecture, in: SIGCOMM, 2007. 452 o V. Ramasubramanian, R. Peterson, E. G. Sirer, Corona: a high 453 performance publish-subscribe system for the world wide web, in: 454 NSDI, 2006. 456 o V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, 457 N. H. Briggs, R. L. Braynard, Networking Named Content, in: 458 CoNEXT, 2009. 460 o Y. Cui, B. Li, K. Nahrstedt, ostream: asynchronous streaming 461 multicast in application-layer overlay networks, JSAC 22 (1) 462 (2004) 91-106. 464 o Y. Diao, S. Rizvi, M. J. Franklin, Towards an internet-scale 465 XML dissemination service, in: VLDB, 2004. 467 6. Standardisation Considerations 469 Future versions of this document will outline a concrete protocol 470 specification for pub/sub support for ICN. Below some initial 471 standardisation considerations are outlined. 473 An initial list of details that need to be specified is the 474 following: 476 o Pub/Sub related interfaces/APIs 477 o Pub/Sub related data structure modification to existing ICN 478 proposals 480 We are also considering to write a survey paper that accumulates all 481 the Pub/sub related work. 483 7. References 485 7.1. Normative References 487 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 488 RFC 1112, August 1989. 490 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 491 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 492 Protocol Specification (Revised)", RFC 4601, August 2006. 494 7.2. Informative References 496 [Banerjee2002] 497 Banerjee, S., Bhattacharjee, B., and C. Kommareddy, 498 "Scalable application layer multicast", SIGCOMM, 2002, . 500 [Carzaniga2011] 501 Carzaniga, A., Papalini, M., and A. Wolf, "Content-based 502 Publish/Subscribe Networking and Information-centric 503 Networking", Proceedings of the ACM SIGCOMM workshop on 504 Information-centric networking, ACM, 2011, . 506 [Chen2011] 507 Chen, J., Arumaithurai, M., Fu, X., and K. Ramakrishnan, 508 "COPSS: An Efficient Content Oriented Publish/Subscribe 509 System", ACM/IEEE 7th Symposium on Architectures for 510 Networking and Communications Systems (ANCS), 2011, . 512 [Chen2012] 513 Chen, J., Arumaithurai, M., Fu, X., and K. Ramakrishnan, 514 "G-COPSS: A Content Centric Communication Infrastructure 515 for Gaming Applications", IEEE 32nd International 516 Conference on Distributed Computing Systems (ICDCS), 2012, 517 . 519 [Chu2002] Chu, Y., Rao, S., Seshan, S., and H. Zhang, "A case for 520 end system multicast", IEEE Journal on Selected Areas in 521 Communications 20, no. 8 (2002): 1456-1471, . 523 [Fenner2005] 524 Fenner, W., Rabinovich, M., Ramakrishnan, K., Srivastava, 525 D., and Y. Zhang, "XTreeNet: Scalable overlay networks for 526 XML content dissemination and querying (synopsis)", 10th 527 International Workshop on Web Content Caching and 528 Distribution (WCW), 2005, . 530 [Jannotti2000] 531 Jannotti, J., Gifford, D., Johnson, K., and M. Kaashoek, 532 "Overcast: reliable multicasting with on overlay network", 533 Proceedings of the 4th conference on Symposium on 534 Operating System Design & Implementation-Volume 4, pp. 535 14-14. USENIX Association, 2000, . 537 [Katsaros2011] 538 Katsaros, K., Xylomenos, G., and G. Polyzos, "MultiCache: 539 An overlay architecture for information-centric 540 networking", Computer Networks 55.4 (2011): 936-947, . 542 [Ramasubramanian2006] 543 Ramasubramanian, V., Peterson, R., and E. Sirer, "Corona: 544 A High Performance Publish-Subscribe System for the World 545 Wide Web", NSDI. Vol. 6. 2006, . 547 [Schmidt2012] 548 Schmidt, T. and M. Waehlisch, "Why We Shouldn t Forget 549 Multicast in Name-oriented Publish/Subscribe", arXiv 550 preprint arXiv:1201.0349 (2012), . 552 Appendix A. Acknowledgment 554 This document has been supported by the GreenICN project (GreenICN: 555 Architecture and Applications of Green Information Centric Networking 556 ), a research project supported jointly by the European Commission 557 under its 7th Framework Program (contract no. 608518) and the 558 National Institute of Information and Communications Technology 559 (NICT) in Japan (contract no. 167). The views and conclusions 560 contained herein are those of the authors and should not be 561 interpreted as necessarily representing the official policies or 562 endorsements, either expressed or implied, of the GreenICN project, 563 the European Commission, or NICT. 565 Authors' Addresses 566 Mayutan Arumaithurai 567 University of Goettingen 568 Goldschmidt Str. 7 569 Goettingen 37077 570 Germany 572 Phone: +49 551 39 172046 573 Fax: +49 551 39 14416 574 Email: arumaithurai@informatik.uni-goettingen.de 576 Jiachen Chen 577 University of Goettingen 578 Goldschmidt Str. 7 579 Goettingen 37077 580 Germany 582 Phone: +49 551 39 172051 583 Fax: +49 551 39 14416 584 Email: jiachen@informatik.uni-goettingen.de 586 Xiaoming Fu 587 University of Goettingen 588 Goldschmidt Str. 7 589 Goettingen 37077 590 Germany 592 Phone: +49 551 39 172023 593 Fax: +49 551 39 14416 594 Email: fu@informatik.uni-goettingen.de 596 K. K. Ramakrishnan 597 University of California, Riverside 598 900 University Ave 599 Riverside CA 92521 600 USA 602 Email: kkramakrishnan@yahoo.com 603 Jan Seedorf 604 NEC 605 Kurfuerstenanlage 36 606 Heidelberg 69115 607 Germany 609 Phone: +49 6221 4342 221 610 Fax: +49 6221 4342 155 611 Email: seedorf@neclab.eu