Content-Based Publish/Subscribe Networking and Information-Centric Networking
Carzaniga, Papalini, Wolf
content-based network ccn information-centric pub/sub
@inproceedings{carzaniga:icn-2011,
author={Antonio Carzaniga and Michele Papalini and
Alexander L. Wolf},
title={Content-Based Publish/Subscribe Networking and
Information-Centric Networking},
booktitle={{ACM} {SIGCOMM} Workshop on
Information-Centric Networking ({ICN})},
pages={56--61},
year={2011},
address={Toronto, Canada},
month={August}
}
[ Download PDF ]
Abstract:
On-line information comes in different forms and is accessed in different ways and for different purposes. For example, a recording of Beethoven’s Ninth Symphony differs from a storm warning from the local weather service. Beethoven’s Ninth is a large media file with perpetual validity that is typically accessed on demand by users. By contrast, a storm warning is a small ephemeral message typically pushed by the weather service to all users in a specific geographic area. We argue that both should and would be well supported by an information-centric network. More specifically we argue three points. First, modern applications, reflecting the nature of human communications, use and transmit large and long-lived files as well as small ephemeral messages. Second, accessing those two types of information involves significantly different operations within the network. Third, despite their differences, both types of information would benefit from an addressing scheme based on content rather than on more or less flat identifiers, which means that both should be integrated to some extent within a unified content-based routing infrastructure.
Both content upon demand and publish/subscribe should be supported
- Paper seems to feel this combination is novel
- Feel needs to motivate pub/sub
Differ along three dimensions
- Validity or value of content over time
- Initiator of content flow
- Expressiveness of names versus predicates (queries)
Argument: In practice, persistent content is generally on-demand (flow initiated by consumer), while ephemeral content is push proactively (flow initiated by producer)
Volume of on-demand content is greater due to sheer bulk, despite perhaps fewer messages in some settings
Not efficient to ride on-demand over proactive, or vice versa
- Same argument I've made about CCNx pulls being too much traffic
- Interesting point about cache semantics: Can't continually ask for the latest data, you'll just keep getting the previous message from the closest cache
- Connection here to OntoNet services-over-CCN model
Current CCN architecture not designed to handle overlapping names
Size of state is a big issue in CCN
CCN on-demand content producers register prefixes of content they produce
Only string based names considered here, in both on-demand and pub/sub modes
- Once unified by name, only difference in terms of routing information is content source
- Producers in on-demand, consumers in pub/sub
- In terms of traffic, three message types required
- Messages: One-way messages like an IP multicast datagram
- Request: Forwarded to data block, triggering return of latter as reply
- Reply: A data block sent back toward a request source
Assume routing is propagated and computed using fairly standard link state
Messages and requests both forwarded toward nodes advertising matching prefixes
- Matched against progressively more specific prefixes
- Source routed, path computed when originally entering network
Negative replies---no such data available
Doesn't store requests at nodes along path not shared with other requests
- Instead multi-hop forwards across IP to cover gaps
See also: