Bellini: Ferrying Application Traffic Flows through Geo-distributed Datacenters in the Cloud

Transcription

1 Bellini: Ferrying Application Traffic Flows through Geo-istribute Datacenters in the Clou Zimu Liu, Yuan Feng, an Baochun Li Department of Electrical an Computer Engineering, University of Toronto Department of Computing, Hong Kong Polytechnic University Abstract Thanks to the on-eman nature of clou computing, a large number of applications have been recently migrate to the clou. To take full avantage of superior connectivities between geo-istribute atacenters, application traffic can be ferrie through the clou to provie better service an user experience. However, implementing an eploying such interatacenter protocols for various applications, such as messaging, streaming an conferencing, are not without challenges, ue to complex requirements of applications an unique characteristics of atacenters. In orer to simplify the esign an implementation of new inter-atacenter protocols, we esign an implement a new system framework, calle Bellini, in this paper. Bellini provies customizable elements share by the new category of inter-atacenter protocols, incluing a variety of transport protocols, routing policies, an rate allocation strategies. Bellini is also optimize to perform well in virtual machines, utilizing available resources efficiently. With case stuies on vieo conferencing an messaging, we emonstrate the benefits of Bellini when it comes to esigning an evaluating new inter-atacenter protocols to serve the nees of clou-base applications. I. INTRODUCTION The proliferation of clou computing using geographically isperse atacenters has clearly emonstrate its avantages in cost reuction an scalability. Moving traitional applications to the clou allows the convenience of pay-as-you-go when it comes to using resources on eman, enabling these applications to scale up naturally to meet surging user eman. With applications eploye in atacenters, it is common to see that application traffic flows are relaye by satellite atacenters to backbone atacenters. Chen et al. showe that interatacenter traffic now accounts for a significant amount of the total traffic through the atacenter egress router []. On the other han, with the ubiquitous use of smart mobile evices for streaming an interactive conferencing sessions, geo-istribute atacenters in the clou can be use to offer better performance to a wie variety of mobile applications. Empirical stuies reveal that links between geo-istribute atacenters often offer higher capacities than peer-to-peer connections between two en hosts over the public Internet []. Therefore, it is conceivable to esign new application-layer protocols that take avantage of higher link capacities in interatacenter networks, operate by clou service proviers. The objective of these new inter-atacenter protocols is to ferry application traffic flows via a collection of atacenterto-atacenter paths in the inter-atacenter network, while each of these paths may involve multiple hops. With these new protocols, packets in multiple streaming or conferencing sessions can be route through a high-capacity inter-atacenter network, as if they are traveling aroun the worl in chartere private flights with minimal congestion, rather than cruise ships with long lines waiting for embarkation. Yet, research is still in its infancy when it comes to how new inter-atacenter protocols can be esigne to serve the nees of a variety of streaming, conferencing, an messaging applications, with many research questions remaining open. A major roablock is that such research requires real-worl implementations of new protocol esigns, which can be reaily eploye in actual atacenters. Such implementations are complex an time-consuming to be esigne an realize. In this paper, we present a new system framework, calle Bellini, that ientifies an incorporates common system elements that are neee by prototype implementations of a class of inter-atacenter protocols. Bellini makes it much more convenient to evelop, test, an evaluate new protocols in a realistic clou platform with geo-istribute atacenters, such as Amazon EC. From the groun up, Bellini is esigne to efficiently utilize resources in VMs: it uses asynchronous I/O to process incoming an outgoing packets, with high performance in terms of packet processing rates. In orer to offer better flexibility so that it can be use by ifferent interatacenter protocols, Bellini supports one-to-one, one-to-many, an many-to-many communication, an traffic can be split into multiple paths, each transmitte over multiple relays. Design patterns are also wiely use, making it convenient to plug in customize protocols an components. We evaluate the flexibility an performance of Bellini through two case stuies: vieo messaging an multi-party conferencing. Our case stuies span a range of protocols for routing application traffic flows, incluing choices of transport protocols, routing policies, an flow assignment strategies. We show how ifferent esign choices can be plugge into Bellini an teste in atacenters with ease. Our experimental results, obtaine by running Bellini instances in actual atacenters in the Amazon EC clou, emonstrate the performance we are able to achieve with the framework. The remainer of this paper is organize as follows. In Sec. II, we iscuss the esign objectives of the Bellini system framework. In Sec. III, we present the esign an implementation in etail. In Sec. IV, we stuy two cases an show how Bellini is use to facilitate their evelopment an evaluation.

2 We conclue the paper with a iscussion of relate work (Sec. V) an concluing remarks (Sec. VI). II. DESIGN OBJECTIVES Intuitively, streaming, messaging, an conferencing applications are typically banwith-emaning an elay sensitive, an they may benefit most from high-capacity inter-atacenter networks. Since Bellini is esigne to facilitate the rapi prototyping of inter-atacenter protocols, we wish to ientify share elements of these applications an implement them in a system framework. Let s first examine three representative class of applications: On-eman streaming applications. In these applications, a vieo stream is typically transmitte in an applicationlayer multicast session, from a meia source server to a group of subscribing users. Messaging applications. A meia message, such as a vieo/auio clip, is to be share from one user to another. Though these applications are best-effort in nature an are not as sensitive on elays as streaming, messages will nee to be receive with a reasonably slow elay, since users may interact in these applications. Multi-party vieo conferencing applications. A group of users, each serves as a vieo source, are involve in a conferencing session an transmits her/his vieo stream to other participants. Due to the all-to-all broacasting nature of these conferencing sessions, they can be potentially banwith-emaning an elay-sensitive. Consiering a variety of requirements on application performance, ifferent inter-atacenter protocols will nee to be esigne to cater to the nees of ifferent applications. Despite their ifferent requirements, application traffic will be sent via the inter-atacenter network, with solutions to two problems. At a high level, they nee to manage atacenter noes so that they can be use to ferry traffic flows belonging to a number of concurrent sessions, each involving a group of participants. At a low level, packets are to be transmitte from their sources to the inter-atacenter network, an then relaye to their final estinations, possibly via a number of atacenter-to-atacenter paths, with multiple hops along each path. Bellini is esigne to provie solutions to these problems, as they constitute the share elements in inter-atacenter protocols. To get starte, we first look at the traffic patterns: the traffic can be as simple as a source-estination pair involving two atacenters, or as complex as involving multiple sources an estinations. To organize these traffic flows Bellini aopts a two-tier hierarchy, as shown in Fig. : A conference consists of several noes participating in the same event, such as the sharing of a meia message; a conference further contains one or multiple concurrent sessions, each of which has a specific source an a set of estinations. Taking a multiparty vieo conference as an example, all participants form a conference, an vieo broacasting streams originate from each participant are consiere as sessions. Once a session has been establishe, how shoul packets be transmitte? Governe by an inter-atacenter protocol, packets Fig.. Conference # (conf. creator: a) a other concurrent conferences b c a a b b c c Session #- src: a; st: b/c/) Session #- src: c; st: b/) other concurrent sessions Organizing traffic flows in Bellini with a two-tier hierarchy. coul be sent to one or multiple estination atacenters, using reliable or unreliable connections, through irect paths, multihop relay paths, or multicast paths, epening on ifferent application scenarios. For some elay-sensitive applications, it is also possible that a packet is copie an transmitte through ifferent paths to the same estination. In orer to embrace a wie variety of routing policies, incluing unicast, multicast, multi-hop transmission, an multi-path transmission, Bellini is esigne to provie a flexible packet router at the application layer, allowing traffic flows to be sent to an arbitrary noe an forware by any intermeiate noes. Furthermore, in orer to fully utilize inter-atacenter capacities, it is also common to see that rates of ifferent traffic flows are ynamically ajuste. With ifferent application requirements consiere, it is critical to support both flexible routing policies an ajustable flow assignment, such that Bellini can easily support a wie variety of applications with ifferent requirements an objectives. We now elaborate on two main objectives as our system framework is being esigne: flexibility an performance. Flexibility. Designe as a system framework that supports a variety of clou-base applications, Bellini shoul be highly flexible, so that it helps to simplify inter-atacenter protocol prototyping for networking researchers. To be specific, Bellini shoul allow inter-atacenter protocols to customize their own routing policies an rate assignment strategies, base on certain requirements for ifferent applications. To facilitate such customization, an easy-to-use interface must be provie for the applications to activate available components an configure parameters. To achieve this goal, Bellini supports both APIbase control an file-base configuration. With respect to the API-base control, Bellini provies a set of programming interfaces for applications to monitor an control every etail of the unerlying transmissions in an online fashion, incluing ecisions on which path shoul packets be sent through, or which alternative path shoul be use if congestion is etecte. In practice, Bellini is controlle through three abstract classes: IConference, IRouting an IFlowAssignment. By eriving C++ classes from these abstract classes, a new inter-atacenter protocol can easily create conferences, an change routing policies an flow assignment strategies. Taking customize routing in Fig. as an example, the MyRouting class erive from IRouting instructs Bellini to perioically loa application-specific routing ecisions for each session. When necessary, the application can also reloa routing policies of a given session.

3 class MyRouting : protecte IRouting { /* app-specific variables an functions */ }; RoutingList MyRouting::routingDecisions(const ConfIDType confi, const SessionIDType sessioni) { // eclare in IRouting RoutingList rlist; /* app-specific routing algorithms */ rlist.aroutingentry(/* a routing policy */); // return rlist; } { /* initialization */ MyRouting myrouting(/* init. values */); gbellini.registerroutingobj(myrouting); // } { /* when certain event occurs */ /* make some ajustments */ myrouting.ajustsomething(/* */); /* force Bellini to call IRouting::routingDecisions an reloa routing polices */ gbellini.reloasessionpolicies(confid, sessioni); } Fig.. Implementation of customize routing algorithms using the IRouting programming interface. In aition to API-base control, Bellini also supports the JSON-base configuration file. By writing a human-reaable lightweight JSON file, Bellini allows users to config a wie variety of settings, such as routing policies an rate assignment strategies for iniviual conferences an sessions, without writing any C++ coe. Fig. (a) lists a segment of a Bellini configuration file, showing a transmission session from the source noe in conference. We can see that there exist two routing policies from the source (noe ) to estinations (noe an ), with their respective flow rate assignments. Following such a mix of multi-hop multi-path policies, packets will be transmitte, forware, an uplicate through esignate paths, as shown in Fig. (b). // "ConferenceList": [ { "ConferenceID":, "StartTime": " :: UTC", "Participants": [,,,], "SessionList": [ { "SessionID":, "Protocol": TCP, "SrcNoe":, /* Source Noe ID */ "DstNoes": [,], /* Destinations */ "AverageRate": 80, /* 80 KB/s */ "MaxBurstSize": 50 /* 50 KB at burst */ "RoutingList": [ { "FlowWeight": 5, "PathList": [",",",,"] }, { "FlowWeight": 75, "PathList": ["",","] }, // (a) A segment of the Bellini configuration file. Source Rate=80 KB/s BurstSize=50 KB 80 KB/s 60 KB/s 0 KB/s 80 KB/s 0 KB/s 0 KB/s (5%) 60 KB/s (75%) (b) The corresponing traffic flows. Fig.. An example of configuring Bellini for multi-hop multi-path transmission session from noe to noe an. Performance. Since Bellini is esigne to support the implementation of real-worl applications to be eploye in actual clou atacenters, it shoul be implemente with performance an scalability in min. In particular, it is critical for Bellini to achieve the best possible performance, such that all resources purchase in atacenter are utilize efficiently. Furthermore, when the system scales up, e.g., multiple noes are forming multiple concurrent transmission sessions, which is the norm in reality (e.g., in the vieo streaming scenario), Bellini shoul be capable of hanling a large number of concurrent sessions, each maintaining a high transmission rate. In orer to achieve this goal, the esign of Bellini is guie by the asynchronous event-riven paraigm, in which incoming events (e.g., packet reception) are processe by corresponing hanlers, an subsequent events may be generate for further processing. The avantage of the event-riven paraigm is two-fol. First, the event-riven engine incurs less CPU an memory overhea. When the workloa concurrency of a clou noe is high, the event-riven moel only uses a fixe number of threas, while the threa-per-connection moel will create a large amount of working threas, leaing to excessive overhea of threa context switching. Secon, with the help of the event-riven engine, components insie Bellini can be loosely couple. As long as event hanlers from ifferent components are appropriately registere for specific events, event-base workflows are naturally forme an then components can work seamlessly. III. IMPLEMENTATION With our esign objectives in min, we have esigne an implemente Bellini from scratch, using C++ an the Boost asio asynchronous I/O library. To realize new cloubase applications, inter-atacenter protocols can be easily built on the Bellini framework, an then eploye in VMs at geo-istribute atacenters. Using the interface provie by Bellini, application instances (henceforth calle noes) can establish or join one or more conferences an corresponing transmission sessions. Within a conference, Bellini assists applications to sen an receive ata to/from instances running on other VMs. For ifferent application traffic, combinations of routing policies an rate control strategies can be specifie an execute. In orer to thoroughly monitor the performance of the entire system, instrumentation units are embee in Bellini. We now present further etails on the esign an implementation of the Bellini framework. Conference an Session Management Bellini manages all active transmissions using the aforementione conference-session hierarchy. When a conference is initiate by the application, using either a configuration file or the IConference programming interface, Bellini noe will create an object that correspons to this conference, an register it in a conference listing server. With the conference create, the application can further establish multiple concurrent sessions for actual transmissions among participating noes. Within a session, ata from the session source will

4 be sent to esignate estinations for storage or playback. In orer to maximize its flexibility, Bellini allows the application to customize each iniviual session, by specifying its routing policies an flow assignment strategies in the interface. If a noe in the conference serves as the source of a session, Bellini retrieves content from the application running on this noe, an then supply ata packets to unerlying transmission components. In reality, content may be files (e.g., igital photographs an asynchronous messages) or streams (e.g., conferencing vieos an on-eman vieos). Furthermore, streams can be further categorize into two groups: aaptive bitrate streams, which etects the available banwith an ajusts the stream quality accoringly, an non-aaptive streams. Since Bellini is esigne to support ifferent applications, we accommoate all three types of content, by properly converting them into a flow of ata packets to be transmitte. In aition to using actual content from applications, Bellini also provies a flexible ata generator that can emulate ifferent types of ata sources, which facilitates the testing of new interatacenter protocols. Flexible Source Routing When esigning routing support in Bellini, an important esign choice is whether the routing ecision shoul be mae by the source noe of a session in a centralize fashion, or by iniviual noes in the session in a istribute manner. Different from traitional peer-to-peer routing protocols, Bellini is esigne to transmit traffic flows through atacenters. Since the total number of atacenters is relatively small, only a limite number of noes are involve in inter-atacenter protocols. In that sense, the complexity of centralize routing algorithms can be reuce in the clou. Furthermore, thanks to the excellent connectivity an abunant banwith between atacenter VMs, running a centralize algorithm becomes much more convenient. Taking full avantage of the clou infrastructure, Bellini aopts the source routing paraigm to achieve better performance. With source routing chosen, we have esign flexible structures in Bellini to escribe ifferent routing policies, incluing irect, multicast, multi-hop, an multi-path transmissions. As shown in Fig., the RoutingInfo to be embee in the packet heaer consists of one or more segments of Pathlet ata, with each Pathlet segment representing a next-hop noe. Within a Pathlet segment, the next-hop noe is ientifie by a unique noe ientifier (Noe ID), an the ata in RoutingInfo inicate how this next-hop noe shoul hanle the packet. Since several estinations may exist in a session, we reserve the highest bit in the Noe ID to ientify whether the next-hop is one of the estinations. With the help of these two ata structures, we can easily specify ifferent routing policies in Bellini. Table I lists a few examples of policies an corresponing representations in Bellini. Ajustable Flow Assignment In aition to source routing, another important feature of Bellini is the support of customizable flow assignment, where RoutingInfo := Fig.. Pathlet := Pathlet- (require) Pathlet Length require, bytes require, bytes optional, variable length Pathlet- (optional) Pathlet Length (in bytes) Next-hop Noe ID & Destination Flag Pathlet-N (optional) RoutingInfo The RoutingInfo an Pathlet structures for source routing. TABLE I EXAMPLES OF REPRESENTATIVE ROUTING POLICIES REPRESENTED BY THE ROUTINGINFO DATA STRUCTURE. Routing Category Representation Direct 6 s s s s 5 Multi-hop 0 6 Multicast Multi-path Note: s inicates a source; inicates a estination; the numbers in boxes represent values in fiels of RoutingInfo an Pathlet structures; the superscript number in the Noe ID fiel inicates the highest bit. ata packets from a session can be split into several flows, an each flow is transmitte at a given rate following a specific routing policy. As iscusse previously, Bellini executes routing ecisions at the granularity of iniviual packets in the source noe, by embeing the routing information in each packet. Such a flexible esign allows us to sen packets carrying ifferent RoutingInfo heaers, each of which represents the path of a traffic flow, an then packets will be naturally split into multiple flows by the ispatcher. In orer to implement flow assignment in each session, we organize all active flows in the same session as a traffic flow list at the source noe, an each entry in the list represents a traffic flow an has the corresponing RoutingInfo heaer cache. When a packet in a session to be sent, Bellini ranomly choose an entry from this session s flow list, an embe the cache routing information into this packet. By allowing the application to assign customize statistical istribution to entries, packets will be sent in ifferent flows at given probabilities, an thus ifferent portions of traffic flows will be transmitte in a controlle manner. To further enhance the flexibility of Bellini, an application is able to ynamically change the flow assignment istribution of each iniviual session, by inheriting the IFlowAssignment abstract class. Supporting Concurrent Conferences an Sessions Bellini is esigne to support clou-base applications, an it is the norm to have multiple ongoing conferences an sessions, when the system scales up. Furthermore, in a large-scale system, conferences an sessions may start an en frequently. Hence, it is critically important to efficiently

5 support concurrent traffic sessions in Bellini s implementation. First, the Bellini ispatcher is implemente with conference/session awareness. For each session, its corresponing routing an flow assignment ecisions will be loae into a per-session internal object for speey access. In this way, each session can operate separately without affecting each other. Secon, we must think carefully how outgoing packets of the ispatcher particularly, packets from ifferent sessions but to the same next-hop noe shoul be transmitte, to support a large number of concurrent sessions. Intuitively, a solution is to establish separate connections from the local noe to the next-hop noe, with each connection use by one ongoing session. However, such an approach will incur aitional overhea (e.g., hanshake an slow-start) when creating new connection for each session. To ensure system performance, multiplexe noe-to-noe connections is aopte in Bellini, by sening packets esignate to the same next-hop noe through the same connection. In orer to implement such an efficient an scalable esign, we create a ata feeer object for each next-hop noe, an each ata feeer collects packets from the Bellini ispatcher to be sent to a particular next-hop noe. As shown in Fig. 5, within each ata feeer, we maintain a list of per-conference queues to buffer packets from ifferent conferences, rather than queueing all packets in a share buffer. On one han, such a esign provies the flexibility to balance or prioritize ongoing conferences in Bellini. As a transmission opportunity comes, the ata feeer can pop a packet from per-conference queues in a roun-robin manner or in a prioritize orer specifie by the application. On the other han, once a conference is terminate, associate queues can be immeiately remove to eliminate useless packets, instea of scanning share queues. It is also worth noting that as multi-hop transmissions are allowe, queues in an intermeiate noe may overflow when the congestion occurs. In such a case, Bellini will notify all involve noes so that the application can take proper actions. Conf. Session - Session - Conf. Session - Fig. 5. Dispatcher Data Feeer for Noe Conf. Conf. Conf. K Data Feeer for Noe Conf. Conf. Conf. K An illustration of ata feeers in Bellini. Implementing High-Performance Packet Delivery With packets queue in ata feeers, we are reay to eliver them to the corresponing next-hop noes. In out implementation, Bellini provies high-performance packet elivery to other running Bellini noes. Applications can choose ifferent transport protocols in Bellini, with support for both TCP an UDP as transport protocols. In orer to achieve a reasonable fairness when UDP an TCP compete for banwith, TCPfrienly rate control (TFRC) is activate in each UDP connection as the flow control algorithm. With multiplexe transmission, each TCP/UDP connection to a remote noe will be associate with a corresponing ata feeer. Once a transmission opportunity occurs, Bellini immeiately requests a packet from the associate ata feeer an sen it out. Meanwhile, Bellini asynchronously waits for any incoming packets from the network. Upon receiving a packet, a reception completion hanler will be triggere an the packet will be sent to the ispatcher for further processing. In aition to ata packets, all control packets, such as session management messages or congestion notifications, are sent over eicate connections, to timely manage the Bellini system. Network Coing In recent years, we have observe that ranom network coing has been wiely use for peer-to-peer transmissions. With satisfactory performance reporte in the literature [], Bellini supports ranom network coing, so that researchers can simply activate network coing as a component, an then evaluate its suitability in new inter-atacenter protocols. As network coing is a rateless erasure coe, we ecie to incorporate it with UDP an TFRC in Bellini, to provie an alternative transmission protocol supporting both error control an flow control. To be specific, packets to be sent are linearly combine to prouce coe packets, using ranom coefficients in GF ( 8 ). At a receiving noe, the ecoing is performe progressively using the Gauss-Joran elimination. Any relay noe may also prouce coe packets by performing similar operation on the receive coe packets. To provie the best possible performance when the network coing engine is enable, we have inclue a fully optimize network coing coec in Bellini. Our accelerate coec is able to conuct network coing in a parallel manner using SIMD instructions. Instrumentation an Supporting Scripts Since Bellini is primarily esigne as a real-worl eployment platform to evaluate new inter-atacenter protocols, the ability to evaluate its runtime performance is a must. We have implemente instrumentation units in Bellini to closely monitor various performance metrics, e.g., the TCP/UDP throughput, per-session packet forwaring rates, an en-toen elays. Every 0 secons, these performance metrics are reporte to the gstatistics object provie in the interface, so that the application is able to monitor the Bellini runtime. For the convenience of offline performance analysis, perioic performance reports are also written to logs. Last but not the least, Bellini inclues an extensive set of eployment scripts that provies turn-key solutions when it comes to eploying multiple executable instances an configuration files to their respective atacenters, launching them for execution, an collecting logs after they are terminate. Batch processing scripts have also been provie to automate the eployment of a large number of performance tests (perhaps with

6 ifferent configuration settings) without human intervention. IV. CASE STUDIES We now use two case stuies to show how Bellini can facilitate the implementation an evaluation of new interatacenter protocols. In our case stuies, the flexibility an performance of Bellini are assesse thoroughly. CPU Usage (%) Memory Usage (%) A. Vieo Messaging with Minimize Traffic Costs With increasing uses of messaging applications on mobile evices, it is conceivable that, not only text, short vieos can also be message. An, such messaging is not as sensitive to en-to-en elays as streaming an conferencing applications. If vieos to be message are transmitte over inter-atacenter networks with high-capacity links, we can focus more on the operational costs of running such vieo messaging service. We iscover that percentile-base charging moels that are typically use in inter-atacenter networks may provie further opportunities to reuce operational costs: if some traffic is alreay generate on one link, transmitting less traffic in subsequent time intervals will be a waste of capital investment. Therefore, a possible way to reuce costs is to esign routing an flow assignment for traffic flows so that the uner-utilize time intervals are minimize as much as possible. To achieve this goal, a set of algorithms has been esigne to minimize the clou operator s costs on messaging traffic, by optimally routing flows in an online fashion []. As Bellini is esigne to be flexible, using it to buil a prototype of such a vieo messaging application possibly using intermeiate atacenters as relays is a breeze. By implementing the new algorithms as C++ objects erive from IRouting an IFlowAssignment, vieo traffic across inter-atacenter links can be split an transmitte along multiple multi-hop paths. Thanks to such a flexible support of the Bellini framework, the prototype of the vieo messaging service has no more than, 000 lines of C++ coe. With such a prototype built on Bellini, we use the clou eployment scripts to eploy instances of our prototype in meium VMs in 7 Amazon EC atacenters an evaluate the performance. First, we investigate the relation between the packet processing rate an the resource usage of Bellini, by sening an increasing number of ranomly generate vieo messages. After collecting all the logs, we group performance reports by 5-min intervals, an then erive the average packet processing rate an CPU/memory usage within each interval. As shown in Fig. 6, there exists a strong linear correlation between the processing rate an the CPU usage, which makes it possible to estimate Bellini s performance given the processing power of a VM. Such a preictable performance of Bellini is mainly attribute to the low CPU overhea incurre by the high-performance event-riven engine. With respect to the memory usage, we observe that the memory usage is reasonably low even at a high processing rate, implying that packets are processe in a timely manner. We then evaluate the time consume internally for packet processing, to verify the effectiveness of online routing an Packet Processing Rate (pkt/s) Packet Processing Rate (pkt/s) Fig. 6. Comparisons between the packet processing rate an CPU/memory usage of Bellini. flow assignment. Since each packet will be first combine with a routing heaer to execute the customize routing an flow assignment ecisions, we plot the CDF of the processing time consume on such operations in Fig. 7. It is shown that the average processing time for each packet is as low as.89 µs an the stanar eviation is no more than 0. µs. Recall that all packets, incluing local packets an incoming packets from other noes, will be forware to corresponing next-hop noes by the ispatcher. Fig. 8 further examines internal processing times in Bellini s ispatcher. With an average of 5.7 µs/packet observe, we can erive that the total processing time consume by these two major steps is aroun 7. µs/packet. These observations reveal that Bellini is able to achieve excellent performance in real-worl settings. CDF average =.89 st. ev. = Processing Time (microsec/pkt) Fig. 7. Processing time consume for routing an flow assignment. CDF average = 5.7 st. ev. = Processing Time (microsec/pkt) Fig. 8. Processing time consume on ispatching packets. B. Vieo Conferencing using Inter-Datacenter Networks Traitionally, multi-party vieo conferencing protocols are esigne to use a peer-to-peer architecture. However, ue to a lack of banwith between noes over the Internet, its quality is not satisfactory. Since atacenters in the clou are typically connecte via eicate links, it is conceivable that throughput may be higher by relaying the conferencing session over the inter-atacenter network. In this case stuy, we woul like to use Bellini to valiate the iea of clou-base vieo conferencing, name Airlift []. By elivering live vieo conferencing streams via atacenters, Airlift algorithms try to use network coing an optimal flow control to maximize the total throughput, without violating en-to-en elay constraints. Since Bellini supports network coing assiste multihop transmission, it is trivial to setup the Bellini: after turning on the network coing engine, Bellini is able to automatically

7 5 6 (a) Clou (b) Peer-to-Peer Fig. 9. Topologies supporte by ifferent Bellini configurations, with one of sessions highlighte. Note that noes in Toronto, Waterloo, Beijing an Shanghai are numbere with,, an, respectively; Virginia an Tokyo atacenters are represente by 5 an 6. encoe packets, forwar them through esignate paths using the optimal flow assignment compute by Airlift algorithms, recoe them whenever necessary, an finally ecoe coe packets at estinations for playback. To conuct a preliminary test of Airlift, we first eploy four Bellini instances as conference participants, in PlanetLab noes locate in Toronto, Waterloo, Beijing, an Shanghai, respectively. These four instances forms concurrent sessions in a conference, with each session corresponing to a vieo source at one of participants. As illustrate in Fig. 9(a), we further eploy two Bellini instances in the Amazon EC Virginia an Tokyo atacenters as relay noes for this conference. By analyzing logs prouce by instrumentation facilities in Bellini, we have observe that the throughput can achieve up to.9 Mbps. On the other han, it is observe that the ento-en elay, with an average of 9 ms. For comparisons, we reconfigure Bellini instances in PlanetLab to execute optimal peer-to-peer base packet elivery (shown in Fig. 9(b)). The experiment shows that the achievable throughput is merely kbps with an en-to-en elay of 57 ms on average. Encourage by such observations, we eploy Bellini instances to all Amazon EC atacenters aroun the worl, as relays for multiple source-estination pairs of PlanetLab noes. By writing ifferent configuration files an running scripts, all Bellini instances are launche automatically to conuct various experiments. Table II summarizes the runtime traces between representative cities in ifferent continents. Overall, the collecte logs show that throughput improvements are aroun times. TABLE II PERFORMANCE TRACES BETWEEN CITIES IN DIFFERENT CONTINENTS. Clou / PP Total throughput En-to-en elay (Mbps) (msec) Toronto-Beijing./ /. Vancouver-Berlin./.8 7./0.9 Seoul-Rio 0./. 8.6/0.5 V. RELATED WORK In the literature, very little effort has been evote to the esign an implementation of a flexible an high-performance framework to support inter-atacenter protocols. Before the era of clou computing, several peer-to-peer frameworks, such as PeerSim [5], were esigne to simulate or emulate peerassiste ata transmission protocols. Although these frameworks can be configure to imitate atacenter networks, they cannot help researchers to implement, eploy, an evaluate actual applications in real-worl clou. With respect to application packet forwarer, RON [6] was implemente to route packets in an application-layer overlay network. But, RON only supports simple multi-hop routing, an cannot split a session into multiple flows to conuct fine-granularity control. It also fails to provie a flexible customization interface for clou-protocol prototyping. To support clou-base applications, very few frameworks were propose with focus on ata transmission. The SAM framework [7] was propose solely for the backup traffic in the clou. Different from existing work, Bellini focuses on interatacenter transmission of application traffic flows in the realworl clou environment. Designe as a flexible system framework, Bellini helps researchers to simplify the implementation an evaluation of new protocols that use atacenters in the clou. With flexibility as the most important esign objective, essential elements such as routing an flow assignment, are supporte in Bellini, an a wie variety of customizations can be achieve through the configuration file or the given programming interfaces with ease. VI. CONCLUDING REMARKS This paper presents Bellini, a system framework that is esigne to facilitate the rapi evelopment, clou eployment, an instrumentation of a wie range of inter-atacenter protocols. Governe by the esign objective of flexibility, Bellini supports plugging in customer-tailore routing policies an flow assignment strategies, in orer to meet the nees of ifferent applications. The implementation of Bellini is finetune for performance, so that resources in clou VMs can be efficiently utilize. Bellini supplies most of the features an components that are esire by a variety of applications, such as sharing, conferencing an messaging. Our experiences with two case stuies have shown that, Bellini makes it feasible to evelop an evaluate new protocols using atacenters with ease an satisfactory performance. We will release Bellini as an open-source software release so that other researchers may benefit from the framework. REFERENCES [] Y. Chen, S. Jain, V. Ahikari, Z.-L. Zhang, an K. Xu, A First Look at Inter-Data Center Traffic Characteristics via Yahoo! Datasets, in Proc. INFOCOM, 0, pp [] Y. Feng, B. Li, an B. Li, Airlift: Vieo Conferencing as a Clou Service using Inter-Datacenter Networks, in Proc. IEEE International Conference on Network Protocols (ICNP), 0. [] C. Gkantsiis, J. Miller, an P. Roriguez, Comprehensive View of a Live Network Coing PP System, in Proc. IMC, 006, pp [] Y. Feng, B. Li, an B. Li, Jetway: Minimizing Costs on Inter-Datacenter Vieo Traffic, in Proc. ACM Multimeia, 0. [5] A. Montresor an M. Jelasity, PeerSim: A scalable PP simulator, in Proc. Intl. Conference on Peer-to-Peer (PP 09), 009, pp [6] D. Anersen, H. Balakrishnan, F. Kaashoek, an R. Morris, Resilient Overlay Networks, in Proc. SOSP, 00, pp. 5. [7] Y. Tan, H. Jiang, D. Feng, L. Tian, Z. Yan, an G. Zhou, SAM: A Semantic-Aware Multi-tiere Source De-uplication Framework for Clou Backup, in Proc. International Conference on Parallel Processing, 00, pp. 6 6.