Extending the Functionality of RTP/RTCP Implementation in Network Simulator (NS-2) to support TCP friendly congestion control

Transcription

1 Extendng the Functonalty of RTP/RTCP Implementaton n Network Smulator (NS-2) to support TCP frendly congeston control Chrstos Bouras Research Academc Computer Technology Insttute and Unversty of Patras N. Kazantzak Str., Unversty of Patras, Ron, Greece bouras@ct.gr Apostolos Gkamas Research Academc Computer Technology Insttute and Unversty of Patras N. Kazantzak Str., Unversty of Patras, Ron, Greece gkamas@ct.gr Georgos Koumourtzs Unversty of Patras, Department of Computer Engneerng and Informatcs Unversty of Patras, 26500, Ron, Patras, Greece gkoumou@ced.upatras.gr ABSTRACT In ths paper, we present a modfcaton of the ns2 code for the RTP/RTCP protocols. The legacy RTP/RTCP code n ns2 has not yet valdated but t provdes a framework of the protocol s specfcaton for expermental use. We have modfed the code by addng most of the RTP/RTCP protocol s attrbutes that are defned n RFC We also mplemented addtonal algorthms and functons n order to enhance our modfed code wth TCP frendly bandwdth share behavor. Our protocol, named RTPUP ( UP stands for the Unversty of Patras), s offered as a package and s fully documented so that t can be used for smulatons and research wthn the ns2 smulaton envronment. Keywords Network Smulator (NS-2), RTP/RTCP protocol, Multmeda transmsson, TCP Frendly 1. INTRODUCTION Real tme multmeda applcatons have enjoyed the global nterest over the last few years. These applcatons are characterzed by three man propertes: the demand for hgh data transmsson rate (bandwdth-consumng applcatons), the senstveness to packet delays (latency and jtter) and the tolerance to packet losses (packet-loss tolerant applcatons), when compared to other knd of applcatons. The Transmsson Control Protocol (TCP) s the domnant and the most wdely used protocol at the transport layer. However, there are three characterstcs of ths protocol that makes t nsuffcent for real tme data delvery: TCP has a bult-n retransmsson mechansm that may be n fact useless for delay-senstve applcatons. TCP does not carry any tme related nformaton, whch are needed by real tme applcatons and lastly. Permsson to make dgtal or hard copes of all or part of ths work for personal or classroom use s granted wthout fee provded that copes are not made or dstrbuted for proft or commercal advantage and that copes bear ths notce and the full ctaton on the frst page. To copy otherwse, or republsh, to post on servers or to redstrbute to lsts, requres pror specfc permsson and/or a fee. Conference 04, Month 1 2, 2004, Cty, State, Country. Copyrght 2004 ACM /00/0004 $5.00. TCP employs a strct congeston control mechansm that reacts even n the lght of a sngle packet loss event. Smlarly, the User Datagram Protocol (UDP) does not provde any support for multmeda applcatons. Therefore, the need of a new protocol led the research communty to desgn the Real Tme Protocol (RTP) and the assocated RTP Control Protocol (RTCP) [1] n order to support multmeda applcatons. The RTP protocol consttutes a new de facto standard and s the domnant transport protocol for multmeda data transmsson. The mplementaton of the RTP n NS2 [2] s very generc. It only provdes the man functons of a common transport protocol and runs on the top of the UDP. In ths work we extend the functonalty of the RTP and RTCP code n NS2 to nclude: Most of ts feedback functons descrbed n [1]. TCP frendly behavor wth the meanng that the transmtted flow consumes no more bandwdth than a TCP connecton, whch s traversng the same path wth the transmtted flow. Wth these new feedback functons any multmeda applcaton can employ the nternal mechansms of the RTP and RTCP for Qualty of Servce (QoS) measurements. The TCP frendly bandwdth share mechansm s based on the TCP Frendly Rate Control (TFRC) protocol presented n [3]. Our motvaton s to use the RTP modfed code for smulatng multmeda data transmsson from a server to a number of recevers, through multcastng and by usng dfferent multcast RTP streams. The ns2 code provdes the framework for these smulaton scenaros. However, one has to extend the code to support these scenaros because the RTP code n ns2 cannot support multple RTP streams runnng n one network node. The rest of ths paper s organzed as follows. Next secton brefly descrbes RTP and the RTCP protocols. Secton 3 dscusses the Algorthmc aspects. The extensons made to RTP code n ns2 are presented n secton 4. Secton 5 presents the performance evaluaton of our modfed code. Conclusons and future work are dscussed n secton REAL TIME PROTOCOL (RTP) AND CONTROL RTP (RTCP) In ths secton we brefly dscuss the attrbutes of the Real tme protocol and the assocated Control protocol (RTCP)

2 2.1 Real Tme Protocol (RTP) RTP s a real tme transport protocol that s used usually on top of the UDP protocol (also other transport protocols are supported). By sayng ths we already accept a transport protocol on top of another transport protocol and ths statement may be msleadng. On the other hand, RTP s hghly coupled to the applcaton that t carres. Therefore, RTP would better be vewed as a framework for real tme applcatons and not as just a transport protocol. RTP nether provdes any guarantees for data delvery nor for sequencng packet delvery. The man functons of the RTP nclude: Identfcaton of payload type Identfcaton of the source sendng the RTP packets Tmestamps to the RTP packets Sequence numbers of the RTP packets 2.2 RTP Control Protocol (RTCP) The RTCP protocol provdes to partcpants of the RTP sesson feedback nformaton of the network condtons. RTP and RTCP protocols use dfferent port numbers. The man functons of the RTCP are: Network measurements for QoS (packet loss rato, delay jtter, tmestamps of sender and recever reports etc) Identfcaton of the source sendng the RTCP packets Estmaton of the sesson sze and scalng mechansms The RTCP sender and recever reports (SR) and (RR) provde drect nformaton on the packet losses, cumulatve number of the RTP packets sent by the source and delay jtter. They provde also addtonal felds that can be used for the mplementaton of congeston control polces by separate protocols, lke for example TCP-lke flow control, whch we have mplemented. A separate entty lke a network management can obtan network metrcs based on the recepton of the RTCP reports wthout actually takng part n the RTP sesson. Other nformaton carred by the RTCP packets nclude a source dentfer of the transport layer (CNAME), the e-mal address, name, phone, locaton of the source orgnated the RTCP report. 3. ALGORITHMIC ASPECTS In ths secton we descrbe the algorthm to estmate a TCP frendly bandwdth share. We then explan how we estmate the packet loss rato and the Round trp Tme (RTT) that are used for the TCP frendly bandwdth calculatons. Fnally, we present the nter-arrval jtter delay estmatons, whch are based on the RFC 3550 recommendatons. 3.1 TCP Frendly Bandwdth Share Estmatons The subject of transmsson of TCP frendly flows over networks has engaged researchers all over the world, [4], [5] and [6]. Varous adaptaton schemes deploy an analytcal model of TCP [4] n order to estmate a TCP frendly bandwdth share. Wth the use of ths model, the average bandwdth share ( ) of a r TCP connecton s determned (n bytes/sec) wth the followng equaton: r where = t e RTT r l 3 frendly bandwdth share, P 3l ) l (1 + 32l 8 2 e 2 + 4t RTT mn( 1,3 t RTT ) (1) s the recever s estmaton of the TCP P s the packet sze n bytes, l s the packet loss rate, s the Round Trp Tme (RTT) of the TCP connecton. If the recever does not experence packet losses, n order to estmate a TCP frendly bandwdth share r, the r must not be ncreased more than a packet / RTT. For ths reason the recever calculates the value of r wth the followng equaton (n bytes/sec): r = r 1 + e t P (2) RTT Each tme the recever sends a recever report to the sender t ncludes the average value of r snce last recever report. 3.2 Packet Loss Rate Estmaton Every recever that jons the RTP sesson can measure the packet loss rate based on RTP packets sequence numbers. In order to prevent a sngle spurous packet loss havng an excessve effect on the packet loss estmaton, the recevers smooth the values of packet loss rate usng the flter presented n [7], whch computes the weghted average of the m most recent loss rate values. The authors of [7] have also evaluated ths flter and the results are very postve. 3.3 RTT Estmatons When a recever receves a RTP packet from a sender, t uses the followng algorthm to estmate the RTT between the sender and the recever: f no feedback has been receved before RTT = sqrt(effectve_rtt) else RTT = q * RTT + (1-q) * effectve_rtt (3) where, q has a default value of 0.9 Ths calculaton s based on the sender estmaton of the RTT tme (effectve_rtt) and s measured by usng the tmestamps of the RTCP sender and recever reports. The algorthm above s descrbed n [1] wth the dfference that n the TRFC specfcatons the RTT estmatons are made by the sender. In our mplementaton we have the recevers estmatng the RTT tme. 3.4 Inter-arrval Jtter Estmatons Our mplementaton for delay jtter calculatons s based on the algorthm defned n RFC Shortly explanng, let S s the

3 RTP tmestamp from packet, and R s the tme of arrval n RTP tmestamp unts for packet, then for two sequentally packets and j, D may be expressed as: D = ( R R j ) ( S S ) j (4) Ths delay varaton should be calculated for each RTP packet. RFC 3550 suggests a flter functon to avod temporal fluctuaton and the delay jtter s computed wth the use of the followng equaton: J = (15 /16) J 1 + (1/16) D (5) All the above-descrbed algorthms are mplemented n our RTP modfed code. 4. EXTENSIONS TO RTP CODE In ths secton we descrbe the extensons made to RTP code n ns2. Our work manly s dvded nto two man areas: Provdng the RTP code the addtonal functonalty defned n RFC Employng TCP frendly bandwdth share mechansms for expermental use. The extensons made n the ns verson on a Lnux platform runnng Fedora 6 operatng system. 4.1 Software Archtecture We present the structure of the RTPUP code wth the UML dagram n fgure 1. Frst of all we have renamed the RTP packet header form hdr_rtp to hdr_rtpup ( up stands for Unversty of Patras) to dstngush our code from the legacy code n ns2 n order to avod confuson wthn the ns2 users communty. We also defned new data structures named server_report and recever_report to store the felds of the RTCP SR and RR respectvely. A new class named RTPUPRecever was declared to hold the felds that are used by the recevng Agents for QoS measurements. Every new nstance of the RTPUPSesson class creates two nstances of the RTPUPSource and one nstance of the RTPUPRecever classes, accordngly. The RTPUPSessonClass s called va the TCL scrpt and n turn two new Agents (RTPUPAgent and RTCPUPAgent) are assgned to every node n the network that partcpates n the multcast stream. The RTPUPAgent holds all the functonalty for sendng and recevng RTPUP packets whereas the RTCPUPAgent s responsble for the transmsson and recepton of the RTCPUP sender and recever reports. We have mplemented a one-to-many scheme of the RTP/RTCP protocol n whch one sender transmts a multcast stream to a set of recevers. It s however, easy and qute straghtforward to extend the code so that a node can be a recever and at the same tme an actve sender. Ths apples to VoIP applcatons n whch, the sender s also a recever durng the VoIP sesson. Fnally, new functons are also used for the mplementaton of the algorthms descrbed n the prevous secton. We wll explan n more detals the functonalty of the RTPUP code n the followng paragraphs wth the followng TCL usage example: set s0 [new Sesson/RTPUP] $ns at 0.1 "$s0 jon-group $group" $ns at 1.0 "$s0 transmt 256kb/s" $s0 enable-control 1 Fgure 1. UML dagram of the RTPUP code When a new sesson s created from the TCL programmng language scrpt n our smulaton envronment, a new nstance of the RTPUPSesson class s returned. The constactor of the RTPUPSesson class ntalzes the localsrc_ and allsrcs_ nstances of the RTPUPSource class and also the recevers_, whch s an nstance of the RTPUPRecever class. The localsrc_ stands for the orgnator of the RTPUP and RTCPUP packets. It s possble that the localsrc_ generates only RTCP packets f t s only a recevng source n the newly created sesson. Next lne of the TCL command calls the above-descrbed functons: set s0 [new Sesson/RTPUP] The RTCP packets are orgnated by all the partcpants n the sesson. The creaton of the RTP and RTCP packets s done by the RTPUPAgent and RTCPUPAgent classes respectvely. The nstances of these classes are created n the ntalzaton of the RTPUPSesson TCL class. The two Agents are not actve untl the new sesson s0 jons a multcast group. We can manually declare the nstances of the RTPUPAgent and RTCPUPAgent classes but we recommend the use of the RTPUP code for multcast transmsson. Next lne calls sesson s0 to jon the multcast group at 0.1 second: $ns at 0.1 "$s0 jon-group $group" where group s the multcast address. Untl now there s no transmsson of any RTPUP or RTCPUP packets because sesson

4 s0 was smply declared and joned a new multcast group. We need to call the start functon for sesson s0 to start transmttng RTCP packets at 0.1 second: $ns at 0.1 "$s0 start" we added to provde QoS measurements and necessary nformaton for the congeston control mechansm. New nlne functons provde the accessblty to these felds. In the next subsectons we wll dscuss and explan how the data collecton and processng s done and how the TFRC congeston control s mplemented. 4.2 Modfed and New Functons In our RTPUP code we dstngush three major functons/modules. Fgure 2. Class dependency of RTPUP and RTCPUP packet types The most mportant feld of the RTCP packets n ths ntal phase s the srcd_, whch s the sesson unque dentfcaton. Ths feld s an unsgned nteger that s unque amongst all partcpants n the multcast group. However, the transmsson of real RTP data packets cannot start untl the transmt functon s called: $ns at 1.0 "$s0 transmt 256kb/s" The above functon provdes the green lght to the RTPUPAgent and the transmsson of RTPUP packets starts at the rate that we have decded n the prevous command. In our mplementaton we defned a new functon n the Sesson/RTPUP TCL class to enable the TFRC frendly congeston control. We dd so n a manner that the user can choose from hs TCL scrpt to enable or not ths congeston control. Therefore, to enable the congeston control the user should execute the next command n the TCL scrpt: $s0 enable-control 1 The default value s zero, whch means that the congeston control s dsabled by default. Followng, fgure 2 shows the class dependency for the creaton of the RTPUP and RTCPUP (SR and RR) packets. We can see n the UML dagram the new felds that Send and Receve RTPUP Packets RTPUP packets are generated based on a tmeout event of the RTPUPTmer. The RTPUP Agent creates a new RTPUP packet by callng the send functon: vod RTPUPAgent::sendpkt(){ The send functon nvokes the make packet functon, whch creates the new RTPUP packet and adds the followng felds n the packet header: vod RTPUPAgent::makepkt(Packet* p){ the sequence number of the RTP packet. rh->seqno() = seqno_++; the source d of the sendng source rh->srcd() = sesson_->srcd(); the tmestamp rh->tmestamp()= tmestamp_; the recevers that ths sender serves wth the recever source d feld and the effectve RTT rh->recevers_= sesson_->recevers_; n whch the effectve RTT s defned as by: eff _ rtt = A tlsr tdlsr (6) where, t L SR s the tme when the recever receved the last SR, t D LSR s the tme elapsed between the recepton of the SR last report and the generaton of a new RR report and A stands for the current tme of the recepton of the RR. We wll see later how the calculaton of the effectve RTT s done by the sender. When the recever receves the RTPUP packet t calls frst a lookup functon to check f the orgnator of the packet s a known source. If not, a new source s added by callng the new-source functon of the Sesson/RTPUP TCL class. The processng of ths newly recevng packet follows. We added a condtonal statement to make sure that the recevng source s not dentcal wth the sendng source: f(rh->srcd()!=localsrc_->srcd()) In the ns2 legacy source code the sendng source s the frst source that receves the packet, whch t has just sent. In the lack of any documentaton for the ns2 legacy code we regarded t as a flow that would affect our measurements. When the condton s met, the recevng source extracts the effectve RTT that the

5 sender has assgned for ths recever by executng the next code segment: for (RTPUPRecever* p = rh->recevers_; p!= 0; p = p->next) { f(p->srcd() == localsrc_->srcd()) { eff_rtt = p->eff_rtt(); f(eff_rtt!= 0 ) { calculate_rtt(eff_rtt); (7) The above lnes are straghtforward. If the sender and the recever have not exchanged yet any SR or RR reports we assume symmetrc lnks to avod dvson by zero values. Thus, we set the RTT to double the value of the one-way trp. When the recever gets non-zero effectve RTT values, (whch happens wthn the frst seconds after the sesson establshment), t calls functon (7) to calculate the estmated RTT tme. Next the recever calculates the delay jtter. We use the code presented n RFC 3550 Appendx A.8. double transt=arrval -rh->tmestamp(); double d = transt - s->transt(); s->transt(transt); f (d < 0) d = -d; s->jtter( s->jtter() + (1./16.) * (d - s->jtter())); where transt s the transt tme of the receved RTPUP packet, d s the dfference n tme unts between two consequent RTPUP packets and s->jtter() holds the prevous jtter delay measurement. Fgure 3. State chart of the send and receve functons Fnally, the recever of the RTPUP packet assgns the followng felds to RTPUPSource s: //count receved RTPUP packets s->np(1); // count lost RTPUP packets s->cum_pkts_lost(pkts_lost); //get the extended hghest number s->ehsr(rh->seqno()); // count the number of receved bytes s->nbytes(mh->sze()); // the packet sze n bytes s->ps(mh->sze()); Each RTPUPSesson nstance keeps n the allsrcs_ feld only the actve sources n the sesson. Therefore, the recevng source s able to look up ths feld n order to locate the sendng source dentfcaton number. To do so the recevng source nvokes the lookup functon that returns the RTPUPSource object s, whch s the sendng source. We can use the nstance s to hold all the above values that we wsh and add any other felds that we can use at a later tme. Fgure 3 depcts the state chart of the abovedescrbed functons Buld RTCPUP Sender and Recever Report Functon The buld functon s called by the RTCPUPAgent as a result of an RTCPUPTmer tme-out event. The sender generates a new SR f t has sent RTPUP packets snce the prevous SR. When ths condton s met the sender sets the we_sent flag to 1 and generates a sender report (SR). Next lnes present the declaraton and constructon of the SR: //add sender report sender_report* sr; //fll n the report sr = new sender_report; //assgn the sender s d sr->sender_srcd()= localsrc_->srcd(); //assgn the RTPUP packets sent sr->pkts_sent() = localsrc_->np(); //assgn the total bytes sent sr->octets_sent() = localsrc_->nbytes(); //nclude the recevers served sr->rcvr_ = recevers_; //store the report rh_->sr_ = sr; The sender ncludes the total number of RTPUP packets and the total number of bytes t has sent snce the begnnng of the sesson. It also ncludes the recevers that ths source serves. We wll explan n the next subsecton how ths nstance of the RTPUPRecever class s used by the recevng sources. Alternately, each recever before buldng the RR t has to calculate the TCP frendly bandwdth share. To do so, the recever calculates the fracton of packets lost snce the prevous RR. We derve the algorthm for calculatng the loss fracton from RFC 3550 specfcatons. The loss fracton s defned as the fracton of the RTPUP packets lost over the number of RTPUP packets expected n the tme nterval between two successve RRs and has values between (0.0, 1.0). Next code segment calculates the loss fracton: //calculate loss fracton snce prevous report nt expected_nterval = sp->ehsr() - last_ehsr_; last_ehsr_ = sp->ehsr(); nt lost_nterval = expected_nterval - receved; f (lost_nterval <= 0 expected_nterval == 0 ) { fracton = 0;

6 else fracton = ((double)lost_nterval / (double)expected_nterval); Sender Report the sender reports the total number of RTP packets and bytes sent rtcp tmeout Buld report we_sent = 1 Recever Report calculate DLSR ncrease rate DLSR = now - SRT measure fracton loss fracton_loss = 0 measure smooth loss calculate new rate Fgure 4. State chart of the buld report functon // Update the R_tcp accordng to fracton value f( sp->np() >= 1) {// I have already receved RTPUP packets from the source f(fracton == 0) { ncrease_rate(sp->ps()); (7) else { measure_smooth_loss(fracton); calculater_tcp(sp->ps()); If the fracton loss s zero the recever estmates a new transmsson rate by executng (7) as shown below: tx_rate_+=(double)ps/rtt_; where, ps s the packet sze of the RTPUP packet, RTT_ s the estmated round trp tme by the recever and tx_rate_ s the prevous estmated TCP frendly transmsson rate. However, zero fracton loss s not always the case and the recever calculates a smooth loss value by nvokng the measure_smooth_loss(fracton) functon: double smooth_values = 0; for (nt =0; <7; ++) { pkt_loss_hstory[+1]= pkt_loss_hstory[]; pkt_loss_hstory[0] = fracton; double temp =0; for(nt =0; <8; ++) { temp += weght[]; for (nt =0; <8; ++) { smooth_values += weght[] * pkt_loss_hstory[]; smooth_loss_= smooth_values / temp; The recever has now the smooth loss rato whch s a consoldated value based on the prevous seven measurements. The pkt_loss_hstory array holds these prevous measurements. The weght array holds statc values. The nterestng reader can reference [8] for more detals on these values. Next step for the recever s to estmate the TCP frendly transmsson rate by callng the followng functon that s the mplementaton of the TCP analytcal model (1): calculater_tcp(sp->ps()); where ps() s an nlne functon that returns the sze of the RTPUP packet. The recever needs to know the packet sze to perform the TCP calculaton. We have seen prevously when descrbng the receve RTPUP functon how we obtaned the RTPUP packet sze and how we assgned ths packet sze to the sendng source. We declared ths feld n the RTPUPSource class as dfferent sources may use dfferent packet sze and wanted to have ths drect accessblty. After the computaton of the varous felds the recever constructs the RR n the followng lnes: //add recever report recever_report* rr; rr = new recever_report; //fll the report // cumulatve packets lost

7 rr->cum_pkts_lost()=sp->cum_pkts_lost(); // add TCP frendly rate rr->r_tcp() = tx_rate_; // last tme sender report rr->lsr() = sp->lsr(); // delay snce recevng the SR rr->dlsr()= now - sp->srt(); //add jtter delay rr->jtter() = sp->jtter(); //add RR to the RTCPUP packet rh_->rr_ = rr; Receve Control RTCPUP Packet Functon We have seen so far how the recevers access the RTPUP packets and how both sender and recevers buld the SR and RR reports. We have also explaned how the recevers perform the varous calculatons n order to provde the sender wth QoS measurements. In ths subsecton we wll descrbe what the actons are from the sender sde, to adjust ts transmsson rate. Therefore, the receve control functon s the mergng functon n whch the results of the program are presented and actons take place. Upon the recepton of a new RTCPUP report sender and recevers performs dfferent functons. The sender frstly evaluates f the orgnator of ths RR does exst n ts recever s lst. At ths pont t has to be mentoned that n the legacy ns2 code the allsrcs_ feld for the sendng source n empty as long as t does not receved any RTPUP packets from any source. That was the reason that led us to defne the RTUPRecever class, so that the sendng source could be able to keep a lst of all the recevers n the sesson t serves. Therefore, f the condton s not met (the orgnator of the RR has not heard yet by the sender) the sender adds the orgnator to hs recevers lst. We use a smlar functon to the ns2 legacy code for constructng the recever s lst: enter_rcv(rtpuprecever* s) The sender processes the RR and calculates the effectve RTT tme as follows: eff_rtt = alpha - rh->rr_->lsr() rh->rr_->dlsr(); where alpha s the current clock tme The TCP recever s estmaton s kept n a separate data structure. We use for t an nstance of the class lst n whch ts sze s dynamcally updated wth the number of ts elements so that we can hold a far large amount of recevers. In addton, the class lst offers a number of bult-n functons that are very convenent for accessng and sortng ts elements. Every tme the sender receves a new report from the RTCPUP Agents n the multcast sesson t adjusts ts transmsson rate. The sender takes nto account the mnmum bandwdth estmatons from the recever set accordng to the algorthm below: new _ rate = mn( r,..., r ) (8) r tcp 1 r_ tcp r_ tcp where, _ s the bandwdth estmaton of recever. At ths pont and n order to prevent oscllatons we use a nofeedbacktmer to check whether or not the sender has receved feedback reports from all the recevers wthn a feedback nterval. Ths feedback nterval s defned as: feedback_nterval = 2 * ps/tx_rate_ where ps s the packet sze of the RTP packet and tx_rate_ s the current transmsson rate. When the sender does not receve an expected RTCPUP report from a recever wthn the feedback nterval t cuts ts sendng rate to half. Ths s a congeston avodance mechansm because a lost RTCPUP recever report ndcates a congested path. It has been notced n our expermental smulatons that ths mechansm ncreases the overall performance of the protocol. Next the sender updates ts transmsson rate by callng the transmt functon n the Sesson/RTPUP TCL class. In the recever sde when t receves an RTCPUP SR t stamps the SRT feld wth the current clock tme. The SRT stands for the Sender Report Tme and ths tme wll be used for the calculaton of the DLSR : source->lsr(rh->tmestamp()); source->srt(now); Wth the above descrbed procedures and functons we conclude the man modules of our modfcaton to the ns2 RTP legacy code. Fgure 5 shows the state chart of the receve control functon r Fgure 5. State chart of the receve control functon

8 5. PERFORMANCE EVALUATION We evaluate our model wth smulatons performed wth the ns2 smulaton software. Our man objectve s frst to verfy that the RTPUP works properly and second that t has ndeed frendly TCP behavor. 5.1 Smulaton Envronment and Network Topology Setup Our benchmark for the evaluaton of the RTPUP protocol s a Local Area Network (LAN), whch conssts of one multmeda server and sx heterogeneous recevers. The heterogenety of the recevers lays n the varaton of the lnk capacty, whch connects the recevers wth the LAN. We have ntentonally created a bottleneck between routers 2 and 3 to create two dfferent sets of wred recevers. The frst set of recevers (Nodes 1, 2, 3 fast recevers ) are able to receve a hgher bt rates than the second set (Nodes 4, 5, 6 slow recevers ). We run a smple smulaton scenaro n whch the multmeda server transmts RTPUP traffc at an ntal rate of 256Kb/s. The RTCP transmsson nterval s set to 500 msec. At the same tme a Fle Transfer Protocol applcaton (FTP) s transmttng TCP packets through the same ppe wth the RTPUP traffc from Node 7 (TCP Agent) to Node 8 (TCP Snk). We run two dfferent smulaton sets to nvestgate: The behavor of our proposed protocol towards the TCP traffc The behavor of the TFRC mplementaton n ns2 towards the same TCP traffc Pros and cons between our mplementaton and the TFRC code n ns2. Fgure 6 depcts the network topology for the smulated scenaros. begnnng of the smulaton. We run our smulaton for 200 seconds. In the chart presentng the smulaton results (Fgure 7) we can see the recevng rates from two representng nodes of the two dfferent groups (Node 1, fast recever and Node 4, slow recever ) and also the TCP recevng rate named as TCP Snk. We extract the followng conclusons of the smulaton results: The RTPUP protocol presents the characterstcs of the TCP congeston control mechansm, n whch the protocol ncreases ts sendng rate as long as the end-to-end path s congeston-free. Ths s a drect result of the TCP frendly algorthm that has been mplemented n our code. The RTPUP protocol has also the characterstcs of a multplcatve-decrease protocol, smlar to that of the TCP protocol. Ths s also the drect result of the mplementaton of the TCP analytcal model n our code. However we have not mplemented all the characterstcs of the TCP protocol as out ntenton s to enrch the RTPUP wth TCP frendly behavor and not to replcate the legacy TCP code. Another mportant concluson s that our modfed RTPUP protocol does have TCP frendly behavor. The TCP traffc s beng delvered from the source to the destnaton node although the path s heavly congested by the RTPUP traffc. RTPUP presents the same oscllatons wth the TCP protocol due to the mplementaton of the congeston control mechansm. We observe that when the TCP transmsson rate ncreases the RTUP transmsson rate decreases and vce versa. One last mportant observaton s that RTPUP has smlar delvery rato to both slow and fast recevers. Ths s a wshed attrbute of the protocol as t ensures a far delvery rato, whch most of tmes s above 100 Kb/s to the whole set of recevers. We wll see n the next smulaton run whether or not the TFRC mplementaton n ns2 s able to keep an equal delvery rato to the whole set of recevers. Node 4 Node 1 TCP Snk Fgure 6. Smulated network topology 5.2 Frst Smulaton: Transmsson of RTPUP Multcast Stream wth Background TCP Traffc We ntally set the bandwdth capacty of the RTPUP traffc to 256Kb/s and the RTCPUP reportng nterval to 500 msec. However, these two parameters do not reman unchangeable and adopt ther values accordng to network condtons. As for the TCP protocol we use the smple TCP verson n ns2. recevng rate (Kb/s) smulaton tme (sec) Fgure 7. RTPUP versus TCP traffc The transmsson of both RTPUP and TCP traffc start n the

9 5.3 Delay Jtter Measurement The delay jtter measurement s straghtforward and s beng done wth a procedure that s defned n the TCL Sesson/RTPUP class. The results below (Fgure 8) present the measurements of the slow recever (Node 4) n contrast to the delay jtter of the fast recever (Node 1). These results were measured durng the prevous smulaton and are presented n the same chart, although the delay jtter values are n dfferent scales. We present the results from Node 4 on the left Y axs and the results from Node 1 on the rght Y axs. All the results are represented n seconds. We extract the followng observatons: Fast recevers enjoy mnmum values of delay jtter; the hghest observed delay jtter value throughout the smulaton tme s 2 msecs. We regard ths as a good performance metrc for the RTPUP protocol as the smulaton scenaro was set up n such way to challenge the protocol performance. Slow recevers present delay jtter values between 100 and 150 msecs and n general one-way jtter up to 150 msecs s consdered to be acceptable even for VoIP applcatons. jtter delay (sec) Node 4 Node 1 Fgure 8. Delay jtter measurements Packet Loss Rate Measurement For the packet loss rate measurement we have also defned a new procedure n the TCL Sesson/RTPUP class. In ths way we can get drectly ths rate from our smulaton scrpt. We measure the loss rate as the rato of packets lost over the packets receved durng the sample nterval (9). Ths sample nterval s the tme elapsed between two consequent Recever Reports, (RR). ploss _ rate = plost / prcv *100 (9) We can observe from the smulaton results (fgure 9) that lost events occur manly when the network s heavly congested and ths happens only for a very short perod. We present only the packet loss rato from a slow recever (Node 4) as we have not observed any packet losses from the fast recevers. Ths s a wshed attrbute of our RTPUP mplementaton as we have a multcast protocol that s able to transmt at hgh bt rates n a congested network, wth low delay jtter and mnmal packet losses. In the next smulaton run we wll see how our mplementaton outperforms the TFRC mplementaton n ns2. packet loss rato (%) Node smulaton tme (sec) Fgure 9. Loss rate measurements 5.5 Second Smulaton: Comparson wth the TFRC Implementaton n ns2 In the last smulaton we compare the TFRC mplementaton n ns2 to our RTP/RTCP mplementaton wth the TCP frendly enhancements. The TFRC code n ns2 has been used for smulaton throughout a number of researchers and provdes an acceptable mplementaton of the TFRC specfcatons. The smulaton scenaro has exact the same network attrbutes as our prevous smulatons to acheve a far comparson. In ths case, RTP traffc s transmtted to the same set of recevers and the congeston control s left to TFRC protocol. We transmt also the same TCP traffc across the network from Node 7 to Node 8. Fgure 10 depcts the smulaton results. recevng rate (Kb ,7 38,4 56,1 Node 4 Node 1 TCP Snk 73,8 91, smulaton tme (sec) Fgure 10. TFRC n ns2 versus TCP traffc We observe from the above results that the ns2 TFRC mplementaton has smoother oscllatons than our mplementaton, whch s a desred attrbute especally for vdeo transmsson. The TCP frendly behavor s also stable except for some cases, n whch TCP traffc s reduced to zero. In our mplementaton the TCP traffc has always equal or hgher values when compared to the ntal transmsson rate.

10 A second observaton s that although Node 1 ( fast recever ) enjoys hgh recevng rates, Node 4 ( slow recever ) has very low recevng rates. However, t has to be mentoned that the TFRC code n ns2 s used for uncast transmsson. Thus, the sender transmts dfferent uncast streams to each one of the recevers and adjusts ts transmsson rate accordngly. Our fnal concluson s that our RTP/RTCP mplementaton ntroduces very good characterstcs when we have multcast vdeo stream that s transmtted va a congested path. The code and the mplementaton complexty of our mplementaton are very low when compared to the TFRC module n ns2. [8] C. Bouras, A. Gkamas, G. Koumourtzs, "A Framework for Cross Layer Adaptaton for Multmeda Transmsson over Wred and Wreless Networks, The 2007 Internatonal Conference on Internet Computng (ICOMP 07), Las Vegas, Nevada, USA, June CONCLUSIONS/FUTURE WORK We present n ths work an extenson of the RTP code n ns2. Our motvaton was to enrch the functonalty of the exstng code by ncludng most of the RTP/RTCP protocol s specfcaton n RFC We also extended our code to enhance t wth TFRC mechansms for research and expermental use. Our effort was to keep the functons and the data felds of the orgnal ns2 code, to modfy exstng functons and to defne only the necessary functons for the mplementaton of the new algorthms. We tred also to keep the code style of the ns2, document our code and offer t as a package for easer ntegraton nto ns2 lbrares. There were several smulaton runs and tests along wth those that are presented n ths work n order to verfy that we get the correct QoS measurements. Smulaton results show that the RTPUP performance has certan advantages for multcast transmsson of delay senstve data, such as VoIP and vdeo streamng. In our future work we wll extend the RTUP code to support smultaneous RTPUP multcast streams n one node for expermental and smulaton use. 7. REFERENCES [1] H. Schulzrnne, S. Casner, R. Frederck, V. Jacobson, A Transport Protocol for Real-Tme Applcatons RFC 3550, July 2003 [2] [3] Handley, M.; Floyd, S.; Padhye, J.; Wdmer, J. TCP Frendly Rate Control (TFRC): Protocol Specfcaton Request for Comments (RFC) 3448, The Internet Socety, January 2003 [4] J. Pandhye, J. Kurose, D. Towsley, R. Koodl, "A model based TCP-frendly rate control protocol", Proc. Internatonal Workshop on Network and Operatng System Support for Dgtal Audo and Vdeo (NOSSDAV), Baskng Rdge, NJ, June [5] D. Ssalem, A. Wolsz, "MLDA: A TCP-frendly congeston control framework for heterogeneous multcast envronments", n Eghth Internatonal Workshop on Qualty of Servce (IWQoS 2000), Pttsburgh, PA, June [6] L. Vcsano, L. Rzzo, J. Crowcroft, "TCP - lke congeston control for layered multcast data transfer", n IEEE INFOCOM, March 1998, pp [7] L. Vcsano, L. Rzzo, J. Crowcroft, "TCP - lke congeston control for layered multcast data transfer", n IEEE INFOCOM, March 1998, pp