Solutions for Real-Time Communication over Best-Effort Networks

Transcription

1 Solutons for Real-Tme Communcaton over Best-Effort Networks Anca Hangan, Ramona Marfevc, Gheorghe Sebestyen Techncal Unversty of Cluj-Napoca, Computer Scence Department {Anca.Hangan, Ramona.Marfevc, Abstract The problem of transportng real-tme traffc over general purpose networks generates ssues whch need to be analyzed. Ths paper has the objectve of comparng some of the solutons proposed n ths specfc research area and emphaszng ther most mportant advantages and drawbacks. Moreover, a real-tme traffc model s proposed as a soluton for IP network bandwdth estmaton. The proposed model, fnally, s evaluated by smulaton of the behavor of perodc real-tme traffc on IP networks 1. Introducton In dstrbuted real-tme systems the communcaton nfrastructure has to exhbt a determnstc behavor to guarantee the satsfacton of tmng requrements [1]. Durng the last years, a sgnfcant trend emerged for usng best-effort (non-determnstc) networks for realtme communcaton [-]. Ths trend was caused by techncal developments such as the ncreasng network bandwdth (Gbps) and the development of new QoS mechansms. Interoperablty requrements between real-tme applcatons and organzatonal software were another cause. Researchers are now proposng solutons for accommodatng real-tme traffc on best-effort nfrastructures. Solutons cover lower layers (e.g. MAC) as well as hgher layers (e.g. transport and network) of the OSI model. In some approaches collsons are avoded through mplementng medum access control mechansms for Ethernet such as TDMA or token-passng. In other approaches swtches and traffc shapers are used to separate collson domans and to avod bursts [3] n Ethernet networks. Another possble soluton s to mplement the.1p standard n swtches, whch provde a prorty-based mechansm for QoS delvery at MAC level []. Some dfferent approaches solve relablty and real-tme ssues by developng new transport level protocols (Real-tme Transport Protocol) n order to replace TCP and UDP []. Other approaches use QoS mechansms such as resource (bandwdth) reservaton [7][] and dfferentated servces [9] to solve the requrements of real-tme traffc. In ths context, there s a need for analyzng the ssues and evaluatng the solutons proposed untl now from dfferent pont of vews, lke the classes of applcatons addressed, the tmng requrements whch can be guaranteed or predcted, the mpact of changes that have to be made on the network nfrastructure, scalablty, and so on. Followng ths need, n the frst part of the paper, we analyze some of the proposed solutons for the ssues of real-tme communcaton over best-effort networks n order to emphasze ther man characterstcs, advantages and possble drawbacks. In the second part of the paper we propose a real-tme traffc model as a soluton for IP network bandwdth estmaton. Moreover, we conduct a set of smulatons n order to characterze the behavor of perodc real-tme traffc n the absence and n the presence of best-effort traffc on the same network. The paper s organzed as follows. Secton presents an analyss of dfferent possble solutons for real-tme communcaton over best-effort networks. Secton 3 contans a descrpton of the real-tme traffc model and the parameters used for evaluaton. Secton descrbes the smulaton scenaros. Results analyss s presented n Secton. Secton concludes the paper.. Transportng real-tme traffc over general purpose networks Two man QoS mechansms [7-9] have been proposed to solve the problem of transportng real-tme traffc whle guaranteeng desrable propertes for realtme communcatons: Integrated Servces (IntServ) [1] and Dfferentated Servces (DffServ) [11]. IntServ archtecture s based on reservng network resources between ndvdual flows, whle DffServ archtecture s based on provsonng network resources

2 between traffc aggregates. Although both the IntServ and DffServ approaches can offer dfferent servce classes, the man trade-off between these two approaches s the one of determnstc guarantees versus bandwdth utlzaton. IntServ reles on admsson control and can offer determnstc bandwdths and end-to-end delays to ndvdual flows at the cost of placng strct resource reservatons that guarantees the worst case scenaro. Snce ths case occurs very seldom, a lot of bandwdth s wasted. On the other hand, DffServ prortzes flows accordng to ther servce class and provdes much better bandwdth utlzaton, because no control admsson s performed. IntServ assumes that requrements can only be acheved by reservng resources for a partcular flow. Thus, n a real-tme communcaton envronment wth many defned flows, nformaton about reservaton needs to be stored/processed/accessed. Thus managng reservaton states at such nodes causes sgnfcant overhead and degrees the performance of the nodes. In other words, IntServ has a scalng problem. Also, another problem wth IntServ archtecture s that the hosts and applcatons should be RSVP-aware, as Resource ReSerVaton Protocol (RSVP) [1] s the default reservaton protocol, although other protocols are also allowed. Snce both IntServ and RSVP assumes that the applcaton has to know the traffc characterstcs and that the reservaton s made before the actual data transmsson, IntServ/RSVP does not seem to be useful for burst traffc transmsson. It can only be a useful soluton n a network where the number of flows s lmted, the lnk s often overloaded and a dynamc admsson control s needed. DffServ addresses the scalablty problems of IntServ approach by aggregaton of ndvdual flows to a small number of dfferent traffc classes for whch servce dfferentaton s provded. Packets are dentfed by smple markngs that ndcate the respectve class. In the core of the network, nodes do not need to determne whch flow a packet belongs, only whch aggregate behavor has to be appled. Edge nodes mark packets and ndcate whether they are wthn profle or, f they are out of profle, n whch case they mght even be dscarded. A partcular markng on a packet ndcates a so-called Per Hop Behavor (PHB) that has to be appled for forwardng of the packet. Currently, the Expedted Forwardng (EF) PHB [13] and the Assured Forwardng (AF) PHB [1] groups are specfed. The EF PHB s ntended for buldng a servce that offers low loss, low delay, low delay jtter, assured bandwdth, end-to-end servce through DffServ networks, namely a Premum Servce. The AF PHB s desgned to provde a servce superor to best-effort but one that does not requre the reservaton of resource wthn an nternet and does not requre the use of detaled dscrmnaton among flows from dfferent sources. DffServ approach takes nto account the structure of the network and ts requrements. The archtecture s scalable, servces are based n relatve dfferentaton and no hard guarantees are provded. Although DffServ s a very smple and robust archtecture, for real-tme communcatons t has one sde-effect: ts statc nature. The traffc condtonng specfcatons must be pre-confgured nto the boundary nodes and the nteror nodes have to be pre-dmensoned. Several protocols to support real-tme communcaton over shared-medum Ethernet have been proposed [][]. However, these protocols are ether changng the Ethernet standard or do not add guaranteed real-tme servces. Real-tme communcaton over swtched Ethernet has also been proposed (EtheReal) [1]. EtheReal project bult a scalable real-tme Ethernet swtch, whch supports bt rate reservaton and guarantee over a swtch wthout any hardware modfcaton of the end-nodes. It s throughput orented, there s no or lmted support for hard real-tme communcaton and t has no explct support for perodc traffc. A commonly employed method to help reduce the delay ntroduced by forwardng and queung wthn a network s defned by IEEE.1p [] standard (now ncorporated n the latest.1d standard). Whle ths s a very effectve mechansm to reduce latency, t becomes hghly neffcent when appled to guaranteed bandwdth. The standard uses prorty to decde whch traffc to dscard frst n case of congeston and actually offers a herarchcal way of droppng guaranteed bandwdth. In addton, a prorty mechansm appled to guaranteed bandwdth only works when end users actually subscrbe to dfferent levels of prorty. If several subscrbers choose the same prorty, whatever the prorty value s, t wll be mpossble for the devce to drop guaranteed bandwdth n a herarchcal order, resultng n random drops of traffc. Although each real-tme applcaton could nclude ts own mechansms for supportng real-tme transport, there are a number of features that warrant the defnton of a common protocol. A standards-track protocol desgned for ths purpose s real-tme transport protocol (RTP) [17]. It supports the transfer of realtme data among a number of partcpants n a sesson. Although RTP can be used for uncast real-tme transmsson, ts strength les n ts ablty to support multcast transmsson. RTP s best suted to soft real-

3 tme communcaton. It lacks the necessary mechansms to support hard real-tme traffc. A separate control protocol (RTCP) [17] also operates n a multcast fashon to provde feedback to RTP data sources as well as all sesson partcpants. RTCP provdes feedback on the qualty of data dstrbuton. Because RTCP packets are multcast, all sesson members can assess how well other members are performng and recevng. Sender reports enable recevers to estmate data rates and the qualty of the transmsson. Recever reports ndcate any problems encountered by recevers, ncludng mssng packets and excessve jtters. 3. Perodc real-tme data flow model Real-tme traffc conssts of message streams that are contnuously delvered through the network from source to destnaton. Usually, there are three types of real-tme messages: perodc (e.g. sensor acquston data), aperodc and sporadc (e.g. compressed vdeo streams) [1]. For the purpose of ths paper, only perodc messages are consdered. Perodc messages are characterzed by three parameters: nterarrval perod T, relatve deadlne D and maxmum packet length l (t s consdered, for smplcty, that messages are not splt nto more packets). For perodc messages, the deadlne has to be satsfed. Perodc real-tme traffc s modeled as a sum of data flows []. A data flow s the sum of all packets sent through the network that have the same source, destnaton, nterarrval perod and maxmum packet length. Perodc real-tme data flows can be represented as n-tuples: ( T, D, Src, Dest l ) DF =, (1) where: T data flow perod D relatve deadlne Src, Dest data flow source and destnaton l maxmum packet length Based on the perodc real-tme data flow model and a rate-monotonc prorty assgnment, n our prevous work [] we developed an equaton set whch can be used to estmate the bandwdth needed for a set of perodc data flows that never mss ther deadlnes. The worst case scenaro was consdered and the equatons obtaned proved to be an upper bound for bandwdth requrements. Bandwdth and end-to-end delays for a set of data flows are computed usng the followng equatons: d () = C + RTT + C () j P ( j ) > P ( ) C + d ( t ) = C + RTT + d * Cj + { Ck P( k) < P( )} P( j) > P( ) Tj where: P() prorty for flow d end-to-end delay tme for flow C transmsson tme for flow RTT round-trp tme (f usng UDP packets, to be RTT substtuted by ) mum bandwdth computed n ths manner can be used when evaluatng an Ethernet or IP network whch s to be used for delverng real-tme traffc exclusvely. When best-effort and real-tme traffc coexst on the same network, estmatng network bandwdth s a complex problem. Equatons () have to be modfed to nclude the effect of best-effort packets on end-to-end delay tmes of real-tme packets. The end-to-end delay tme of a real-tme packet s nfluenced by all packets that are encountered on ts route. Whle for perodc data flows, the number of packets can be computed easly, for best-effort flows (especally TCP) the number of packets can be, n the best case, roughly estmated. When measurng the performance of a real-tme communcaton system, the followng parameters are sgnfcant: deadlne mss rate, delay jtter and packet loss. For hard real-tme applcatons deadlne msses are not acceptable and message delay must be guaranteed a-pror. Delay jtter may not cause serous problems as long as deadlnes are satsfed. In the case of soft realtme applcatons deadlne msses are tolerable f below a certan threshold, but, under some partcular condtons, delay jtter may have negatve effects. For these reasons, the goal for real-tme communcaton systems s to mnmze both end-to-end delay and delay jtter tmes.. Experments Experments have been conducted wth the objectve of measurng the end-to-end delay, delay jtter and packet loss for multple perodc real-tme data-flows, n an attempt to evaluate ther behavor on an IP network. The smulaton study was performed on Network Smulator (NS-) [1], verson.33. The Smulaton results are evaluated n dfferent cases usng the topology depcted n Fg. 1. The proposed smulated topology conssts of nne nodes.

4 Fgure 1. The smulaton topology and data flows Nodes are connected wth full-duplex bdrectonal lnks. All lnks have the same avalable bandwdth and propagaton delay. Constant Bt-Rate (CBR) agents were attached to each source node (N, N, N and N) and used to generate perodc, fxed sze packet traffc n the network. User Datagram Protocol (UDP) s used as transport layer protocol to mnmze the overhead of establshng a connecton. Four perodc real-tme data flows were defned wth the parameter settngs summarzed n Table 1. Experments n four scenaros are presented. For the frst scenaro, equatons () are used to derve the maxmum bandwdth needed by the set of data flows n order to satsfy deadlnes. The computed maxmum bandwdth s Mbps. It s assumed that the propagaton delay s neglgble. In the second scenaro the same set of data flows s released on a network wth lnk bandwdth decreased to 1 Mbps (propagaton delay s neglgble), n order to observe the effects of decreasng the computed maxmum bandwdth on end-to-end delay and delay jtter tmes. In the thrd and fourth scenaros we ncluded an addtonal TCP connecton wth FTP traffc. The objectve was to observe the nfluence of best-effort traffc on real-tme traffc. The lnk bandwdth was set to Mbps and propagaton delay was consdered neglgble n both cases. For the thrd scenaro F was substtuted by FTP traffc over TCP, as F affects all other data flows and has the longest route. For the fourth scenaro F was substtuted by FTP traffc. F affects F and F3 more, and F1 less (just n N). The rest of the data flows parameters are left unchanged.. Results analyss In the case of the frst scenaro all deadlnes are satsfed (Fg. ) and delay jtters were very small (Fg. 3). For the second scenaro, deadlnes were also satsfed (Fg. ), delay jtter was small, but there was an ncrease of average delay jtter on the majorty of flows (Fg. ). No packet loss was recorded for these scenaros. By comparng the results of the frst and second scenaros, we conclude that the maxmum bandwdth computed wth equatons () s hghly overestmated, and the resultng network utlzaton s very low. In the case of hard real-tme traffc the overestmaton s necessary because deadlnes have to be guaranteed n the worst case scenaro. But, n the case of soft real-tme traffc, bandwdth utlzaton can be ncreased to some extent, because deadlne msses are tolerated. For the last two scenaros we recorded a sgnfcant jtter ncrease (Fg. and ). In the thrd scenaro the most affected was F and n the fourth scenaro, F. Many deadlne msses were recorded n both scenaros (Fg. 7 and 9). For the fourth scenaro F1 was the only flow not to experence deadlne msses (Fg. 9(a)). Measured packet losses were small (below.11%). We conclude that for scenaros three and four, the most affected real-tme flows are the ones whch ntersect wth the best-effort flow n the largest number of nodes. s and jtter tmes are badly affected, but packets are rarely lost. Table 1. Parameter settngs for perodc realtme data flows Flow Source Destnaton Perod Packet sze (B) F N N7. 1 F1 N N F N N7 1 1 F3 N N Concluson Usng general purpose networks for real-tme communcaton generates a number of ssues whch need to be analyzed. In the frst part of ths paper, we evaluated some of the solutons proposed for these specfc problems. As a result of ths evaluaton we can conclude that at the present tme ssues are only partally solved. Even though mportant steps have been made, hard tmng requrements are dffcult to guarantee over best-effort networks. In the second part of the paper we proposed a perodc data flow model. Ths model was used n dfferent smulaton scenaros to characterze the behavor of real-tme traffc over IP networks. The smulaton results analyss for dfferent scenaros enable us to estmate the IP network bandwdth n the case of perodc real-tme traffc, assumng that: there are no other types of traffc on the network, data flows perods are gven, maxmum packet sze s known for

5 each flow, RTT s prevously measured. Also, when accommodatng best-effort traffc n parallel wth realtme traffc, only that flows that ntersect wth the besteffort traffc n the largest number of nodes are affected n terms of delay tmes and jtter tmes. End-to-end delay f f1 f f3 Flows (1st scenaro) Mn Fgure. s (1 st scenaro). Delay jtter f f1 f f3 Flows (1st scenaro) Mn Average Fgure 3. Delay jtter tmes (1 st scenaro). End-to-end delay f f1 f f3 Flows (nd scenaro) Mn Fgure. s ( nd scenaro) Delay jtter f f1 f f3 Flows (nd scenaro).31 Mn Average Fgure. Delay jtter tmes ( nd scenaro) mum delay jtter f f1 f3 Flows (3rd scenaro) Fgure. Delay jtter tmes (3 rd scenaro) End-to-end delya tme 1 3,,,,3,,1, , 91,7 131,1 1797, Packet release tme (a) Flow 9, 31, 391,, 9 93, Packet release tme (b) Flow ,3, 9,9 31,1 393,3 1, 9, 939,1 Packet release tme (c) Flow 3 Fgure 7. s (3 rd scenaro).

6 mum delay jtter f1 f f3 Flows (th scenaro) Fgure. Delay jtter tmes ( th scenaro) Packet release tme (a) Flow Packet release tme 13 (b) Flow Packet release tme References [1] J. W.S. Lu, Real-Tme Systems, Prentce Hall, [] W. Stallngs, Hgh-Speed Networks and Internets Performance and Qualty of Servce, Prentce Hall, [3] A. Mfdaou, F. Frances, C. Fraboul, Full Duplex Swtched Ethernet for Next Generaton 13B -Based Applcatons, rtas, pp. -, 13th IEEE Real Tme and Embedded Technology and Applcatons Symposum (RTAS'7), 7 [] Hoa Hoang, Magnus Jonsson, Ulrk Hagström, and Anders Kallerdahl, Swtched Real-Tme Ethernet wth Earlest Deadlne Frst Schedulng Protocols and Traffc Handlng, Proceedngs of the Internatonal Parallel and Dstrbuted Processng Symposum (IPDPS ), IEEE Computer Socety [] S.-K. Kweon, K. G. Shn, and G. Workman, "Achevng realtme communcaton over Ethernet wth adaptve traffc smoothng," Proc. th IEEE Real-Tme Technology and Applcatons Symposum (RTAS'), Washngton, D.C., USA, 31 May - June, pp. 9-1 [] ISO/IEC 1-3: 199, ANSI/IEEE Std.1D, 199 Edton. Informaton technology telecommuncatons and nformaton exchange between systems - local and metropoltan area networks - common specfcatons. Part 3: Meda Access Control (MAC) brdges [7] G. Mathason, M. Amrjoo, Real-tme Communcaton Through a Dstrbuted Resource Reservaton Approach, Techncal report HS-IKI-TR--, Unv. of Skovde, [] A. Hangan, R. Marfevc, G. Sebestyen, "Reservaton- Based Data Flow Schedulng n Dstrbuted Control Applcatons," cns, p. 1, Internatonal Conference on Networkng and Servces (ICNS '7), 7 [9] L. Cruvnel, T. Vazao, F. Slva, "Dstrbuted Adaptatons to Traffc Qualty Requrements," cns, p., Internatonal Conference on Networkng and Servces (ICNS '7), 7 [1] P. Whte and J. Crowcroft, The Integrated Servces n the Internet: State of the ART, IEEE Proceedngs, December 1997 [11] S. Blake et al., An archtecture for dfferentated servces, RFC 7, 199 [1] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamn, S., Resource ReSerVaton Protocol (RSVP)--Verson 1 Functonal Specfcaton., RFC, September 1997, Proposed Standard. [13] B. Dave et al., An expedted forwardng PHB, RFC 3, [1] J. Henanen et al., Assured forwardng PHB group, RFC 97, 1999 [1] S. Varadarajan, T. Chueh, EtheReal: A Host- Transparent Real-Tme Fast Ethernet Swtch, ICNP, 199 [1] ***, The Network Smulator - ns-, [17] C. Perkns, RTP Audo and Vdeo for the Internet, Adsson-Wesley, 3 (c) Flow 3 Fgure 9. s ( th scenaro).