| ICNRG | M. Arumaithurai |
| Internet-Draft | J. Chen |
| Intended status: Informational | X. Fu |
| Expires: January 4, 2015 | University of Göttingen |
| K. Ramakrishnan | |
| University of California, Riverside | |
| J. Seedorf | |
| NEC | |
| July 3, 2014 |
Enabling Publish/Subscribe in ICN
draft-jiachen-icn-pubsub-00
Information-Centric Networks (ICN) provide substantial flexibility for users to obtain information without regard to the source of the information or its current location. Publish/subscribe (pub/sub) systems have gained popularity in society to provide the convenience of removing the temporal dependency of the user having to indicate an interest each time he or she wants to receive a particular piece of related information. Such an "information-centric" communication model should be supported in the new ICN network paradigm. This document outlines some research directions for ICN with respect to enhancing the inherently pull-based ICN approaches for achieving efficient pub/sub capability.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document points out the need to support publish/subscribe (pub/sub) capabilities in ICN and the problems with the existing solutions. Further, the document discusses potential directions for enhancing Information Centric Networking (ICN) to achieve efficient pub/sub.
Section 2 describes the pub/sub systems and the challenges of such systems to the current Internet. Section 3 demonstrates the use of pub/sub systems in different scenarios. Section 4 outlines the requirements of an efficient pub/sub architecture and Section 5 discusses the related works and some possible shortcomings. In Section 6 we brief our standardisation considerations.
Users increasingly desire access to information, ranging from news, financial markets, healthcare, to disaster relief and beyond, independent of who published it, where it is located, and often, when it was published. Typical representation of these usages are microblogs, RSS feed, social network, search engines, etc. A consumer may not wish (or it may even be infeasible) to receive all of the "channels" belonging to a myriad of information providers that disseminate items of interest, either on demand (such as web, twitter, blogs and social networks), or tune to a broadcast channel (e.g., television, radio, newspaper). In these cases, the consumer would rather prefer obtaining the data based on Content Descriptors (CD) such as a keyword, a tag, or a property of the content (publisher identity, published date etc.).
Publish/subscribe (pub/sub) systems are particularly suited for such kind of large scale content-oriented information dissemination, and provide the exibility for users to subscribe to information of interest, without being intimately tied to when that information is made available by publishers. With the use of an appropriate interface, users can select and filter the information desired so that they receive only what they are interested in, often irrespective of the publisher.
Intelligent end-systems and information aggregators (e.g., Google News and Yahoo! News, cable and satellite providers) have increasingly adapted their interfaces to provide a content-oriented pub/sub-based delivery method. However, these mechanisms are built on top of a centralized server based framework and can also result in a waste of network resources as shown in [Ramasubramanian2006][Katsaros2011], since the Internet protocol suite is focused on end-to-end delivery of data. Furthermore, issues of "coverage" and "timeliness" still exist in such forms of dissemination, where the aggregator may be selective in what information is made available.
Information-Centric Networks (ICN) is a new network paradigm that intendeds to achieve large scale data delivery with greater ease for users, greater scalability in terms of the amount of information disseminated as well as number of producers and consumers of information, and greater efficiency in terms of network and server resource utilization.
It is also desirable for such a network to assist the pub/sub communication model that delivers the information from any of the producers to all subscribers. Moreover, it is desirable for the network to assist in delivering fine-grained information to the subscriber.
Recently, works such as [Schmidt2012],[Carzaniga2011],[Chen2011],[Chen2012] have also highlighted the need for ICN to support a pub/sub like communication model.
In this section, we list several use cases of pub/sub architectures in ICN. They help us to understand the requirements of an efficient pub/sub architecture and why the existing solutions fall short.
Online social networks (e.g., Twitter, Facebook, etc.) and Rich Site Summary (RSS) feeds are typical use cases for a content-centric pub/sub system. In such systems, the receivers receive messages either from friends, followees, or from some information aggregators. They do not care which exact machine is sending the message (content-centric), nor do they know when and what is the name of the next message they are going to receive (temporal separation).
To prevent the receivers from polling all the possible providers, existing systems use web servers as rendezvous points: the publishers send new messages to the servers and the receivers/subscribers poll the server periodically. This still causes great wastage for the (HTTP) servers answering "304 - Not Modified" repeatedly since the message update frequency is usually lower than the polling frequency.
Massively multiplayer online role-playing games (MMORPGs, e.g., Counter-Strike, Quake, World of Warcraft, etc.) and audio/video conferencing (e.g., Skype meeting, Web Whiteboard, Etherpad, etc.) is another kind of content-centric pub/sub systems. Similar to the social network scenario, users in such systems only care about the content, either the area of interest (AoI) or the conference partners, and they do not know when and from where the next message will come. But different from the previous scenario, such systems require real-time update (message) delivery and these messages are usually smaller in size compared to the online social networks.
Many of these systems choose to use HTTPS or direct TCP connection between the server and the users to enable the capability of server "pushing" the updates to the user. But maintaining such links are costly. MMORPGs usually limit the number of players in a same game which greatly reduces the interesting of these games.
Disasters have often disrupted communications because of damages to critical infrastructure. For instance in the aftermath of the Japanese Earthquake in 2011, approximately 1,200,000 fixed telephone lines and 15,000 base-stations were not functioning. On average, 22% (with peaks up to 65% in some areas) of the base-stations had to shut down due to the lack of power or damages to the infrastructure.
Contradictory to the loss of available hardware capacity, during and in the aftermath of a disaster, there is a substantial increase in the amount of traffic generated because of the natural anxiety and panic among people and the need to organize rescue and emergency services. Many of these traffic are in the form of a pub/sub communication model, e.g., the government needs to publish some notifications (recovery status, new shelter locations, etc.), the refugees need to notify their friends about their safety, or people needs to ask for help from ambulances or fire brigade. In the Japanese case, the congestion caused by such traffic resulted in restrictions in voice traffic up to 95%, including emergency priority calls.
Given a pub/sub communication model as described in Section 2, on a high-level one can derive the following (incomplete) list of basic requirements:
Additionally, to support a full-fledge pub-sub environment, it is desirable that the target system support the following additional features:
IP multicast [RFC1112] is a candidate solution for efficiently delivering content to multiple receivers. A sender sends data to a multicast group address that subscribers could join. Multicast routing protocols such as PIM-SM [RFC4601] construct and maintain a tree from each sender to all receivers of a multicast group. However, IP multicast isn't an efficient pub/sub delivery mechanism for several reasons: 1) IP multicast is designed for delivery of packets to connected end-points. Dealing with disconnected operation (when subscribers are online) would have to be an application layer issue. Overlay multicast solutions such as [Jannotti2000][Chu2002][Banerjee2002] are agnostic of the underlying network topology, usually relying on multiple unicasts in the underlay path and are therefore also inefficient as a pub/sub delivery mechanism. 2) The somewhat limited multicast group address space makes it difficult to support a direct mapping of CDs to IP multicast addresses. 3) Current IP multicast is not able to exploit relationships between information elements, such as CDs. CDs may be hierarchical or may have a contextual relationship, which enables multiple CDs to be mapped to a group. For example, consider a publisher that sends a message to all the subscribers interested in football, and subscribers who are interested in receiving messages about all sports. The message from the publisher will have to be sent to two distinct IP multicast groups. If there happens to be a subscriber of messages on sports and football, (s)he will receive the same message twice and will have to perform redundancy elimination in the application layer. The result is a waste in network traffic and processing at both ends.
CCN/NDN has limited intrinsic support for pub/sub systems, a critical need in a content centric environment. The aggregation of pending Interests at routers achieves efficient dissemination of information from NDN nodes. But this aggregation is similar to a cache hit in a content distribution network (CDN) cache, which occurs only if subscribers send their Interests with some temporal locality. Thus it avoids multiple Interest queries having to be processed directly by the content provider. Note however that this is still a pull-based information delivery method and depends both on temporal locality of interests and a large enough cache to achieve effective caching in the (content centric) network. On the other hand, native multicast support allows for a much more scalable push-based pub/sub environment, since it is not sensitive to issues such as the cycling of the cache when a large amount of information is disseminated.
COPSS enhances CCN/NDN with a push-based delivery mechanism using multicast in a content-centric framework. It is designed to satisfy the requirements mentioned above, especially to provide temporal separation between subscription (or expression of Interest) and publication. At the content-centric network layer, COPSS uses a multiple-sender, multiple-receiver multicast capability, in much the same manner as PIM-SM.
Here we list the other related works we are considering. The list might not be complete and we intend to add to it based on feedback received in further revisions.
And some related projects:
Future versions of this document will outline a concrete protocol specification for pub/sub support for ICN. Below some initial standardisation considerations are outlined.
An initial list of details that need to be specified is the following:
We are also considering to write a survey paper that accumulates all the Pub/sub related work.
| [RFC1112] | Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. |
| [RFC4601] | Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. |
This document has been supported by the GreenICN project (GreenICN: Architecture and Applications of Green Information Centric Networking ), a research project supported jointly by the European Commission under its 7th Framework Program (contract no. 608518) and the National Institute of Information and Communications Technology (NICT) in Japan (contract no. 167). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the GreenICN project, the European Commission, or NICT.