Optimum Number of RLC Retransmissions for Best TCP Performance in UTRAN

Transcription

1 Optmum Number of RLC Retransmssons for Best TCP Performance n UTRAN Olver De Mey, Laurent Schumacher, Xaver Dubos {ode,lsc,xdubos}@nfo.fundp.ac.be Computer Scence Insttute, The Unversty of Namur (FUNDP) Rue Grandgagnage 1, B-5 Namur, Belgum Abstract As far as transfer relablty s concerned, the wreless segment of UTRAN s the weakest part of an Internet sesson. To overcome ths mperfecton, the RLC protocol features a lnk-level retransmsson mechansm. In ths paper, we show by analytcal means and computer smulatons that for a gven Block Error Rate (BLER), the maxmum number of RLC transmssons has a very mportant mpact on TCP performance, both Round Trp Tme (RTT) and throughput. We extend the lnk level Automatc Repeat Request model proposed by Pesa et al. (1) to be able to set a maxmum number of RLC transmssons, and wth the help of Padhye s TCP throughput model (), we determne the correspondng throughput analytcally. We also show that, knowng the current BLER, a network operator may tune the maxmum number of retransmssons ether to reduce the RTT or to ncrease the throughput. I. Introducton RLC recovery s a local retransmsson mechansm desgned to partally overcome the mperfecton of the wreless segment n the UTRAN 1]. It s based on the bufferng of the Protocol Data Unts (PDU) at the transmt end of the wreless lnk, coupled wth a local retransmsson mechansm between the User Equpment (UE) and the Rado Network Controller (RNC). Usng the RLC Acknowledged Mode (AM), ths mechansm lets the RNC know whether a RLC PDU has been receved correctly or not. In case of loss or erroneous transmsson of a PDU, the RNC has the ablty to retransmt t locally, makng TCP unaware of the loss from an end-to-end perspectve. The parameters of the RLC (buffer sze, number of retransmssons) are of uttermost mportance to acheve good performance. Usually, these are operator-specfc. In ], the mpact of the buffer sze has been nvestgated. It has been shown that a small RLC buffer sze has negatve effects on the TCP throughput, though the smulaton parameters supposed an unlmted number of RLC retransmssons. The purpose of the current paper s to address the settng of the number of local retransmssons. Indeed, a lmted number of retransmssons s lkely to lead to a TCP packet loss at the recever s sde due to the unablty to recover from the PDU loss. As a result, the TCP sender would reduce ts congeston wndow, and the transmsson throughput would decrease, despte the loss could possbly have been recovered wth a sngle addtonal PDU retransmsson. On the other hand, too many retransmssons would lead to a TCP tmeout, and therefore the retransmsson of PDUs from a duplcated TCP packet. Hence, determnng the optmum number of local retransmssons from the crcumstances, e.g. channel qualty as measured by the, s a meanngful task. In ths paper, we wll show to whch extend the maxmum number of RLC retransmssons s determnng the TCP performance n terms of RTT and throughput. The study wll be performed by means of analytcal developments, valdated by computer smulatons. II. Descrpton of the nvestgated scenaro We are consderng the scenaro llustrated on Fg. 1: one user s downloadng a fle usng FTP from hs/her UE, where the wreless lnk s affected by errors measured by the RLC PDU Block Error Rate (BLER). Errors on the wreless lnk are assumed to be uncorrelated. On the other hand, the rest of the connecton, from the server down to the RNC, s regarded as error-free. Fg. 1. Scenaro We assume that every TCP segment s splt nto N RLC PDUs, TCP Segment sze N =, (1) RLC PDU sze wth x standng for the smallest nteger greater than or equal to x. Moreover, as n 3], t s further assumed that

2 a smple TCP segment completely flls n the transmtter buffer wth ts N RLC PDUs. The RLC protocol s fully descrbed n 1]. Our focus here s on ts AM mode. If a RLC PDU has been ether lost or corrupted between the Node B and the UE, the recever sgnals the ncdent through a status report. In the absence of such a feedback, the transmtter can poll the recever at the expry of a pollng tmer. The RLC can retransmt a mssng PDU ( 1) tmes, where s the total number of transmssons of a RLC PDU: the frst transmsson tself, and the maxmum number of retransmssons. In case the PDU has not been acknowledged by the UE to the RNC after transmssons, the whole TCP packet s then dropped. Already acknowledged PDUs are dropped as well, and a TCP retransmsson s trggered. In the followng sectons, we wll nvestgate the nfluence of BLER and on TCP performance, frst analytcally, then wth the help of computer smulatons. III. Closed-form expresson of the throughput A TCP segment s successfully transmtted f and only f each of ts RLC PDU reaches the UE correctly. Knowng that a RLC PDU may be transmtted at most tmes, the probablty of a successfull RLC PDU transmsson s gven by P rob (Successful PDU transmsson) = 1 BLER ( ). () If the TCP segment s splt nto N RLC PDUs, the probablty of a successfull TCP transmsson p wrtes p = P rob (Successful TCP transmsson) = 1 BLER ( )] N. (3) In order to compute the throughput of the TCP connecton, we need to estmate the Round Trp Tme (RTT) of the sesson. An analytcal expresson of the RTT applcable to UMTS scenaros has been derved n 3]. The authors splt the whole RTT nto a contrbuton due to the RLC, RT T RLC, and the transmsson delay n the wred network, RT T W red, such that the whole RTT wrtes RT T T CP = RT T RLC + RT T W red. () In the followng, RT T W red values wll be collected from the trace fles of the computer smulatons. In 3], a closed-form expresson of RT T RLC s proposed: RT T RLC (BLER) = RT T RLC P + RT T RLC P ( ) e + T P ollng P 1 e + T T I BLER j N P (5) r j= where varables e, P, T P ollng, T T I and r respectvely stand for the probablty of unsuccessful transmsson of a status report, set as e = 1 (1 BLER) ], () the probablty of needng exactly retransmssons, the pollng tmer delay, the Transmsson Tme Interval, and the number of PDUs transmtted wthn one T T I. x represents the largest nteger less than or equal to x. Relaton (5) does unfortunately not take nto account the lmtaton of the maxmum number of retransmssons. Wrtng that the probablty of the successfull transmsson of N RLC PDUs after attempts as P N = 1 BLER (+1)] N 1 BLER ] N the expresson of RT T RLC becomes RT T RLC (BLER, ) RT T RLC + RT T RLC ( e ) =1 P N + T P ollng { e1 e ( 1) ] 1 e =1 ( 1) e P N =1 + T T I =1 BLER j N j= r P N } (7) P N () wth settng the lmt on the number of possble transmssons of a gven PDU. As already mentoned, errors affectng successve PDUs are assumed to be uncorrelated. Fnally, to derve the throughput, we add RT T W red to RT T RLC n () and nsert the resultng RT T T CP n the analytcal expresson from ] gvng the throughput of a TCP Reno connecton. Assumng that the TCP wndow sze reaches ts maxmum value W MAX, the authors of ] obtan T hroughput (BLER, ) = p + WMAX RT T T CP ( W MAX + + Q (p, W MAX ) ) pw MAX + + Q(p,WMAX )G(p)T (9) wth the help of (3) and (). In (9), stands for 1 p, T represents the TCP retransmsson tmer, whle

3 Smulaton 1 3 Number of smulatons 5 5 Length s] Number of users 1 Traffc FTP Downlnk kbps] RT T W red s] DCH TTI ms] PDU sze Bytes] W Max TCP Verson Reno 1..1] BLER...] TABLE I Smulatons parameters Q(p, W MAX ) and G(p) are functons defned as Q (p, W MAX ) { = mn 1, 1 3 ] { G(p) = WMAX WMAX 3]} } () ( 1) p. (11) =1 IV. Smulaton set-up The scenaro descrbed n Secton II has been smulated wth the help of the Network Smulator ns- 5] and ts Enhanced UMTS Rado Access Network Extensons (EU- RANE) ]. These extensons dd not provde a lmtaton for the number of retransmssons, and therefore we had to mplement t ourselves. Only the hatched elements of Fg. 1 were smulated. The detals of the ns- smulaton set-up were as follows: a sngle user was downloadng a sngle fle usng FTP, durng ether or seconds, wth a downlnk bandwdth of 3, 1 or 3 kbps. The uplnk bandwdth was set to 3 kbps, to avod uplnk packet loss due to congeston. The BLER was set wthn,.], ncreasng by.5 for each smulaton. The smulaton parameters are summarsed n Table I. The TCP performance s measured n terms of RTT and average throughput. The RTT s calculated accordng to Karn s algorthm 7, p. 31], e.g. gnorng retransmssons. The average throughput s the total amount of transfered data durng 5 (3 kbps, 1 kbps) or (3 kbps) smulatons, dvded by the total smulaton length. The RLC buffer sze was set large enough to have no mpact on TCP performance, as opposed to the work presented n ]. V. Analyss of Results Fgs. -5 show the RTT and the throughput as a functon of the BLER and the maxmum number of RLC AM transmssons, for a downlnk bandwdth of 1 kbps. BLER value goes from to., whle we lmted to 1. RTT and throughput values are ether measured by post-processng ns- trace fles (Fgs. and ) or derved from relatons () and (9), refer to Fgs. 3 and 5. Estmates of the RTT for low and hgh BLER are ether unavalable or questonable n Fg.. Obvously, the total RTT can not be lower than RT T W red. However, some estmates seem to be that small. Ths s actually a statstcal artefact, due to the fact that the number of collected samples from ns- trace fles was too low to enable us to derve a statstcally meanngful estmate. The wdth of ths uncertanty area grows wth BLER. In the correspondng area n Fg., no throughput s observed. We wll call the lmt beyond whch no throughput s observed Ret A. On the other hand, there s a value beyond whch the throughput s not growng anymore, that we shall call Ret B. For a gven BLER, Ret A, Ret B ] bound the nterval settng the actual TCP throughput, as llustrated n Fgs. and 7, to be dscussed later on. For values smaller than RET A, there s always at least one RLC PDU corrupted or lost per TCP packet, and therefore the whole TCP packet s regarded as lost. Snce there s no explct congeston notfcaton, the next TCP packet s sent only after the TCP tmeout has expred. Throughput s therefore very low. For values n Ret A, Ret B ], some TCP packets are beng receved correctly, and the throughput s growng very fast wth, reachng ts maxmum n Ret B. For values beyond Ret B, no further ncrease of the throughput s observed. If s set hgher than Ret B, then the throughput decreases lnearly wth BLER, even for hgh RLC PDU loss rates. Movng to the RTT, one can notce from Fg. that the average RTT grows slghtly more than lnearly wth BLER. Comparng smulated to analytcal results, one can notce a pretty good match between absolute fgures on the average. Table II presents the average and maxmal msmatch percentage between smulaton and analytcal results for the three nvestgated bandwdths, for both RTT and throughput. For RTT values, the uncertanty area dscussed here above has been dsregarded. Whereas a good match s acheved at 1 kbps, the msmatch culmnates at 7.3% for the 3 kbps bandwdth. However, one should keep n mnd that the authors of ] acknowledged themselves that ther expresson of the throughput was sufferng from some lmtatons. It seems that these lmtatons appear here. Fnally, as already announced, Fgs. and 7 show the nfluence of on the RTT and the throughput of a 1 kbps TCP connecton at BLER =.15 and. respectvely. Such fgures can help operators to assess the ncdence of the choce of ther value. They

4 Downlnk RT T T hroughput kbps] Average MAX Average MAX 3 13.% 35.%.7% 7.3% 1.93% 13.5%.9% 3.79% % 35.5% 13.3% 31.31% TABLE II Comparson between smulaton and analytcal results llustrate n how much they are confronted wth conflctng goals, as they would lke to acheve the shortest possble RTT, whch requres small, whle delverng the hghest throughput, typcally reached at hgh. In the BLER =.15 case (Fg. ), a value of enables to offer the hghest throughput (115 kbps) at the expense of a RTT equal to 1. s. However, dvdng by leads to a dvson by of the throughput wthout a smlar reducton of the RTT. The stuaton s even more problematc when BLER =. (Fg. 7) where a of would enable to acheve less than one eghth of the measured maxmum throughput. Adaptng to the channel condton mght therefore appear as an appealng soluton. However, the sgnallng overhead ts mplementaton would requre most lkely rules out ths dea. Nevertheless, fgures such as the ones shown n ths paper help to pck an operatng value. ] Jtendra Padhye, Vctor Frou, Donald F. Towsley and James F. Kurose, Modelng TCP Reno Performance: a Smple Model and ts Emprcal Valdaton, IEEE/ACM Transactons on Networkng, vol., n., pp , Aprl. 5] Anonymous, The Network Smulator - ns-, onlne]. No date Cted February 5]. Avalable from: < ] Twente Insttute for Wreless and Moble Communcatons, EU- RANE Webste, onlne]. 15 February 5 Cted February 5]. Avalable from: < 7] W. Rchard Stevens, TCP/IP Illustrated, Volume 1 - The Protocols, Addson-Wesley, 199. VI. Concluson Wth the help of exstng analytcal models that we enhanced on the one hand, and computer smulatons on the other hand, we have shown n ths paper n how much the number of RLC local retransmsson has a drect mpact of the TCP performance. The presented results llustrate to whch extend the selecton of the number of retransmssons based on the qualty of the wreless lnk expressed n terms of error rate can help n achevng a good trade-off between latency and throughput. Acknowledgements The frst two authors would lke to thank ther colleague Etenne Cuveler for hs help n masterng the analytcal developments of Secton III. The authors are also grateful to the anonymous revewers for ther help n mprovng the qualty of the paper. References 1] 3rd Generaton Partnershp Project; Techncal Specfcaton Group Rado Access Network, Rado Lnk Control (RLC) protocol specfcaton, Techncal Report TS 5.3 v.., December. ] Robert Bestak, Phlppe Godlewsk and Phlppe Martns, RLC Buffer Occupancy When Usng a TCP Connecton Over UMTS, n Proceedngs of 13th IEEE Internatonal Symposum on Personal, Indoor and Moble Rado Communcatons PIMRC, Lsbon, Portugal, volume 3, pp , September. 3] Janne Pesa and Mchael Meyer, Analytcal Model for TCP Fle Transfers over UMTS, n Proceedngs of 1 Internatonal Conference on Thrd Generaton Wreless and Beyond, San Francsco, Unted States of Amerca, May 1.

5 AverageRTT ms] 5 1 RTT ms] Fg.. Average RTT for 1 kbps - ns-/eurane results Fg. 3. RTT for 1 kbps - Analytcal results Throughput kbps] 1 Throughput kbps] Fg.. results Average throughput for 1 kbps - ns-/eurane Fg. 5. Throughput for 1 kbps - Analytcal results 15 RTT ms] Ret A Ret B Throughput kbps] RTT ms] Ret A Ret B 5 Throughput kbps] 13 5 RTT Throughput 1 RTT Throughput 1 Fg.. RTT and throughput vs. at BLER =.15 Fg. 7. RTT and throughput vs. at BLER =.