Escolar Documentos
Profissional Documentos
Cultura Documentos
mates. However, such an approach involves investigating Minimize average update detection time w.r.t. expected
heuristics for determining the appropriate performance update frequency, bounding load on content servers.
requirement for each channel and for dividing the total Corona-Fair-Sqrt:
load between different channels. Moreover, it does not PM √τ bli PM PM
min. 1 qi u N
√ s.t. si bNli ≤ qi
provide fine-grained control over the performance of the i
1 1
system, often causing it to operate far from optimally. Corona-Fair with sqrt weight on the latency ratio to
The rest of this section describes how the tradeoffs can be emphasize infrequently changing channels.
posed as mathematical optimization problems to achieve Corona-Fair-Log:
different performance requirements. PM log τ bli PM PM
min. 1 qi log ui N s.t. si bNli ≤ qi
Corona-Lite: The first performance goal we ex- 1 1
plore is minimizing the average update detection time Corona-Fair with log weight on the latency ratio to
while bounding the total network load placed on content emphasize infrequently changing channels.
servers. Corona-Lite improves the update performance Notation
seen by the clients while ensuring that the content servers
τ polling interval
handle a light load: no more than they would handle from
M number of channels
the clients if the clients fetched the objects directly from
N number of nodes
the servers.
b base of structured overlay
The optimization problem for Corona-Lite is defined
T performance target
in Table 1. The overall update performance is measured
li polling level of channel i
by taking an average of the update detection time of each
qi number of clients for channel i
channel weighted by the number of clients subscribed to
si content size for channel i
the channels. We weigh the average using the number of
ui update interval for channel i
subscriptions because update performance is an end user
experience, and each client counts as a separate unit in Table 1: Performance-Overhead Tradeoffs: This table
the average. The target network load for this optimiza- summarizes the optimization problems for different perfor-
tion is simply the total number of subscriptions in the mance goals in Corona.
system.
Corona-Lite clients experience the maximum bene- Corona-Fast: While Corona-Lite bounds the network
fits of cooperation. Clients of popular channels gain load on the content servers and minimizes update latency,
greater benefits than clients of less popular channels. Yet, the update performance it provides can vary depending
Corona-Lite does not suffer from “diminishing returns,” on the current workload. Corona-Fast provides stable up-
using its surplus polling capacity on less popular chan- date performance, which can be maintained steadily at a
desired level through changes in the workload. Corona- The preceding optimization problem is NP-Hard, as
Fast solves the converse of the previous optimization the polling levels only take integral values. Hence, in-
problem; that is, it minimizes the total network load on stead of using computationally intensive techniques to
the content servers while meeting a target average up- find the exact solution, Honeycomb finds an approxi-
date detection time. Corona-Fast enables us to tune the mate solution quickly in time comparable to a sorting
update performance of the system according to applica- algorithm. Honeycomb’s optimization algorithm runs in
tion needs. For example, a stock-tracker application may O(M log M log N ) time.
choose a target of 30 seconds to quickly detect changes The solution provided by Honeycomb is accurate and
to stock prices. deviates from the optimal in at most one channel. Honey-
Corona-Fast shields legacy Web servers from sudden comb achieves this accuracy by finding two solutions that
increases in load. A sharp increase in the number of sub- optimize the problem with slightly altered constraints:
scribers for a channel does not trigger a corresponding one with a constraint Td ≤ T and another with con-
increase in network load on the Web server since Corona- straint Tu ≥ T . The corresponding solutions L∗u and L∗d
Fast does not increase polling after diminishing returns are exactly optimal for the optimization problems with
sets in. In contrast, in legacy RSS, popularity spikes constraints Tu and Td respectively, and differ in at most
cause a significant increase in network load on content one channel. That is, one channel has a different polling
providers. Moreover, the increased load typically contin- level in L∗u than in L∗d . Note that the optimal solution L∗
ues unabated in legacy RSS as subscribers forget to un- for the original problem with constraint T may actually
subscribe, creating “sticky” traffic. Corona-Fast protects decide to allocate channels differently from L∗d and L∗u .
content servers from flash-crowds and sticky traffic. Yet, the minimum determined by L∗ will be bounded by
Corona-Fair: Corona-Fast and Corona-Lite do not the minima determined by L∗d and L∗u due to monotonic-
consider the actual rate of change of content in a channel. ity. Honeycomb then chooses L∗d as the final solution
While some Web objects are updated every few minutes, because it satisfies the constraint T strictly.
others do not change for days at a time [10, 19]. Corona- Honeycomb computes L∗d and L∗u using a Lagrange
Fair incorporates the update rate of channels into the per- multiplier to transform the optimization problem as fol-
formance tradeoff in order to achieve a fairer distribution lows:
of update performance between channels. It defines a
modified update performance metric as the ratio of the X
M X
M
update detection time and the update interval of the chan- L∗ = arg min. fi (li ) − λ[ gi (li ) − T ].
nel, which it minimizes to achieve a target load. 1 1
While the new metric accounts for the wide difference Honeycomb iterates over λ and obtains the two solu-
in update characteristics, it biases the performance unfa- tions L∗d and L∗u that bracket the minimum using standard
vorably against channels with large update interval times. bracketing methods for function optimization in one di-
A channel that does not change for several days experi- mension.
ences long update detection times, even if there are many Two observations enable Honeycomb to speed up the
subscribers for the channel. We compensate for this bias optimization algorithm. First, L∗ (λ0 ) for a single itera-
by exploring other update performance metrics based on tion can be computed by finding arg min.fi (li ) − λ0 gi (li )
square root and logarithmic functions, which grow sub- independently for each channel. This takes O(M log N )
linearly. A sub-linear metric dampens the tendency of the time as the number of levels is bounded by dlog N e.
optimization algorithm to punish slow-changing yet pop- Second, for each channel there are only log N val-
ular feeds. Table 1 summarizes the optimization prob- ues of λ that change arg min.fi (li ) − λ0 gi (li ). Pre-
lems for different versions of Corona. computing these λ values for each object provides a dis-
crete iteration space of M log N λ values. By keep-
3.2 Decentralized Optimization
ing a sorted list of the λ values, Honeycomb computes
Corona determines the optimal polling levels using the
the optimal solution in O(log M ) iterations. Overall,
Honeycomb optimization toolkit. Honeycomb provides
the run-time complexity of the optimization algorithm
numerical algorithms and decentralized mechanisms for
is O(M log M log N ) time, including the time spent in
solving optimization problems that can be expressed as
pre-computation, sorting, and iterations.
follows:
The preceding algorithm requires the tradeoff func-
X
M
PM tions fi (l) and gi (l) of all channels in the system in
min. fi (li ) s.t. 1 gi (li ) ≤ T. order to compute the global optimum. Solving the op-
1
timization problem using limited data available locally
Here, fi (l) and gi (l) can define the performance or the can produce highly inaccurate solutions. On the other
cost for channel i as a function of the polling level l. hand, collecting the tradeoff factors for all the channels
at each node is clearly expensive and impractical. It is of the content, and the interval at which servers update
possible to gather the tradeoff data at a central node, run channel content. The latter is estimated based on the time
the optimization algorithm at a single location, and then between updates detected by Corona.
distribute the optimal levels to peers from the central lo- Corona manages cooperative polling through a pe-
cation. We avoid using a centralized infrastructure as it riodic protocol consisting of an optimization phase, a
introduces a single point of failure in the system and has maintenance phase, and an aggregation phase. In the
limited scalability. optimization phase, Corona nodes apply the optimiza-
Instead, Honeycomb internally aggregates coarse tion algorithm on fine-grained tradeoff data for locally
grained information about global tradeoff factors. It polled channels and coarse-grained tradeoff clusters ob-
combines channels with similar tradeoff factors into a tained from overlay contacts. In the maintenance phase,
tradeoff cluster. Each cluster summarizes the trade- changes to polling levels are communicated to peer
off factors for multiple channels and provides coarse- nodes in the routing table through maintenance mes-
grained tradeoff information. A ratio of performance and sages. Finally, the aggregation phase enables nodes to
cost factors, fi /gi , is used as a metric to combine chan- receive new aggregates of tradeoff factors. In practice,
nels. For example, channels with comparable values for the three phases occur concurrently at a node with aggre-
ui si are combined into a cluster in Corona-Fair. gation data piggy-backed on maintenance messages.
qi
Honeycomb nodes periodically exchange the clusters Corona nodes operate independently and make deci-
with contacts in the routing table and aggregate the clus- sions to increase or decrease polling levels locally. Ini-
ters received from the contacts. Honeycomb keeps the tially, only the owner nodes at level K = dlog N e poll
overhead for cluster aggregation low by limiting the for the channels. If an owner decides to lower the polling
number of clusters for each polling level to a constant level to K − 1 (based on local optimization), it sends a
Tradeoff Bins. Each node receives Tradeoff Bins clus- message to the contacts in its routing table at row K−1 in
ters for every polling level from each contact in the rout- the next maintenance phase. As a result, a small wedge
ing table. Combined, these clusters summarize the trade- of level K − 1 nodes start polling for that channel. Sub-
off characteristics of all the channels in the system. The sequently, each of these nodes may independently decide
cluster aggregation overhead in terms of memory state as to further lower the polling level of that channel. Simi-
well as network bandwidth is limited by the size of the larly, if an owner node decides to raise the level from
routing table, and scales with the logarithm of the system K − 1 to K, it asks its contact in the K − 1 wedge to
size. stop polling.
In general, when a level i node lowers the level to i−1
3.3 System Management or raises the level from i − 1 back to i, it instructs its
Corona is a completely decentralized system, in which contact in row i − 1 of its routing table to start or stop
nodes act independently, share load, and achieve glob- polling for that channel. This control path closely fol-
ally optimal performance through mutual cooperation. lows the DAG rooted at the owner node. Nodes at level i
Corona spreads load uniformly among the nodes through (depth K − i) in this DAG decide whether their children
consistent-hashing [18]. Each channel in Corona has a at level i − 1 should poll a channel and convey these de-
unique identifier and one or more owner nodes managing cisions periodically every maintenance interval. When a
it. The identifier is a content-hash of the channel’s URL, node is instructed to begin polling for a channel, it waits
and the primary owner of a channel is the Corona node for a random interval of time between 0 and the polling
with the numerically closest identifier to the channel’s interval before the first poll. This ensures that polls for a
identifier. Corona adds additional owners for a channel channel at different nodes are randomly distributed over
in order to tolerate failures. These owners are the F clos- time.
est neighbors of the primary owner along the ring. In the Corona nodes gather current estimates of tradeoff fac-
event an owner fails, a new neighbor automatically re- tors in the aggregation phase. Owners monitor the num-
places it. ber of subscribers and send out fresh estimates along
Owners take responsibility for managing subscrip- with the maintenance message. Subsequent maintenance
tions, polling, and updates for a channel. Owners receive messages sent out by descendant nodes in the DAG prop-
subscriptions through the underlying overlay, which au- agate these estimates to all the nodes in the wedge. The
tomatically routes all subscription requests of a channel update interval and size of a feed only change during up-
to its owner. The owners keep state about the subscribers dates and are therefore sent along with updates. Tradeoff
of a channel and send notifications to them when fresh clusters are also sent by contacts in the routing table in
updates are detected. In addition, owners also keep track response to maintenance messages.
of channel-specific factors that affect the performance Corona inherits robustness and failure-resilience from
tradeoffs, namely the number of subscribers, the size the underlying structured overlay. If the current contact
in the routing table fails, the underlying overlay automat- polling level of the channel. The dissemination along the
ically replaces it with another contact. When new nodes DAG takes place using contacts in the routing table of the
join the system or nodes fail, Corona ensures the transfer underlying overlay. For channels that cannot obtain a re-
of subscription state to new owners. A node that is no liable modification timestamp from the server, the node
longer an owner simply erases its subscription state, and detecting the update sends the delta to the primary owner,
a node that becomes a new owner receives the state from which assigns a new version number and initiates the dis-
other owners of the channel. Simultaneous failure of semination to other nodes polling that channel. Two dif-
more than F adjacent nodes poses a problem for Corona, ferent nodes may detect a change “simultaneously” and
as well as to many other peer-to-peer systems; we as- send deltas to the primary owner. The primary owner
sume that F is chosen to make such an occurrence rare. always checks the current delta with the latest updated
Note that clients can easily renew subscriptions should a version of the content and ignores redundant deltas.
catastrophic failure lose some subscription state.
Overall, Corona manages polling using light-weight 3.5 User Interface
mechanisms that impose a small, predictable overhead Corona employs instant messaging (IM) as its user in-
on the nodes and network. Its algorithms do not rely on terface. Users add Corona as a “buddy” in their favorite
expensive constructs such as consensus, leader election, instant messaging system; both subscriptions and update
or clock synchronization. Networking activity is limited notifications are then communicated as instant messages
to contacts in the nodes’ routing tables. between the users and Corona. Users send request mes-
sages of the form “subscribe url” and “unsubscribe url”
3.4 Update Dissemination to subscribe and unsubscribe for a channel. A subscribe
Updates are central to the operation of Corona; hence, or unsubscribe message delivered by the IM system to
we ensure that they are detected and disseminated effi- Corona is routed to all the owner nodes of the channel,
ciently. Corona uses monotonically increasing numbers which update their subscription state. When a new up-
to identify versions of content. The version numbers are date is detected by Corona, the current primary owner
based on content modification times whenever the con- sends an instant message with the delta to all the sub-
tent carries such a timestamp. For other channels, the scribers through the IM system. If a subscriber is off-
primary owner node assigns version numbers in increas- line at the time an update is generated, the IM system
ing order based on the updates it receives. buffers the update and delivers it when the subscriber
Corona nodes share updates only as deltas, the differ- subsequently joins the network.
ences between old and new content, rather than the en- Delivering updates through instant messaging systems
tire content. A measurement study on micronews feeds incurs additional latency since messages are sent through
conducted at Cornell shows that the amount of change in a centralized service. However, the additional latency is
content during an update is typically tiny. The study re- modest as IM systems are designed to reduce such la-
ports that the average update consists of 17 lines of XML, tencies during two-way communication. Moreover, IM
or 6.8% of the content size [19], which implies that a systems that allow peer-to-peer communication between
significant amount of bandwidth can be saved through their users, such as Skype, deliver messages in quick
delta-encoding. time.
A difference engine enables Corona to identify when Instant messaging enables Corona to be easily accessi-
a channel carries new information that needs to be dis- ble to a large user population, as no computer skills other
seminated to subscribed clients. The difference engine than an ability to “chat” are required, and ubiquitous IM
parses the HTML or XML content to discover the core deployment ensures that hosts behind NATs and firewalls
content in the channel, ignoring frequently changing ele- are supported. Moreover, instant messages also guaran-
ments such as timestamps, counters, and advertisements. tee the authenticity of the source of update messages to
The difference engine generates a delta if it detects an the clients, as instant messaging systems pre-authenticate
update after isolating the core content. The data in a Corona as the source through password verification.
delta resembles the typical output of the POSIX ‘diff’
command: it carries the line numbers where the change 4 Implementation
occurs, the changed content, an indication of whether it We have implemented a prototype of Corona as an ap-
is an addition, omission, or replacement, and a version plication layered on Pastry [29], a prefix-matching struc-
number of the old content to compare against. tured overlay system. The implementation uses a 160-bit
When a delta is generated by a node, it shares the up- SHA-1 hash function to generate identifiers for both the
date with all other nodes in the channel’s polling wedge. nodes (based on their IP addresses) and channels (based
To achieve this, the node simply disseminates the delta on their URLs). Both the base of Pastry and the number
along the DAG rooted at it up to a depth equal to the of tradeoff clusters per polling level are set to 16.
Prefix matching overlays occasionally create orphans, mance of Corona to the performance of legacy RSS, a
that is, channels with no owners having enough match- widely-used micronews syndication system. The simula-
ing prefix digits. Orphans are created when the re- tions and experiments are driven by real-life RSS traces.
quired wedge of the identifier space, corresponding to We collected characteristics of micronews workloads
level dlog N e − 1, is empty. Corona cannot assign ad- and content by passively logging user activity and ac-
ditional nodes to poll an orphan channel to improve its tively polling RSS feeds [19]. User activity recorded
update performance. Moreover, orphans adversely affect between March 22 and May 3 of 2005 at the gate-
the computation of globally optimal allocation. Corona way of the Cornell University Computer Science De-
handles orphan channels by adjusting the tradeoffs ap- partment provided a workload of 158 clients making
propriately. The tradeoff factors of orphan channels are approximately 62,000 requests for 667 different feeds.
aggregated into a slack cluster, which is used to adjust The channel popularity closely follows a Zipf distribu-
the performance target prior to optimization. tion with exponent 0.5. The survey analyzes the update
Corona’s reliance on IM as an asynchronous commu- rate of micronews content by actively polling approxi-
nication mechanism poses some operational challenges. mately 100,000 RSS feeds obtained from syndic8.com.
Corona interacts with IM systems using GAIM [12], We poll these feeds at one hour intervals for 84 hours,
an open source instant messaging client for Unix-based and subsequently select a subset of 1000 feeds and poll
platforms that supports multiple IM systems including them at a finer granularity of 10 minutes for five days.
Yahoo Instant Messenger, AOL Instant Messenger, and Comparing periodic snapshots of the feeds shows that
MSN Messenger. Several IM systems have a limitation the update interval of micronews content is widely dis-
that only one instance of a user can be logged on at a tributed: about 10% of channels changed within an hour,
time, preventing all Corona nodes from being logged on while 50% of channels did not change at all during the
simultaneously. While we hope that IM systems will sup- five days of polling.
port simultaneous logins from automated users such as
Corona in the near future, as they have for several chat 5.1 Simulations
robots, our implementation uses a centralized server to We use tradeoff parameters based on the RSS survey in
talk to IM systems as a stop-gap measure. This server our simulations. In order to scale the workload to the
acts as an intermediary for all updates sent to clients as larger scale of our simulations, we extrapolate the distri-
well as subscription messages sent by clients. Also, IM bution of feed popularity from the workload traces and
systems such as Yahoo rate-limit instant messages sent set the popularity to follow a Zipf distribution with ex-
by unprivileged clients. Corona’s implementation limits ponent 0.5. We use a distribution for the update rates of
the rate of updates sent to clients to avoid sending up- channels obtained through active polling, setting the up-
dates in bursts. date interval of the channels that do not see any updates
Corona trusts the nodes in the system to behave cor- to one week.
rectly and generate authentic updates. However, it is We perform simulations for a system of 1024 nodes,
possible that in a collaborative deployment, where nodes 100,000 channels, and 5,000,000 subscriptions. We start
under different administrative domains are part of the each simulation with an empty state and issue all sub-
Corona network, some nodes may be malicious and gen- scriptions at once before collecting performance data.
erate spurious updates. This problem can be easily We run the simulations for six hours with a polling inter-
solved if content providers are willing to publish digi- val of 30 minutes and maintenance interval of one hour.
tally signed certificates along with their content. An al- We study the performance of the three schemes, Corona-
ternative solution that does not require changes to servers Lite, Corona-Fast, and Corona-Fair, and compare the
is to use threshold-cryptography to generate a certificate performance with that of legacy RSS clients polling at
for content [40, 15]. The responsibility for generating the same rate of 30 minutes.
partial signatures can be shared among the owners of a
node ensuring that rogue nodes below the threshold level Corona-Lite
cannot corrupt the system. Designing and implementing Figures 3 and 4 show the network load and update perfor-
such a threshold-cryptographic scheme is, however, be- mance, respectively, for Corona-Lite, which minimizes
yond the scope of this paper. average update detection time while bounding the to-
tal load on content servers. The figures plot the net-
work load, in terms of the average bandwidth load placed
5 Evaluation on content servers, and update performance, in terms of
We evaluate the performance of Corona through large- the average update detection time. Figure 3 shows that
scale simulations and wide-area experiments on Planet- Corona-Lite stabilizes at the load imposed by legacy RSS
Lab [2]. In all our evaluations, we compare the perfor- clients. Starting from a clean slate where only owner
1.5 4
10
Legacy RSS
Corona Lite
Network Load per Channel (kbps)
3
10
2
10
0.5
1
10
Legacy RSS
Corona Lite
Corona Fast 0
0 10
0 2 4 6 0 20000 40000 60000 80000 100000
Time (hours) Channel Rank by Popularity
Figure 3: Network Load on Content Servers: Corona-Lite Figure 5: Number of Pollers per Channel: Corona trades
converges quickly to match the network load imposed by off network load from popular channels to decrease update
legacy RSS clients. detection time of less popular channels and achieve a lower
system-wide average.
100
Legacy RSS
4
Corona Lite 10
Corona Fast Legacy RSS
Corona Lite
Update Detection Time (min)
15
10 3
Update Detection Time (sec) 10
2
10
1
0.5
1
10
0 2 4 6 0
Time (hours) 10
0 20000 40000 60000 80000 100000
Channel Rank by Popularity
Corona-Lite 53 48.97
Corona-Fair 142 50.14 2
10
Corona-Fair-Sqrt 55 49.46
Corona-Fair-Log 53 49.43
Corona-Fast 32 58.75 1
10
Corona-Fast
Unlike Corona-Lite, Corona-Fast minimizes the total Figure 8: Update Detection Time per Channel: Corona-
Fair-Sqrt and Corona-Fair-Log fix the bias against chan-
load on servers while aiming to achieve a target update
nels that change rarely and provide better update detection
detection latency. Figures 3 and 4 show the network load time for them than Corona-Fair does.
and update performance, respectively, for Corona-Fast.
Figure 4 confirms that Corona-Fast closely meets the
desired target of 30 seconds. This improvement in up- ranked by their update intervals. Channels with the same
date detection time entails an increase in server load over update intervals are further ranked by popularity. For
Corona-Lite. Unlike Corona-Lite, whose update perfor- clarity of presentation, we plot the distribution for 200
mance may vary depending on the workload seen by the uniformly chosen channels.
system, Corona-Fast provides a stable average update Figure 7 shows that Corona-Lite achieves an unfair
performance. Moreover, it enables us to set the perfor- distribution of update detection times by ignoring update
mance depending on the requirements of the application interval information. Many channels with large update
and ensures that the targeted performance is achieved intervals have short update detection times (shown in the
with minimal load on content servers. lower-right of the graph), while some rapidly changing
channels have long update detection times (shown in the
Corona-Fair upper-left of the graph). Corona-Fair fixes this unfair dis-
Finally, we examine the performance of Corona-Fair, tribution of update detection time by using update inter-
which uses the update rates of channels to fine-tune the vals of channels to influence the choice of polling levels.
distribution of load. It takes advantage of the wide dis- Figure 7 shows that Corona-Fair has a fairer distribution
tribution of update intervals among channels and aims of update detection times with update intervals; that is,
to poll frequently updated channels at a higher rate channels with shorter update intervals have faster update
than channels with long update intervals. Figure 7 detection times and vice-versa.
shows the distribution of update detection times achieved Corona-Fair optimizes for update performance mea-
by Corona-Lite and Corona-Fair for different channels sured as the ratio of update detection time and update in-
terval. Thus, channels with long update intervals may 3
10
also have proportionally long update detection times,
leading to long wait times for clients. Section 3.1 pro-