Design of the Application-Level Protocol for Synchronized Multimedia Sessions

Transcription

1 Desgn of the Applcaton-Level Protocol for Synchronzed Multmeda Sessons Chun-Chuan Yang Multmeda and Communcatons Laboratory Department of Computer Scence and Informaton Engneerng Natonal Ch Nan Unversty, Tawan, R.O.C. Abstract- An applcaton-level protocol that ntegrates the concept of applcaton level framng and the network-aware applcatons s proposed n ths paper to support the network applcatons wth the synchronzed multmeda sesson. The applcaton model and the applcaton QoS for the protocol are also proposed. The applcaton QoS for each connecton ncludes the maxmum allowable rato of the lost medum unt and the delay bound of the medum unt assocated wth the maxmum allowable rat o. The control mechansms that support the applcaton protocol nclude error control, real-tme control for ndvdual connecton wthn the sesson, and synchronzaton control for the multmeda sesson. Moreover, the applcaton protocol wth the control mechansms provdes a quanttatve expresson for the qualty of the synchronzed sesson n terms of the QoS parameters. Smulaton results show the effectveness of the protocol. I. INTRODUCTION Multmeda network applcatons often requre an end-to-end provson of qualty of servce (QoS) [1]. The requrement results n ntensve and vast research for QoS-red ssues. The QoS-red ssues nclude the desgn of the new programmng APIs for QoS supportng [2], the resource reservaton mechansm [3, 4, 5], the QoS management archtecture [6, 7, 8, 9], and QoS supportng for the wreless envronment [10, 11] etc. Snce the network behavor s dynamc and the statc allocaton strategy (e.g., peak rate assgnment for bandwdth requrement) could not acheve the effcency of the packet swtchng network (.e., the gan of the statstcal multplexng), the adaptve network QoS for multmeda transmssons was suggested. Moreover, the best-effort nature or lack of the resource (bandwdth) reservaton mechansm for some sub-networks on the transmsson path makes t mpractcal to provde the statc end-to-end QoS. However, adaptve QoS mples that once the network stuaton changes, the applcaton wll be notfed that the QoS supported by the network subsystem s changed, and t s the responsblty of the applcaton to adapt tself to the new network condton. In other words, adaptve network QoS also requres the adaptablty of the applcaton [6, 7, 8, 9, 10, 11]. The concept of the mddleware mechansm was proposed to reduce the overhead of ntroducng QoS to the exstng multmeda applcatons such as web servers [8, 9]. For the development of new multmeda network applcatons, the programmer needs to consder the network dynamcs n desgnng adaptve network applcatons [14]. Bandwdth measurement mechansms [15, 16, 17] for provdng the run-tme nformaton about the network condton could be ncluded n the applcaton tself. Such knd of applcatons was called network-aware applcatons [14]. On the other hand, the concept of Applcaton Level Framng (ALF) [12, 13] was proposed to ntegrate the transport protocol functonalty n the applcaton. The ALF concept requres that the applcaton controls the packet sze n the network and s responsble for the control mechansms such as error control and real-tme control. That s, the ALF concept empowers the applcaton wth more controls over network transmssons. Experments have proved that the ALF concept mproves the communcatons systems performance and allows more advanced technques for the effcent mplementaton of communcatons systems. Certanly an ALF applcaton should also be a network-aware applcaton snce the ALF applcaton controllng network-red functons should also adapt to the network envronment. The ntegraton of the concept of ALF and network-awareness s proposed n ths paper to support the network applcatons wth the synchronzed multmeda sesson. The applcaton QoS s defned for each connecton wthn the multmeda sesson, and the applcaton-level protocol wth the correspondng control mechansms, whch nclude error control, real-tme control, and synchronzaton control, s proposed. The remander of the paper s organzed as follows. The applcaton model and the connecton QoS from the applcaton pont of vew are presented n secton II. The format of the proposed applcaton-level protocol s explaned n secton III, and the control mechansms are presented n secton IV. Performance evaluaton for the protocol s presented n secton V. Secton VI concludes the paper. II. APPLICATION MODEL AND QOS There are multple connectons for a network applcaton wth the synchronzed multmeda sesson. Each connecton s responsble for the transmssons of one medum. The archtecture of the proposed applcaton model for both the sender ste and the recever ste of a multmeda sesson s llustrated n Fg. 1. The data producton block n the fgure denotes the source of each medum data n the applcaton program at the sender ste and s responsble for the nput process and the encodng process for one medum. The data unt generated from the data producton block s called the medum unt (), whch could be a vdeo frame or an audo segment, etc. represents the basc data unt for the encoder/decoder of each medum. As mentoned n secton I, the applcaton under the ALF concept controls the transport protocol functonalty such as error control. Snce the sze of s usually too large to be the basc data unt of the control mechansm, we defne the basc data unt for the control mechansm as the applcaton data unt (). Therefore, the applcaton segments the from the data producton block nto several fragments for the connecton of the medum. Each fragment s further encapsud by the applcaton protocol format that s presented n the next secton. Note that when decdng the sze of, we should consder the maxmum packet sze supported by the underlyng network sub-system to elmnate redundant segmentaton/reassembly.

2 Sender Applcaton Medum 1 Producton Producton Segmentaton, Tme stampng Fll n AP protocol header Module: Retransmsson (on-demand) Medum2 (Medum Unt) (AP. Unt) Recever Applcaton Medum 1 Consumpton Consumpton Module: Error control Real-tme control Synchronzaton control Reassembly Medum2 TxRate P MaxP P D : Transmsson rate of the medum data for connecton. : Loss rate that trggers retransmsson mechansm for connecton. : Maxmum rate of medum unt () allowed for connecton. : Maxmum rate of allowed for connecton. : End-to-end delay bound of for connecton. For all connecton n the synchronzed sesson, Fg. 2. Applcaton QoS for synchronzed multmeda sessons ConnectonID Sequence# Tmestamp D = D Length OptonalChecksum Network Subsystem (QoS supported or Best Effort) Connecton 1 Connecton 2 Network Subsystem (QoS supported or Best Effort) Fg. 1. Applcaton structure for the synchronzed multmeda sesson The only control mechansm supported by the applcaton at the sender ste s the on-demand retransmsson for error control, whch means the sender only retransmts as requested by the recever. Snce the sender usually acts as the data server for multple concurrent recevers, the on-demand polcy of retransmsson reduces the overhead of the sender to support ALF. The applcaton model does not mpose any QoS constrant on the underlyng network subsystem, whch means the underlyng network could be ether the QoS supported network or the best-effort network. The dfference between the best-effort network and the QoS supported network s the dfferent actons taken by the applcaton when the applcaton QoS s vod. Once the applcaton QoS s vod, the applcaton enters the re-negotaton state of the connecton for the QoS supported network, but termnates the connecton for the best-effort network. The nterface between the applcaton and the QoS supported networks s not addressed n the paper. On the other hand, the recever ste accepts s from the network subsystem and performs the control mechansms as well as the reassemblng process, whch are explaned n secton IV. As llustrated n Fg. 1, each from the network must pass error control, real-tme control, and synchronzaton control n the recever applcaton. Fnally, the s of all connectons n the sesson are delvered synchronously to the data consumpton module of each medum. Fve parameters are used to specfy the QoS requrement for each connecton wthn the synchronzed sesson. TxRate denotes the transmsson rate of the medum data by the sender for connecton. MaxP denotes the maxmum allowable rato of for connecton. P denotes the rate that trggers the on-demand retransmsson mechansm. Furthermore, the value of P s requred to be smaller than the value of MaxP. D denotes the end-to-end delay bound of for connecton, and P denotes the maxmum allowable rato of s. The wth the end-to-end delay exceedng D s defned as the. The summary of the applcaton QoS parameters for a connecton s shown n Fg. 2. Notce that each connecton n the same sesson should have the same value of the end-to-end delay bound because of the the synchronzaton requrement,.e. for all connecton n the synchronzed sesson, D = D. All of the parameters except TxRate are used for the control mechansms of the proposed applcaton-level protocol. TxRate only serves as the nput parameter n the connecton setup phase # Fragment# NumberOfFragments n the Fg. 3. The applcaton protocol format for underlyng QoS-supported networks to reserve proper resource. More specfcally, ( TxRate, MaxP, D, P ) could be passed to the underlyng network system n the setup phase of each connecton f the underlyng network s QoS-supported. III. PROTOCOL FORMAT As mentoned n secton II each s segmented to several fragments, whch are further encapsud nto s. The header of each s responsble for carryng nformaton for the control mechansms at the recever ste. The format of the s depcted n Fg. 3. The feld of ConnectonID s used for the applcaton to dstngush the connectons n the sesson. The Sequence# feld carres nformaton for reassemblng the orgnal. There are three sub-felds n the Sequence# feld: #, Fragment#, and NumberOfFragments. The feld of # represents the ID of the medum unt that s the source of ths. The feld of Fragment# ndcates the poston of ths n the orgnal. The NumberOfFragments feld ndcates how many s belong to the same. That s, all the s, whch are from the same, wll have the same value of # and NumberOfFragments. The feld of Tmestamp carres the generaton tme of the orgnal. That s, the s from the same have the same value of Tmestamp. The Tmestamp feld s used for the real-tme control mechansm and the synchronzaton control mechansm at the recever ste. As wll be explaned n next secton, the s wth the same Tmestamp from dfferent connectons must be synchronzed n the synchronzaton control mechansm. The Length feld ndcates the length of the followng feld. The feld carres the fragment data segmented from the. Fnally, The OptonalChecksum feld allows the connecton wth tghter error checkng functon. The sender and recever must decde f the OptonalChecksum feld s needed or not n the connecton setup phase. IV. CONTROL MECHANISMS In ths secton, three control mechansms preformed at the recever ste are presented. The executon sequence for the mechansms s, frst the error control, second the real-tme control, and fnally the synchronzaton control. Reassembly of s s executed durng the process of the real-tme control. Two applcaton varables are defned for these mechansms, R and R. R s used to record the run-tme rato of s, and R s used to record

3 If R > MaxP, enter re-negotaton state for connecton, or just termnate t. If R > P, enter re-negotaton state for connecton, or just termnate t. Network subsystem If R > P, ask the sender to retransmt the. Error 1. Check Checksum 2. In-sequence checkng UpdateR Real-tme Error Real-tme Reassemble wthn the tme of (Tmestamp + D) Update R Synchronzaton If the cannot be reassembled wthn the tme, drop all receved s of the. Drop only when checksum error, Pass the out-of-sequenced Fg. 4. The error control mechansm. the run-tme rato of s. The control mechansms uses the two varables to examne whether the applcaton QoS s vod or not and to take the proper acton for the volaton. We explan each of the control mechansms n the followng. 4.1 Error control The objectve of the error control s to detect f there s some lost, whch results from the lost of the, and to compute the new value for R. Therefore, the man functons of the error control nclude checkng the Sequence# feld for the ncomng s, checkng the data ntegrty f the optonal checksum s requred for the connecton, calculatng the new value for R, and fnally trggerng the proper acton accordng the new value of R. The process of the error control s llustrated n Fg. 4. Snce the calculaton of R s based on s, the error control process has to decde f some fragments of the are lost or n error accordng to the ncomng s. There are two knds of errors for the, checksum error of s and of s. The checksum error s detected va the OptonalChecksum feld, and the lost s are detected by the n-sequence checkng. In order to make the n-sequence checkng work correctly for the detecton of lost s, we assume that all the s of the same connecton follow the same path from the sender to the recever, whch s actually the concept of vrtual crcut. The assumpton s reasonable for the multmeda connecton wth long duraton. Therefore, by examnng the Sequence# feld of the ncomng s, the error control process could detect the lost s, and calcu the value of R, whch s the rato of the number of lost s over the total number of s that should be receved. The new value of R s then compared wth the values of MaxP and P. If R > MaxP, whch means the QoS s vod, the connecton should enter the re-negotaton state or be termnated. If P < R < MaxP, t trggers the retransmsson mechansm for the lost. The applcaton ssues a request for retransmsson of the lost, and re-compute R by assumng the retransmtted wll arrve correctly. Note that the error control process does not drop any wth the correct checksum. Thus, the recever merely requests retransmsson of the hole (the mssng ) n the flow of s. No acton s taken by the error control when R < P. The retransmsson strategy for the proposed applcaton protocol s based on the actual rate ( R ) and the Fg. 5. The real-tme control mechansm. desred QoS. It s dfferent from the tme-based error recovery schemes such as those n MSTP [18], LVMR [19], and RVTR [20]. The error control process buffers s for n-sequence checkng and the optonal checksum calculaton, so t only ntroduces a small delay of processng on s, whch s nsgnfcant n comparng wth the end-to-end delay. 4.2 Real-tme control The real-tme control process reassembles the s to the orgnal and checks f the end-to-end delay of the s smaller than the end-to-end delay bound. We defne one as the f the real-tme control process could not fnsh reassemblng the wthn the delay bound. That s, all s (ncludng the retransmsson of the lost ) from the same must arrve to the recever wthn the delay bound. In order to compute the end-to-end delay of s correctly at the recever ste, the sender and the recever must use a common global tme reference, whch can be obtaned from the Global Postonng System (GPS). The recever uses the Tmestamp value of s and the delay bound to decde the local expraton tme (.e. Tmestamp + D) for the reassembly of the as llustrated n Fg. 5. If the real-tme control process could not fnsh the reassembly of one before the expraton tme, all s of the are dropped, and new value of R s calcud. The calculaton of R s to dvde the number of s by the total number of s that should be receved. Smlarly as the error control, f R > P, whch means the QoS s vod, the connecton should be termnated or enter the re-negotaton state. The s that are reassembled wthn the end-to-end delay bound are passed mmedately to the next control mechansm,.e. the synchronzaton control. 4.3 Synchronzaton control The only functon of the synchronzaton control s to synchronze the delvery of all s wth the same Tmestamp. Therefore, the process latches the s wth the same Tmestamp untl the s of all connectons arrve or the local tme (Tmestamp + D) s up. In other words, all s wth the same Tmestamp must be synchronously delvered to the data consumpton module wthn the delay bound (D). The process for the synchronzaton control s llustrated n Fg. 6. Notce that the bufferng tme of one n the real-tme control and the synchronzaton control plus the actual end-to-end delay of the does not exceed the end-to-end delay bound. However, not all s wth the same tmestamp are delvered

4 Real-tme Connecton 1 Connecton Sync. Latch receved s untl all s wth the same tmestamp arrved, or the tme (Tmestamp + D) s up. snce some of them are probably and are dropped n the process of the real-tme control. 4.4 Qualty of the synchronzed sesson The qualty of each connecton could be quantfed n terms of the QoS parameters. We defne the qualty of a connecton, P succ, to be the percentage of successful s that pass all the control mechansms. The followng equaton could be easly derved: Fg. 6. The synchronzaton control mechansm consumpton consumpton Jtters of the delvery tme n a group w/o control (scattered dots) proposed protocol (horzontal at Y=0) Group ID D = 300 ms, Network: N(200, 50 2 ), P net = 2% Fg. 7. Jtters of the synchronous group P = 1 ( R succ + R ) (1) Under the steady state of the connecton, we have MaxP and R < P. Thus, we have succ P = 1 ( R + R < R ) > 1 ( MaxP + P ) (2) We assume that the s of each connecton are of the same mportance. The qualty of the sesson, denoted by Q sesson could be computed as the mean of the connecton qualty,.e., Q sesson= P Sum succ Sum( MaxP + P > 1- # connecton s # connecton s Equaton (2) and Equaton (3) present the relatonshp of the parameters of applcaton QoS and the qualty of the sesson (and ndvdual connecton). Thus, the equatons could be a good reference n determnng the values of QoS. 4.5 Slow-start and slow-stop More fluctuatons of the network stuaton occur n the begnnng of the connecton (sesson). In order to avod a connecton from frequently enterng the re-negotaton state (termnaton and re-connecton) n the begnnng of the connecton, the applcaton should delay the executon of the control mechansms for the begnnng of the connecton. The strategy s called slow-start. The slow-start strategy s reasonable snce the user should be able to tolerate more qualty degradaton n the begnnng of the sesson. On the other hand, after the sesson reaches the steady state, f a sudden congeston happens and the QoS of a connecton s vod. The connecton should delay the re-negotaton (termnaton) process snce the user would tolerate the QoS degradaton resulted from the transent congeston. The strategy s called slow-stop. The tme for postponement of the re-negotaton (termnaton) process depends on the characterstcs of the applcaton and the medum of the connecton. V. PERFORMANCE EVALUATION We conducted some smulatons to nvestgate the performance of the proposed protocol. The network envronment s modeled as an dropper followed by an end-to-end delay generator. The ) (3) Rato of faled group (%) D = 300 D = 400 D = 500 P net = 2% for all cases N(200, 20^2) N(200, 50^2) N(200, 100^2) Fg. 8. Performance for dfferent D and network delays dropper drops s wth probablty P net and the delay generator generates end-to-end delay for each non-dropped accordng to Normal dstrbuton N(µ, s 2 ). The mnmum value of the end-to-end delay s set to 20ms, and the delay of the control packet for trggerng the retransmsson of lost s s also set to 20ms n the smulaton. The traffc generator regularly generates audo s, vdeo s, and HTML s that are then fed nto the network model and the proposed protocol. The generaton rates for audo and vdeo are both 10 /sec, the rate for HTML s 1 /2sec. s wth the same generaton tme, whch form a synchronous group, should be synchronously delvered for playback at the recever. Moreover, one audo generates only one, so does HTML medum. One vdeo generates several s. The traffc generator randomly selects the number of over 3 ~ 7 for each vdeo. The applcaton QoS parameters are set as follows: (1) We assume the underlyng network system merely provdes best-effort transmsson faclty and no negotaton mechansm for network QoS s provded, so we set both MaxP and P to 1 for each medum such that the applcaton cannot termnate the connectons under bad network condton.

5 (2) Settng P to 0 so that the retransmsson of the dropped s always enabled. (3) Several values of D (delay bound) are selected n the smulaton for comparson. The jtters of a synchronous group are defned as the maxmum offset of the delvery tme of s n the same group. Fg. 7 dsplays the jtters for the proposed protocol as well as the contrast case of wthout any control (w/o control). The protocol performs real-tme control and synchronzaton control to shape the arrval pattern to a synchronous pattern. Out-of-real-tme s are dscarded. Thus, the shapng effect of the protocol s n the cost of ncreasng rato of faled synchronous group. One the other hand, f the delay bound D s large enough so that some of retransmssons of lost s could arrve n tme, the performance of the protocol s mproved. Fg. 8 shows performance for dfferent D under dfferent network delay behavors. As shown n the fgure, larger D results n better performance, and smaller varaton of network delay results n better performance as well. Notce that the performance of N(200, 20 2 ) for D=400ms s worse than that of N(200, 50 2 ). The reason s: for N(200, 20 2 ), once an s lost, the chance for the retransmsson to arrve n tme s less than that of N(200, 50 2 ), snce N(200, 20 2 ) usually generates delay close to 200ms and total elapsed tme for the retransmsson arrvng at the recever s always larger than 400ms (delay bound). On the other hand, N(200, 50 2 ) whch has a larger varaton could have more chance to generate delay much less than 200ms and the total elapsed tme sometme s less than the delay bound 400ms. VI. CONCLUSION Combnng the concept of ALF wth the network-awareness, an applcaton-level protocol for the network applcatons wth the synchronzed multmeda sesson was proposed n the paper. The applcaton model and the parameters of the applcaton QoS were also proposed. The control mechansms, ncludng the error control, the real-tme control, and the synchronzaton control, for supportng the applcaton-level protocol and QoS were presented. Moreover, the quanttatve expresson for the qualty of the synchronzed sesson was derved n the paper and could be used n determnng the values of QoS parameters for the sesson. Smulaton results show the effectveness of the protocol. Comparsons for dfferent values of the delay bound under dfferent network condton are also presented n the paper. REFERENCES [1] A. Vogel, B. Kerherve, G. Bochmann, and J. Gecse, Dstrbuted Multmeda and QoS: a survey, IEEE Multmeda, vol. 2, no. 2, pp , summer, [2] P. G. S. Florss, Y. Yemn, and D. Florss, QoSockets: a New Extenson to the Sockets API for End-to-End Applcaton QoS Management, Proceedngs, 6 th IFIP/IEEE Internatonal Symposum on Integrated Network Management, 1999, pp [3] R. Braden, L. Zhang, D. Herzog, and S. Jamn, Resource ReSerVaton Protocol (RSVP)- Verson 1 functonal specfcaton. Internet Draft, Internet Engneerng Task Force, [4] P. Y. Wang, Y. Yemn, D. Florss, J. Znky, and P. Florss, Expermental QoS Performance of Multmeda Applcatons, Proceedngs, IEEE 19 th annual jont conference of the IEEE Computer and Communcatons Socetes, 2000 (INFOCOM 2000), pp [5] I. Foster, C. Kesselman, C. Lee, B. Lndell, K. Nahrstedt, and A. Roy, A Dstrbuted Resource Management Archtecture that Supports Advance Reservatons and Co-Allocaton, Proceedngs, 7 th IEEE Internatonal Workshop on Qualty of Servce (IWQoS 99), 1999, pp [6] A. G. Malamos, E. N. Malamas, T. A. Varvargou, and S. R. Ahuja, On the Defnton, Modelng, and Implementaton of Qualty of Servce (QoS) n Dstrbuted Multmeda Systems, Proceedngs, IEEE Internatonal Symposum on Computers and Communcatons, 1999, pp [7] S. Chatterjee, J. Sydr, B. Sabata, and T. Lawrence, Modelng Applcatons for Adaptve QoS-based Resource Management, Proceedngs, Hgh-Assurance Systems Engneerng Workshop, 1997, pp [8] T. F. Abdelzaher and K. G. Shn, QoS Provsonng wth qcontracts n Web and Multmeda Servers, Proceedngs, 20 th IEEE Real-Tme Systems Symposum, 1999, pp [9] S. Brandt, G. Nutt, T. Berk, and J. Mankovch, A Dynamc Qualty of Servce Mddleware Agent for Medatng Applcaton Resource Usage, Proceedngs, 19 th IEEE Real-Tme Systems Symposum, 1998, pp [10] G. Ln and C. K. Toh, Performance Evaluaton of a Moble QoS Adaptaton Strategy for Wreless ATM Networks, Proceedngs, IEEE Internatonal Conference on Communcatons (ICC 99), 1999, pp [11] A. Kassler and P. Schulthess, Extendng the QoS Paradgm of Wreless ATM to Moble Broadband Applcatons and to the User, Proceedngs, IEEE Wreless Communcatons and Networkng Conference (WCNC), 1999, pp [12] D. Clark and D. Tenenhouse, Archtectural Consderatons for a New Generaton of Protocols, ACM SIGCOMM 90, pp [13] H. Schulzrnne, S. Casner, R.Frederck, and V. Jacobson, RTP: A Transport Protocol for Real-Tme Appl-catons, RFC1889, Nov [14] J. Bollger and Th. Gross, A Framework-based Approach to the Development of Network-Aware Applcatons, IEEE trans. Software Engneerng, vol. 24, no. 5, May 1998, pp [15] J. Bollger and Th. Gross, Bandwdth Modellng for Network-Aware Applcatons, Proceedngs., IEEE INFOCOM 99, 1999, pp [16] K. La and M. Baker, Measurng Bandwdth, Proceedngs, IEEE INFOCOM 99, 1999, pp [17] Vern Paxson, End-to-End Internet Packet Dynamcs, IEEE/ACM trans. Networkng, vol. 7, no. 3, June 1999, pp [18] Chun-Chuan Yang and Jau-Hsung Huang, A Multmeda Synchronzaton Model and ts Implementaton n Transport protocols, IEEE Journal of Selected Area n Communcatons, vol. 14, No. 1, pp , Jan [19] X. L, S. Paul, and M. Ammar, Layered Vdeo Multcast wth Retransmsson (LVMR): Evaluaton of Error Recovery Scheme, Proceedngs, IEEE 7th Internatonal Workshop on Network and Operatng System Support for Dgtal Audo and Vdeo, 1997 (NOSSDAV 97), pp [20] S. Tasaka, T. Nunome, and Y. Ishbash, Lve Meda Synchronzaton Qualty of a Retransmsson-based Error Recovery Scheme, Proceedngs, IEEE ICC 2000, pp