Comments 0

Document transcript

DYNAMIC LOAD BALANCINGACROSS MIRRORED MULTIMEDIA SERVERSAshwatha Matthur,Padmavathi MundurDepartment of Computer Science and Electrical EngineeringUniversity of Maryland,Baltimore CountyBaltimore,MD 21250,USAfashwath1,pmundurg@csee.umbc.eduABSTRACTThe purpose of this paper is to present protocols for efﬁ-cient load balancing across replicated multimedia servers ina Metropolitan Area Network.Current multimedia infras-tructures,even when they use mirrored servers,do not havestandardized load balancing schemes.Existing schemes fre-quently require participation from the clients in balancingthe load across the servers efﬁciently.We propose twoprotocols in this paper for fair load balancing without anyclient-side processing being required.Neither protocol re-quires any change to the network-level infrastructure.Us-ing network packet loss and packet transmission delay asthe chief metrics,we show the effectiveness of the proto-cols through extensive simulations.Keywords:Media streaming,Mirrored Servers,LoadBalancing.1.INTRODUCTIONStreaming applications such as directly usable online videoand audio are becoming increasingly popular on the Inter-net.With this increasing popularity,several mechanismshave been introduced to improve the quality and avail-ability of streaming media.The mechanisms are criticalsince streaming applications require more stringent QoSthan usual Web services.In this paper,we provide two pro-tocols for load balancing and QoS in mirrored multimediaservers for streaming applications.The ﬁrst of the two protocols we propose uses a cen-tralized load distribution algorithm.The different mirroredservers communicate the degree to which they are loadedto a central server.All client requests are received by thecentral server,which uses the information it has about theglobal state to distribute client requests evenly.The secondprotocol does not use a central server and has a token pass-ing scheme to split and distribute each client request equallyacross the servers.The distribution achieves diffusion of thetrafﬁc across several different routes.Through simulationexperiments,we evaluate both protocols against an infras-tructure with no load balancing in effect.The metrics usedto evaluate the quality of streaming are the average packetloss rate and the average packet transmission latency.Theresults showsigniﬁcant decrease in the packet loss rates andlatencies with our protocols.In this and the following paragraph,we describe researchthat is relevant to the current work.Starting with tech-niques related to mirrored servers and load balancing,My-ers,Dinda and Zhang[1] evaluate the techniques for se-lecting a server given a set of mirrored servers.Crovellaand Carter use probes in [2] to evaluate bandwidth and dy-namically select a server.Conti,Gregori and Panzieri[3]propose several load distribution mechanisms to achievehigher availability and quality of data.Bunt et al[4] cou-ple load balancing with caching to handle requests to clus-tered Web servers under very high loads.Colajanni,Yu andDias[5] use DNS as a centralized scheduler for load balanc-ing.Nguyen and Zakhor[10] use a set of mirrored serverswhich co-ordinate using rate allocation and packet parti-tion algorithms to achieve high throughput.Padmanabhanet al[11] use a scheme where data is distributed among theclients,which forward the data in case of a server overload.The above approaches differ from the present one becausewe focus on multimedia streaming and thus take packet lossinto consideration as a QoS parameter.We also eliminateclient-side processing for higher efﬁciency.For Internet simulation,we use the Tiers topology gen-eration mechanism,proposed in Doar[6].The topology isgenerated in terms of several tiers such as LAN,MAN andWAN.Mellia,Carpani and Cigno[8] illustrate tools such asTstat to collect data about Internet trafﬁc on large scales.Recent research indicates that it is possible to provide gen-eral models that fairly represent trafﬁc on the World WideWeb,using distributions such as M/Pareto for sessions andPoisson for arrival patterns[7].Trace collection for videotraces is illustrated in Fitzek and Reisslein[9].The rest of the paper is organized as follows.Section 2explains our load balancing protocols in detail.Section 3provides the details of the simulation model,simulation pa-rameters and results.We conclude this paper in Section 4.2.PROTOCOLSIn this section,we present details of the proposed proto-cols for load balancing and QoS.The Centralized ControlProtocol achieves load balancing by having a central serverdistribute client requests across a set of video servers.Inthe Distributed Control Protocol,each client request is splitinto several substreams and different video servers processFigure 1:Centralized Control Protocoldifferent substreams.2.1.Centralized Control Protocol (CCP)In this protocol,the video servers periodically send state in-formation to the central server,indicating their current load.The central server maintains the global state,and thus hasknowledge about how loaded each of the video servers is.The precision of this knowledge depends on how often thevideo servers send information about their loads to the cen-tral server.Whenever a connection request comes in,thecentral server forwards it to the least loaded video server.Ir-respective of the streaming protocol,TCP is used for inter-server communication so as to prevent losses of messagesfromthe video servers to the central server and vice versa.If a video server fails to send any message about its stateinformation to the central server,the video server is as-sumed to be inactive or overloaded.No client requests areforwarded to the video server until it becomes active againand resumes sending status messages.The protocol can bethought of as a single-stream,single-server protocol,sinceexactly one server services each client request,and there isno breaking up of the streamamong servers.2.2.Distributed Control Protocol (DCP)Most centralized control solutions suffer fromthe overheadof having a single point of failure.Limited resource avail-ability at the central server can also be an overhead underhigh load.However,they have the advantage of simplicity.To evaluate these factors,we present our second protocolusing a distributed control architecture.In the distributed control protocol,a set of video serversform a token passing arrangement to serve each client re-quest.Let the number of servers be K.When a connec-tion request comes to a server from a client,it breaks upthe requested stream into K segments,where K is the num-ber of servers.Let each segment take n seconds to stream.Each segment has a sequence number i,1  i  K.Theserver streams the ﬁrst segment.A period D seconds be-fore it completes transmission of the ﬁrst segment,it handsover control to another server,chosen at random.The sec-ond server processes the second segment,and hands overcontrol to a third server,and so on.While forwarding theFigure 2:Distributed Control Protocolrequest,a sequence number and a server-list are also for-warded.The sequence number indicates the segment that isto be processed by the next server.The server-list containsa list of servers which have already processed segments ofthis stream.While choosing a new server,a server not inserver-list is chosen.While forwarding the request,eachserver appends its id to the server-list.This protocol can bethought of as multiple-server,single-stream,since a singlestream is serviced in several segments and each request isprocessed by several servers.In case the newserver does not respond,a different servernot present in server-list is chosen.In case none of theservers not in server-list respond,a server already in server-list has to be chosen.Event:Connection request fromclient to a server.1.Start processing segment 1.(i=1)2.D secs before completion,send to a server chosenat random,fConnection req,Seq num i+1 (next segment),server-list = (Server-id) gEvent:fConnection req,seq numi,server-listg receivedfromanother server.1.start processing segment i.2.server-list = server-list + (Server id)3.if (i=K),end of stream.Otherwise,4.D secs before completion,choose a server not inserver-list,and forward fconn req,i+1,server-listg to theserver.3.SIMULATION SETUP AND RESULTSNetwork Simulator 2.0 is used for simulating the networkand the multimedia architecture.The multimedia ﬁles aresimulated by traces of actual videos encoded in MPEG-4format[9].3.1.SIMULATION SETUPA Metropolitan scale network with LANs being connectedto different corporate networks is used for simulation.Thetopology is simulated using the topology generator Tiers1.1[6].Realistic values for different network parameters,such as nodes/LAN,LANs/MAN,are used as illustratedin Table 1.In order to model background Internet trafﬁc,ParameterDetailsNetworkMANs,generated by Tiers1.1Number of nodesApprox.1100Trafﬁc arrival patternPoisson,Mean 50-300/hrTelnet and FTP sessionsM/Pareto 0:9 < a < 1:1Background trafﬁcM/Pareto ON/OFF periodsSimulation period500 hoursLink capacity10 MbpsAve Length of video15 min;heavy-tailedMANsNm= 10Nodes/MANSm= 10LANs/MANNL= 5Nodes/LANSL= 20Total number of linksapprox 1250Intranetwork redundancyRM= 2;RL= 1Table 1:Simulation Parameterswe note a few general characteristics of Web trafﬁc:Traf-ﬁc on the Internet is characterized by a large proportion ofTCP trafﬁc and a relatively smaller proportion of UDP traf-ﬁc.TCP trafﬁc,notably Telnet and FTP,have a Poissonarrival pattern.Telnet and FTP sessions can be modeledby a Pareto distribution with heavy tail.Background trafﬁccan be modeled as superpositions of ON/OFF periods ex-pressed as Pareto distributions;0:9 < a < 1:1[7].We useall of the above factors to generate realistic background traf-ﬁc.Results fromTstat,a network monitoring tool describedin [8] are used to provide quantitative information regard-ing the proportion of TCP and UDP ﬂows and other data inour simulation.Table 1 summarizes information about thesimulation.Results fromDoar[6] are used to apply variousparameters for the topology of the network.The intranet-work redundancy parameter refers to the number of edgesbetween nodes of the same type.The simulation architecture consists of 4 identical videoservers and 100 multimedia clients connected over ametropolitan area network.The multimedia clients gener-ate requests in a Poisson arrival pattern.The average num-ber of requests per hour is varied from50 to 300 during theexperiments.Constraint on packet transmission periods:To deter-mine the maximumacceptable packet delay,we use the fol-lowing approach:Let playback begin at the receiver after nseconds worth of video has been cached.Let the averagedownload rate be X bytes/sec,and let the playback rate be Bbytes/sec.Let the instant at which playback begins be t = 0.Therefore,nB bytes of data have already been transmitted.We derive an expression for a constraint that must holdfor the packet to reach the destination in time and be usable.Consider the mthbyte of the stream.Since the playback isat B bytes/sec,it should be,ideally,played at Tplay= m=Bsec.Since downloading is at X bytes/sec,the instant atwhich it will be transmitted is:Tsent= (m  nB)=X,because nB bytes have already been transmitted.The fol-lowing inequality must hold if the packet is to reach the0501001502002503003500.511.522.533.544.555.5Congestion Vs Streams/hourStreams/hourAve Packet Loss (%)No Load BalancingCCPDCPFigure 3:Congestion Vs Number of Streams/hr:Packetlosses are reduced signiﬁcantly with distributed controldestination in time:(Tsent+packetlatency) < TplayOr,packet latency < (mBmnBX)While measuring packet loss rates,we identify packetsthat have too high a delay to be played back,and treat themon par with lost packets.3.2.RESULTSExperiments are conducted using the above simulationsetup to evaluate the performance of the two protocols.They are compared against a base scenario where no loadbalancing is involved.The base scenario uses the same in-frastructure,but no attempts are made to distribute the traf-ﬁc across the servers.The server which receives a clientrequest processes it in its entirety.The average packet losspercentage and the average packet transmission delay aremeasured,with the number of streams per hour being in-creased from 50 to 300.The results are averaged over ﬁvetrials;conﬁdence interval analysis for 95% conﬁdence isconducted over the sets of ﬁve experimental values.Thegraphs are providedwith errorbars that showthe half-widthsof the conﬁdence intervals.Figure 3 shows the average packet losses as the num-ber of streams is increased.The distributed protocol faresbest,since it achieves the highest degree of load distributionacross the network.Each client request is diffused acrossseveral different routes,and thus no particular route gets ahigher amount of trafﬁc than others.Packet losses due tolocal congestion conditions are minimized,since the traf-ﬁc is distributed evenly across the servers.The centralizedcontrol protocol does slightly worse since the global state isupdated only once in a while and thus,the load distributionis not ideal.Figure 4 shows the average packet transmission delaysfor the same increases in the number of streams per hour.The distributed control protocol does slightly worse than thecentralized control protocol,since each stream is servicedby all servers,both near and far fromthe client.It still doesbetter than when there is no load balancing,since delays0501001502002503003506080100120140160180200220Packet Latencies Vs Streams/hourStreams/hourAve Pakcet Latency (ms)No Load BalancingDCPCCPFigure 4:Packet delays Vs Number of Streams/hr:Packetdelays are reduced signiﬁcantly with centralized control0100200300400500600010002000300040005000600070008000900010000Time (Sec)Buffer Content (Kb)Buffer Size Vs TimeNo Load BalancingDCPFigure 5:Buffer Level Vs Time:Buffer level is conservedmore effectively with load balancingdue to congestion are minimized.In the centralized controlprotocol,the stream is either serviced by the nearest serveror,in case the nearest server is highly loaded,a server thathas lower load and thus can serve the streamfaster.Higher packet loss rates also lead to faster depletion ofclient buffers.This is because higher packet loss rates im-ply lower ﬁll rates for the client buffer.Figure 5 shows theresults of an experiment that measures the amount of datain the client buffer as a function of time.In the scenariowith no load balancing,higher packet losses are involved.As a result,the client buffer runs out much sooner,and re-quires to be reﬁlled more often.This leads to more frequentdiscontinuities in video playback.In the scenario with loadbalancing using DCP,there are fewer packet losses,lead-ing to slower depletion of the client buffer.This means thatthere are less frequent discontinuities in playback.Figure 5clearly illustrates this aspect.4.CONCLUSIONSIn this paper,we have presented two protocols for load bal-ancing in a mirrored multimedia server environment.Theprotocols avoid client-side processing.The only abilityclients need to have is the ability to accept connections frommore than one server.The protocols do not require anychange to the network infrastructure either,since the inter-server communication occurs at the transport level.The twoprotocols have been evaluated in terms of their improve-ments to packet losses and packet latencies to the client.Thereduction in packet loss is of particular signiﬁcance to mul-timedia transmission.Packet transmission delays are alsoreduced signiﬁcantly in both the protocols.Smaller packettransmission delay helps in maintaining a smaller buffer onthe client side for streaming applications.5.REFERENCES[1] A.Myers,P.Dinda,and Hui Zhang,”Performancecharacteristics of mirror servers on the Internet,”Proc.of IEEE INFOCOM,Mar 1999.[2] M.Crovella and R.Carter,”Dynamic Server Selec-tion Using Bandwidth Probing in Wide-Area Net-works,” Proc.of IEEE INFOCOM,1997.[3] M.Conti,E.Gregori,F.Panzieri,”Load Distributionamong Replicated Web Servers:A QoS-Based Ap-proach,” in WISP 1999,ACMPress,Atlanta.[4] R.B.Bunt,D.L.Eager,et al.,”Achieving LoadBalance and Effective Caching in Clustered WebServers,” The fourth International Web CachingWorkshop,San Diego,CA,Mar-Apr 1999.[5] M.Colajanni,P.S.Yu,and D.M.Dias,”Analysis oftask assignment policies in scalable distributed Web-server systems,” IEEE Transactions on Parallel andDistributed Systems,9(6):585–600,1998.[6] M.Doar,”A Better Model for Generating Test Net-works,” Proc.of IEEE GLOBECOM,1996.[7] T.D.Neame,M.Zukerman,”Modeling BroadbandTrafﬁc Streams,” Proc.of Globecom ’99,Rio deJaneiro,Brazil,Dec,1999.[8] M.Mellia,A.Carpani,R.Lo Cigno,”Measuring IPand TCP behavior on an Edge Node,” Planet-IP andNebula Joint Workshop,Jan 2002.[9] Frank H.P Fitzek,Martin Reisslein,”MPEG-4 andH.263 Video traces for Network Performance Evalua-tion,” IEEE Network Magazine,Vol.15,No.6,pages40-54,Nov-Dec 2001.[10] T.Nguyen,A.Zakhor,”Distributed Video Streamingover the Internet,” Proc.of MMCN 2002,San Jose,CA.[11] V.N.Padmanabhan,H.J.Wang,P.A.Chou,andK.Sripanidkulchai,”Distributing Streaming Me-dia Content Using Cooperative Networking,” ACMNOSSDAV,Miami Beach,FL,May 2002.