Instantaneous Fairness of TCP in Heterogeneous Traffic Wireless LAN Environments

Transcription

1 KSII TRANSACTIONS ON INTERNET AND INFORMATION SYSTEMS VOL. 10, NO. 8, Aug Copyrght c2016 KSII Instantaneous Farness of TCP n Heterogeneous Traffc Wreless LAN Envronments Young-Jn Jung 1 and Chang Yun Park 1* 1 School of Computer Scence and Engneerng, Chung-Ang Unversty, Seoul, Korea yung@cnlab.cse.cau.ac.kr, cypark@cau.ac.kr *Correspondng author: Chang Yun Park Receved March 3, 2016; revsed May 30, 2016; revsed July 6, 2016; accepted July 16, 2016; publshed August 31, 2016 Abstract Increasngly, numerous and varous Internet-capable devces are connected n end user networks, such as a home network. Most devces use the combnaton of TCP and DCF as a system platform, but whereas some devces such as a streamng vdeo persstently generate traffc, others such as a moton sensor do so only ntermttently wth lots of pauses. Ths study addresses the ssue of performance n ths heterogeneous traffc wreless LAN envronment from the perspectve of farness. Frst, nstantaneous farness s ntroduced as a noton to ndcate how mmedately and how closely a user obtans ts far share, and a new tme-based metrc s defned as an ndex. Second, extensve smulaton experments have been made wth TCP Reno, Vegas, and Westwood to determne how each TCP congeston control corresponds to the nstantaneous farness. Overall, TCP Vegas yelds the best nstantaneous farness because t keeps the queue length shorter than the other TCPs. In the smulatons, about 60% of a far share of the effectve user bandwdth s mmedately usable n any crcumstance. Fnally, we ntroduce two smple strateges for adustng TCP congeston controls to enhance nstantaneous farness and valdate them through smulaton experments. Keywords: TCP Farness, Instantaneous Farness, Heterogeneous Traffc, TCP Congeston Control, DCF Ths research was supported by the Chung-Ang Unversty Graduate Research Scholarshp n ISSN :

2 3754 Park et al.: Instantaneous Farness of TCP n Heterogeneous Traffc Wreless LAN 1. Introducton Increasngly, numerous and varous Internet capable devces are connected n end user networks, such as a home network or an n-car network. Those devces nclude not only general purpose devces such as tablets and laptop computers but also dedcated purpose devces such as streamng vdeo devces and moton capture sensors. Unless power s restrcted, TCP/IP and DCF reman a popular system platform for such devces. However, traffc patterns often vary from the conventonal assumpton that nodes are homogeneous wth smlar traffc patterns. Some devces persstently generate traffc, and others do so only ntermttently wth lots of pauses. As the number of the devces grows, contenton often arses for wreless lnk bandwdth and Internet lnk access. We call ths network usage pattern a heterogeneous traffc wreless LAN envronment. Farness s one of the maor performance metrcs [1] that has been studed extensvely n computer networks. However, the results of prevous studes do not apply well to a heterogeneous traffc envronment because they generally assume homogeneous traffc and focus on how equally each traffc source acheves throughput. For example, for a devce that generates traffc only ntermttently, measurng farness based on throughput s meanngless. Moreover, when that devce starts to send data after a pause, ts traffc could be delayed by the backlogged traffc excessvely generated from neghbors durng ts pause. From the vewpont of that devce, t s acceptable that other devces use ts share whle t s paused, but t should be able to access ts far share mmedately when t starts communcatng, regardless of other devces traffc behavor. Instantaneous farness s the close exstng term for that property. However, exstng studes, for example [2-4], do not apply because ther analyses are based on dfferent assumptons from our heterogeneous traffc wreless LAN envronment, where ntermttent and persstent traffcs are mxed and nether centralzed queue management nor traffc reservaton are supported. A fundamental soluton for ths problem mght be to make a wreless LAN QoS support, such as the e extenson. However, t s unlkely that all the varous devces n the networks would mplement the QoS opton, and even f they dd, managng network QoS would create another hardshp for an ordnary user. A more practcal soluton mght be to use the standard devce platform as the default and make performance predctable by smply controllng the number of devces. In an end user network, obtanng far access to the network n some degree mght be suffcent rather than provdng a strct performance guarantee. Therefore, we choose farness as the performance metrc rather than a response tme guarantee for ntermttent traffc. TCP and DCF are maor components of the most commonly used platform. The congeston control mechansm of TCP supports long-term farness among flows sharng the lnk; thus, the traffc for each source s controlled n some way. On the other hand, DCF n prncple provdes a far chance to transmt to all contendng devces for every frame transmsson. Therefore, they provde not only long-term farness n homogeneous traffc but also the possblty of nstantaneous farness to some degree even n heterogeneous traffc. The obectve of ths study s to fgure out how TCP corresponds to nstantaneous farness n a heterogeneous traffc wreless LAN envronment. Ths study, frst defnes the traffc model and the qualty of nstantaneous farness n a heterogeneous traffc envronment, and ntroduces a new smple new ndex for nstantaneous farness. Next, usng the ndex, we have evaluated the nstantaneous farness of three

3 KSII TRANSACTIONS ON INTERNET AND INFORMATION SYSTEMS VOL. 10, NO. 8, August representatve TCPs, Reno, Vegas and Westwood, by smulaton. Overall, TCP Vegas performs the best among them; Vegas s collson avodance keeps queue lengths low, whch allows ntermttent traffc to recover ts share quckly at the end of a pause. Fnally, based on that expermental analyss, we have ntroduced two strateges for adustng TCPs to acheve better nstantaneous farness and valdated them usng smulaton results. Most prevous studes on qualty of servces n a user network address reservaton-based performance guarantee, whch requres new or extended system platforms. We beleve that our approach s practcal because t can be appled on the platforms currently used, and t s suffcent to estmate servce qualty because performance at a node n a user network can be approxmated based on the degree of farness provded. A smple and ntutve metrc s ntroduced to measure how closely and how nstantly a devce can obtan ts expected performance on average. We have found that selectng a proper TCP verson, a devce can acheve about 60% of the far share of the effectve TCP bandwdth mmedately, regardless of ts neghbors behavor. We also show that mmedacy can be mproved even more wthout sacrfcng the aggregate throughput. The rest of ths paper s organzed as follows. Secton 2 descrbes related work. Secton 3 explans the heterogeneous traffc wreless LAN envronment n detal and defnes nstantaneous farness and ts ndex. Extensve experments have been made to fgure out how exstng TCPs perform vs-à-vs nstantaneous farness n secton 4. Secton 5 ntroduces two adustment polces to enhance nstantaneous farness and valdates them by smulaton. Fnally, secton 6 concludes the study. 2. Related Work There have been numerous studes on farness n computer networks. We summarze those most related to ths study n three subareas: TCP farness, nstantaneous farness, and farness ndex. TCP farness s one of the requrements for TCP congeston control methods; therefore every TCP verson satsfes long-term farness as long as all traffc sources use the same TCP verson. For example, [5] proves t n a concse way. Most TCP farness studes address farness n a mxed TCP stuaton n whch dfferent TCP versons compete [6-8]. They have found that loss-based TCPs such as Reno are sgnfcantly more favored n general than delay-based TCPs such as Vegas. TCP farness n a wreless LAN has also been covered n many studes, and unfar sharng between upstream and downstream traffc s one of the maor ssues [9-11]. Interestngly, [12] has addressed the farness ssue between short-lved flows and long-lved flows, whch s smlar to the ntermttent and persstent traffc, respectvely, n our heterogeneous traffc envronment. That study ntroduces new queue management schemes that mprove unfar treatment aganst short-lved flows, but t does not consder a far share. In ths study, we measure the degree of farness as how quckly and closely a devce acheves ts far share and suggest TCP adustments for mprovng farness n a dstrbuted way. Snce long-term farness covers only the average behavor, farness could be broken n a short nterval. For stronger farness, researchers have also studed nstantaneous farness or short-term farness [13]. Analyzng farness at any nstance requres the descrpton of each source s throughput as a functon of tme, whch can be very complcated n a general network and traffc envronment. Hence most studes on nstantaneous farness assume ether homogeneous traffc [3,14] or centralzed queue management [2,15]. Our approach n ths study s practcal n the sense that analyss s done not on general tme but per

4 3756 Park et al.: Instantaneous Farness of TCP n Heterogeneous Traffc Wreless LAN transmsson-task wth arbtrary data length. Also, I assume a common real-lfe envronment: heterogeneous traffc across a dstrbuted wreless LAN. Many defntons of a farness ndex exst, and Jan s Index [16] s the representatve example n TCP farness. Dependng on how an ndex value s calculated, they can be broadly grouped nto two types. The frst s calculated from the performance values that each compettor actually obtans through contenton. The other s calculated based on the deal performance value achevable n a perfectly far allocaton. Jan s Index s an example of the frst type, and examples of the second type nclude [3], whch s the rato to the throughput of GPS (generalzed processor sharng) schedulng, and [2], whch s the varatonal dstance from the case of unform dstrbuton. Our nstantaneous farness ndex s of the second type, the rato to the case the far share s perfectly allocated. The dstnctve dfference s that our ndex s tme-based, whch means that the ndex value s calculated from the fnsh tme of each transmsson sesson, whereas almost all exstng ndexes are throughput-based. Because the nstantaneous farness ndex should address mmedacy, t s beleved that a tme-based ndex s more ntutve than a throughput-based ndex. 3.1 Network and Traffc Model 3. Instantaneous Farness The network envronment n ths study s an wreless LAN, as a user lnk of Internet such as a home network, where there s a base staton, aka AP and several nodes are assocated wth t. As NIC s nexpensvely avalable, t s wdely used not only n tradtonal computng equpment such as tablets but also n a varety of devces such as streamng vdeo devces, CCTVs, and home applances. Therefore, we assume DCF as a lnk access protocol because t s a default settng that all those devces can support. There s no feature of fxed allocaton; far bandwdth sharng s acheved by on-demand contenton. Snce our study goal focuses on TCP farness, we assume for smplcty that the channel condtons of all nodes are the same. From the pont of vew of network traffc, some nodes, such as a wreless CCTV camera, are traffc ntensve, whereas others, such as a moton sensor, generate traffc sporadcally or perodcally. Although there are no hard real-tme requrements, a far chance of transmsson and quck response are desrable. Most farness studes have assumed a homogeneous traffc envronment n whch all compettors generate the same patterns of traffc requests; for example, all the nodes always have backlogged data to transmt. However, that s unrealstc n the envronment above. Ths study concerns farness n a heterogeneous traffc envronment. As n all farness studes, we assume that enough traffc exsts to cause competton among the nodes. Some nodes, such as sensors, mght use not TCP but UDP as a transport protocol, but most of the traffc wll stll come from TCP. Because UDP does not have a traffc control mechansm, most farness studes exclude UDP traffc. Ths study also assumes that UDP traffc does not cause farness problems; more precsely, the aggregaton of all UDP traffc s lmted under some porton of the lnk bandwdth. All TCP users compete for the remanng lnk bandwdth, and the farness n that stuaton s the concern n ths study. We also assume that all nodes use the same verson of TCP. Ths study categorzes user traffc,.e., applcaton traffc nto two types: persstent and ntermttent. Persstent traffc descrbes data sent wthout a pause, though the user needs not generate traffc contnuously. It s enough that the length of data s unbounded, and hence the

5 KSII TRANSACTIONS ON INTERNET AND INFORMATION SYSTEMS VOL. 10, NO. 8, August transmsson has no end pont. Examples nclude the traffc from a vdeo camera, an Internet rado, or a home cloud server heavly used. Intermttent traffc comes from a user that pauses and sends data n a perodc or sporadc manner. Examples nclude the traffc from an energy consumpton sensor or mage capturng sensor. The amount of the ntermttent traffc s usually small, but t can sometmes occur n large bursts. Ideally, a user should be able to use ts far share of the bandwdth whenever t wants, regardless of how other users behave. However, n the real network envronment of TCP and , hgh utlzaton s also one of the performance obectves, and bandwdth unused by one user can be used by others. In our traffc classfcaton, the unused far shares of ntermttent user can be used by the persstent users. Because long-term farness s already provded n the envronment, every persstent traffc user can use at least ts far share, and hence, there s no need to consder farness for them. In fact, the persstent traffc s consdered background traffc that s always consumng ts share and watng for the chance to use more. The cost for ths opportunstc use s nstantaneous farness for the ntermttent user. When an ntermttent user starts to transmt after a pause, t should compete for ts far share wth the background traffc users already usng excessve bandwdth. Therefore, t s worth dscussng how quckly and how closely an ntermttent traffc user can acheve ts far share. Our traffc model s formally defned as follows. We call an acton n whch a user sends data wthout an ntermsson a transmsson sesson. The -th transmsson sesson of user s denoted by T, and each transmsson sesson s specfed as ( s,() where s s the sesson start tme and l s the data length. The traffc of user s descrbed as a sequence of transmsson n sessons U = < T, T, T, T > where n s the total number of transmsson sessons of 1 user. Persstent traffc s descrbed as U = < T = (0, ) >, whch means that a user has one transmsson sesson that starts at tme 0 and sends an unbounded length of data. 1 U = < T = (0, ) > corresponds to the nfntely backlogged traffc model frequently used n many farness studes. It s worth notng that our traffc model s desgned to analyze only farness: t specfes not the rate of a transmsson but only ts length. Our reasonng s that the transmsson length s determned by the user, but the actual sendng rate s determned by the TCP. Also, we assume one TCP user per node,.e., only one applcaton workng at a node, for smplcty n analyss. The case of multple users at a node s translated n the followng smple ways. All the persstent traffc users are merged nto one persstent user. For each ntermttent traffc user, a new node s added n the network and the user s moved to that node. Although ths translaton does not keep the exact equvalence n performance, the result would be smlar enough to the orgnal to address our obectve n ths study: the nstantaneous farness of ntermttent traffc. 3.2 Defnton of Instantaneous Farness Instantaneous farness has been used as a specfc termnology to emphasze momentarness. Farness means the qualty of equal resource sharng, and when farness s used alone, t usually sgnfes long-term farness, n whch equal sharng s consdered for an nterval long enough for the system to go nto a stable state. Instantaneous farness, sometmes called short-term farness, addresses equal sharng for any short nterval. From the dctonary defnton, another aspect s mmedacy. That s, nstantaneous farness could also be used to address how quckly equal sharng s acheved. To the best of our knowledge, no study on TCP

6 3758 Park et al.: Instantaneous Farness of TCP n Heterogeneous Traffc Wreless LAN farness has explctly addressed ths mmedacy, whch could be understood n the followng ways. Frst, most farness studes cover only long-term farness, and n long-term farness, momentary unequal sharng does not matter. For example, an earler arrval of a perodc transmsson could cause momentary unequal sharng, but n the farness evaluaton, t s consdered to have leveled off over the long nterval. The latency for gong nto a far state also does not matter. Second, exstng farness studes have assumed a homogeneous traffc envronment, often one n whch all sources always have backlogged transmssons. Some studes have addressed nstantaneous farness by analyzng the status of sharng for a momentary nterval n a mcroscopc way, but those studes have shown lttle care for nherently uneven traffc, as n the heterogeneous traffc envronment ths study assumes. Traffc requests vary over tme n a heterogeneous traffc envronment, and hence short-term farness also vares wth tme. A few studes have addressed nstantaneous farness n a heterogeneous traffc envronment, for example [2], but ther tme-varyng farness ndexes are not ntutve. Moreover, for a node wth ntermttent transmssons, the farness durng a pause does not matter, and thus t s meanngless to evaluate the farness for all nodes together. Ideal farness descrbes a stuaton n whch the exact far share s provded mmedately whenever a transmsson sesson begns. In summary, farness n a heterogeneous traffc envronment should address 1) how much of ts far share a node can use whle t transmts and 2) how mmedately a node reaches ts far share after t begns transmttng. Certanly, long-term farness s nadequate to determne those thngs. From the dctonary meanng, the term nstantaneous farness seems to be the best-ft, but exstng defntons do not nclude mmedacy. In prncple, DCF provdes nstantaneous farness. Every tme the network decdes who wll access the lnk, all nodes wth data to transmt compete n a memory-less and far manner: a pause n the past creates nether favor nor dsfavor. Ignorng the one tme effect of the frame length, each node can access ts far share mmedately at any moment. However, TCP s not perfect n our defnton of nstantaneous farness, though t provdes long-term farness. Wth respect to mmedacy, dfferent methods for controllng the congeston wndow have dfferent latences of effect. Also, because of bufferng at ntermedate nodes between the TCP ends, such as an AP, the memory-less property s nvald. In short, nstantaneous farness s complcated to analyze and vares wdely dependng on TCP versons. One of the goals n ths study s to fgure out whch TCP gves better nstantaneous farness and why. 3.3 Metrcs: Instantaneous Farness Index Many researches have defned a farness ndex, and Jan s Index [16] and the Relatve Farness Bound [17] are representatve examples. TCP farness ndexes are mostly orented from Jan s Index. Exstng nstantaneous farness ndexes are defned smlarly to long-term farness ndexes, but they are nterval-specfc. Almost all exstng ndexes are throughput-based, whch means that the ndex value s calculated from the throughputs of each compettor. Accordng to our defnton of nstantaneous, the farness ndex should address mmedacy. Because the throughput does not drectly specfy latency, a throughput-based farness ndex cannot ndcate nstantaneous farness drectly. Hence, we ntroduce a new tme-based nstantaneous farness ndex. Let B be the bandwdth of a shared lnk n byte and N be the number of nodes n the lnk. Then B/N s the deal lnk bandwdth share per node wthout loss from any overhead, such as medum access control overhead. However, due to the nevtable overhead, the effectve lnk bandwdth s less than B. Moreover, the effectve user bandwdth at the end, whch s the real

7 KSII TRANSACTIONS ON INTERNET AND INFORMATION SYSTEMS VOL. 10, NO. 8, August throughput applcatons can get, mght be even less than that at the lnk because of the overhead of the protocol software processng at the node. Let ρ be the rato of the effectve user bandwdth at the end to B. Snce our goal s to compare the farness among dfferent types of TCP congeston control methods, fgurng out the exact value of ρ s unnecessary. In other words, the amount of overhead does not need to be analyzed because t s mposed equally, whchever congeston control the TCP apples. From the same reasonng, we assume a sngle flow per node for smplcty, whch means that each node has one transmttng TCP user. Assumng the overhead s evenly mposed across the nodes, the effectve bandwdth share at TCP s: B S TCP ( N) = ρ wheρe 0 ρ 1 (1) N Supposng TCP s perfectly effcent and far, ths bandwdth share should always be provded to each applcaton; f an applcaton transmts L bytes of data, t should fnsh n L / STCP ( N). However, ths s dffcult to acheve n practce. In fact, dfferent versons of TCP gve dfferent fnsh tmes, and hence, those tmes could be used n evaluatng TCP farness behavor. The man cause of the dfference s the congeston control mechansm. As mentoned above, persstent traffc users can transmt more than ther far share n a heterogeneous traffc envronment. The amount of data excessvely transmtted vares dependng not only on the traffc stuaton but also on dfferent TCP versons polces for congeston control. In summary, the fnsh tmes to transmt L bytes of data vary by TCP verson, even n the same network and traffc stuaton. In ths study, the rato of real fnsh tme to the deal fnsh tme for each transmsson sesson s used as the bass for the farness ndex. The closer t gets to 1, the better nstantaneous farness s acheved. The new nstantaneous farness ndex s bascally the arthmetc average of all the rato values of transmsson sessons that occurred n the experment. It s worth notng that the data length of a transmsson sesson, l, affects the rato and farness ndex. As t lasts longer, the weght of mmedacy becomes smaller on the real fnsh tme. If t s long enough, the rato s close to one because TCP provdes long-term farness. In the case of nfnte length, for example transferrng an nfntely long fle, whch s frequently used n throughput experments, the fnsh tme cannot be defned. Therefore, transmsson sessons wth nfnte data length are not part of the nstantaneous farness ndex, even though ther traffc ndrectly affects the rato for others. The formal defnton of the new nstantaneous farness ndex s as follows. Let r be the rato of the fnsh tmes of transmsson sessont. Let the real measured fnsh tme be m. The deal fnsh tme s estmated from the far share determned n Equaton (1) and the data length of T and s denoted by e. Let be the data length of T (.e., T = ( t, ) n the traffc model n Secton 3.1). If Thus, forl, l l s, m r s decded as follows. r cannot be measured, and ( e s not calculable. e ( / STCP( N) ( = = = (2) ) ) ) S ( N) TCP

8 3760 Park et al.: Instantaneous Farness of TCP n Heterogeneous Traffc Wreless LAN It s worth notng that each rato s determned not by throughput measurement but by tme measurement; that s, t s a tme-based metrc. In addton, n equaton (2), the rato looks lke a functon of N, but n practce t s almost ndependent of N because the measured fnsh tmes, m, also vares wth N, the number of users. The value of N ndrectly affects the amount of contenton overhead. The tme rato n Equaton (2) can also be nterpreted as the conventonal throughput-based farness defnton. Fg. 1 llustrates the behavors of transmsson rate varaton for two cases n an abstract way. The left sde s the deal case wth perfect nstantaneous farness and effcent resource sharng, and the rght sde s a smplfed trace of a general TCP transmsson rate. Assumng no errors n transmsson, the transmsson rate s converted to the throughput. There are two traffc users n the network: the upper one s persstent wth nfntely backlogged data, and the lower one s ntermttent wth a transmsson sesson startng at t start wth data length L. In the deal case, the persstent traffc transmts at two tmes ts far share S untl ts as t takes advantage of the bandwdth left unused by the ntermttent traffc. At t start, the ntermttent traffc user mmedately recovers ts far share and transmts data for the L / S tme of. It s the perfect resource sharng case, and hence we use t as the bass for determnng the degree of nstantaneous farness. Fg. 1. Abstract Transmsson Rate Behavor n Heterogeneous Traffc (Ideal vs. TCP) The transmsson rate of TCP contnually vares around the avalable bandwdth n the shape of a saw blade, whch s bascally the result of adustng the congeston control wndow n an addtve ncrease and multplcatve decrease (AIMD) manner. At the start or after a long tmeout the avalable bandwdth s newly estmated through the slow start process. Hence, n the case of TCP, t takes some tme after t start tll the ntermttent traffc user transmts up to the far share S. Ths tme lag may be lengthened because the feedback of an ntermttent traffc packet suffers delay from competton wth packets from exstng persstent traffcs. Meanwhle a persstent traffc user does not decrease ts transmsson rate unless a negatve feedback s detected. The far share of the ntermttent traffc user wll be eventually recovered due to the far access of networks, and the tme latency depends on how much and frequently the TCP controls the transmsson rate of ts traffc. In summary, the tme to fnsh

9 KSII TRANSACTIONS ON INTERNET AND INFORMATION SYSTEMS VOL. 10, NO. 8, August transmttng L bytes vares dependng on whch congeston control mechansm the TCP uses. Suppose the ntermttent traffc user fnshes ts transmsson at fnsh. Then the average transmsson rate R avg n the transmsson nterval s /( fn/h /tart) R s nterpreted as the throughput n the nterval. The relatve degree of farness n that nterval becomes Ravg L /( t fn/h t/tart) L degree of farne// = = = S S S ( t t ) L and S t t ) corresponds to ( fnsh start are ust an nstance of S TCP t L t t, and ths avg fn/h /tart l and (N) n Equaton (2), respectvely, and m, a measured fnsh tme of a transmsson sesson. Therefore, our defnton of nstantaneous farness based on tme s compatble wth the conventonal defnton based on throughput. Fnally, the nstantaneous farness ndex IF s the arthmetc average of those values of the K = ), then IF s vald rato. Let K be the total count of the measured fnsh tmes (.e., { } defned as follows. r IF = where m s avalable and l (3) K As usual for farness ndexes, the closer IF gets to 1, the better nstantaneous farness s acheved. Moreover, because IF s bascally the rato between the deal and real fnsh tmes, the performance of a communcaton task can be estmated usng IF. For example, f the IF s 0.6 n a wreless LAN wth 5 devces, a devce can obtan 60% of ts far share,.e., 60% of one ffth of the maxmum user-level bandwdth, at any tme. It can also fnsh ts communcaton task no later than 1.66 (1/0.6) tmes of the best fnsh tme t can get. Put another way, f the performance estmated usng IF s unacceptable, the network should be redesgned to ether reduce the number of nodes n the network or provde QoS support. Fnally, t s worth mentonng that the ndex s calculated from not response tmes but transmsson fnsh tmes. Gven the nevtable errors and delays n transmsson, the response tme s a more precse performance parameter. Ths study uses the fnsh tme for the followng reasons. Frst, from the vewpont of measurng how quckly a user can use ts far share, the fnsh tme at the sender s more ntutve than the response tme. Second, purely practcally, fnsh tmes are easer to acqure, and we found few dfferences n the results between response tmes and fnsh tmes n our experments. The only exceptonal cases are when the data length of a transmsson sesson s so short that the sesson s fnshed wthout any feedback,.e., TCP Ack. m 4. Experments: Comparng the Instantaneous Farness of TCP Versons 4.1 Approxmatng a Far Bandwdth Share n Computng the nstantaneous farness ndex requres a knowledge of the far share of effectve bandwdth for each user. Snce the obectve n the experments s comparng how well each

10 3762 Park et al.: Instantaneous Farness of TCP n Heterogeneous Traffc Wreless LAN TCP verson supports nstantaneous farness, the exact value of a far share s unnecessary. We nstead, smply approxmate t by a smulaton measurement as follows. Frst, we estmate the effectve bandwdth of a lnk. For b, the lnk bandwdth s 11M bps, but the effectve bandwdth s much less than that because of the varous sources of overhead. Fndng the scenaro wth the maxmum effectve bandwdth s not straghtforward. For example, as the number of nodes to transmt ncreases, concurrent transmssons can ncrease the total throughput by reducng dle tmes, but the overhead for collson resoluton also ncreases. Table 1 shows the aggregate throughputs as the sum of the throughputs at all nodes n smulatng varous network stuatons. For each of UDP/Download, UDP/Upload, TCP/Download and TCP/Upload, the best scenaro to maxmze the aggregate throughput s selected (shown n boldface font), and ther value wll be used as an effectve bandwdth for each test case. Instead of the lnk bandwdth, throughputs at the transport protocol,.e., end-to-end bandwdths are measured, whch s eventually used n computng a far share. Table 1. Aggregate Throughputs n Varous Stuatons (Measured n NS b) Test Case Download Upload 1 node 7.83M bps 8.00M bps UDP 2 nodes 7.83M bps 8.92M bps 4 nodes 7.84M bps 9.04M bps 8 nodes 7.84M bps 8.89M bps 1 node 4.88M bps 4.97M bps TCP 2 nodes 4.91M bps 5.02M bps 4 nodes 4.96M bps (0.62M Bps) 5.51M bps 8 nodes 4.80M bps 6.88M bps (0.86M Bps) Three factors are vared n the test cases: the number of nodes n the wreless LAN, the type of transport protocol (TCP/UDP), and the drecton of traffc (upload/download). Because UDP has much less protocol overhead than TCP and no control transmsson rate, the UDP cases gve hgher throughputs than the correspondng TCP cases. It s reasonable that the UDP throughput s the effectve lnk bandwdth and the TCP throughput s the effectve end-to-end bandwdth. TCP throughput s shown n the unt of Bps (bytes per second). As dscussed n many studes, n networks, the throughput for upload traffc s usually hgher than that for download traffc. Our NS2 smulaton experments have also shown the same pattern. In most cases, the hghest throughput s observed when the number of nodes n a basc servce set s 4. The only excepton s the TCP upload case, whch s hghest wth 8 nodes transmttng. Overall, the smulaton results are consstent wth the exstng analytc results, for example [11] and the common sense performance measures of As ρ B n Equaton (1) s determned, S (N TCP ) can be smply calculated. For a download traffc user n a network wth N nodes, the far bandwdth share s about 620/N KBps. For example, when a network contans 4 nodes, each TCP user should be able to receve 155 Kbytes per second f farness s provded. In the same network, a far share for upward traffc users s 215 KBps. 4.2 Instantaneous Farness of Exstng TCP Versons Because t s practcally nfeasble to buld a controllable network envronment, we have evaluated performance by smulaton. Snce the goal n the experments s to compare the

11 KSII TRANSACTIONS ON INTERNET AND INFORMATION SYSTEMS VOL. 10, NO. 8, August performance behavors of TCP versons, precse and realstc performance measures are unnecessary. The well-known NS2 [18, 19] s used as a smulaton tool. The expermental envronment s as follows: A wreless LAN conssts of one AP and n wreless nodes workng n 11 Mbps where n s an expermental varable that must be an even number. All wreless nodes are placed at the same dstance from the AP, about 5 meters, and ther channel condtons are consdered to be the same. The AP s connected wth a server through a wred network whose latency s set to 10 mllseconds. Wth respect to traffc, one half of the n wreless nodes generates persstent traffc, and the other half does ntermttent traffc wth perodc transmsson sessons. The length of a transmsson sesson s also an expermental varable, but for each experment, all nodes have transmsson sessons whose length and perod are the same but start tmes are dfferent. Because a node s far share n upload s dfferent from that n download, we have made separate experments n each drecton such that all sources generate traffc n a sngle drecton. Bdrectonal cases, wth half the traffc downloaded and the other half uploaded, have been tested, but those results not shown here because they are bascally the average of the results n each drecton. Frst, we have compared the nstantaneous farness ndex values of representatve TCP versons wth download traffc whle varyng the number of nodes n the network from 2 to 10. Half of the nodes runs the ftp applcaton wthout length, generatng as much persstent traffc as possble. Each of the other nodes generates ntermttent traffc by runnng the ftp applcaton wth 10 Kbytes n the perod of 10 seconds. For each of those transmsson sessons, the fnsh tme s measured and ts rato to the deal fnsh tme s calculated usng Equaton (2) to determne the nstantaneous ndex. The experments are made separately by changng the TCP verson of all nodes. The results of three TCP versons, TCP Reno, TCP Vegas, and TCP Westwood, are shown here because they are well-known representatves wth dfferent congeston control polces. We have also tested several other TCP versons, ncludng Lnux and Westwood-NR, but they all, even Westwood, gve results smlar to Reno s n our bt-error-free smulaton envronment. Therefore, TCP Reno and TCP Vegas are the maor comparson targets. The results are shown n Fg. 2-(a). TCP Vegas always gves better nstantaneous farness than TCP Reno and Westwood. Wth 4 nodes, the ndex value for TCP Vegas s two tmes hgher, whch means that TCP Vegas completes a transmsson sesson two tmes faster than the other TCPs. As the number of nodes ncreases, the dfference ncreases; the ndex values for Reno and Westwood stay mostly the same, but that for Vegas gets hgher Instantanesous Farness Index Reno Vegas Westwood Instantanesous Farness Index Reno Vegas Westwood Number of Nodes (The Length of Transmsson Sesson = 10 Kbytes) (a) Fg. 2. Instantaneous Farness Index wth Download Traffc Length of Trasnsmsson Sesson n Bytes (The Number of Nodes = 4) (b)

12 3764 Park et al.: Instantaneous Farness of TCP n Heterogeneous Traffc Wreless LAN TCP Reno and Westwood keep aggressvely sendng data untl they detect a packet loss, and thus the buffer at the AP s contnuously flled wth packets from the persstent traffc. It takes a relatvely long delay for the ntal packets from an ntermttent transmsson to pass through the buffer. On the other hand, wth persstent traffc, TCP Vegas mostly works n the congeston avodance mode, whch manages the congeston wndow n a precautous manner to avod an over-accumulaton of packets at the buffer [20, 21]. Thus when usng TCP Vegas, the ntal packets from an ntermttent traffc user suffer a shorter queung delay at the AP buffer, and then the faster TCP feedback speeds up the whole transmsson process. That s why TCP Vegas always yelds a shorter transmsson fnsh tme and a hgher nstantaneous farness ndex value than the other TCPs. As the number of nodes ncreases, the lnk and the AP buffer get more congested, but the far share of a node decreases. The congeston control mechansm n every TCP verson mantans a congeston level to some degree, and the fnsh tmes ncrease roughly n proporton to the number of nodes. Because TCP Vegas proactvely avods congeston, the ncreasng rato of the fnsh tmes could be slower than that of the far share, and hence ts slope s up. Next, we have repeated the same experments whle varyng the data length of the transmsson sesson. Because the performance behavor s bascally the same regardless of the number of nodes, the number of nodes s fxed at 4. Transmsson length s an mportant factor n nstantaneous farness because t determnes the weght of latency for a TCP to go from the dle state to the far share. If the data length s suffcently long, the latency s less mportant than the throughput acheved n the far state. The results of these second experments are shown n Fg. 2-(b). The ndex values for TCP Vegas vary lttle, whch means that TCP Vegas consstently provdes some porton, specfcally about 60%, of the far share from the begnnng to the end of every transmsson sesson. Wth TCP Reno and Westwood, the ndex values ncrease as the length of the transmsson sesson grows. When the length s 500 Kbytes, the ndex values are greater than those of TCP Vegas because the shortcomng n mmedacy caused by the aggressveness of other traffc sources fades as the transmsson tme ncreases. In fact, a 500 Kbytes transmsson sesson requres longer than three seconds even n deal far sharng, so t looks lke a persstent transmsson. One thng to note here s that ths result does not mean that TCP Vegas s always worse n a long transmsson; the length of 500 Kbytes s ust one of cases n whch TCP Reno and Westwood do better than TCP Vegas. The throughput ssue wll be explaned later. We have performed the same valdaton processes for upload traffc. As shown n Fg. 3, the overall performance behavor pattern s smlar to the download case, but there are dfferences n detal. When varyng the number of nodes, the ndex values are lower than those for the download traffc overall, and the ndex values for TCP Reno and Westwood consstently decrease as the number of nodes ncreases. When varyng the length of a transmsson sesson, the reversal pont comes earler than wth the download, at 50 Kbytes, and all ndex values for TCP Vegas are less than 0.5.

13 KSII TRANSACTIONS ON INTERNET AND INFORMATION SYSTEMS VOL. 10, NO. 8, August Instantanesous Farness Index Reno Vegas Westwood Instantanesous Farness Index Reno Vegas Westwood Number of Nodes (The Length of Transmsson Sesson = 10 Kbytes) (a) Fg. 3. Instantaneous Farness Index wth Upload Traffc Length of Trasnsmsson Sesson n Bytes (The Number of Nodes = 4) (b) There are two man reasons for ths dfference. Frst, uploadng nvolves multple data traffc sources, whereas only one source,.e., AP, s nvolved n downloadng. In prncple, because there are more chances to fll the lnk n uploadng than n downloadng, the potental end-to-end bandwdth s hgher n uploadng than n downloadng. In effect, as shown n Secton 4.1, the effectve end-to-end bandwdth and far share are both hgher n uploadng. As the far share ncreases, the ndex values decrease n most cases. In TCP Reno and Westwood, more aggressve sources of persstent traffc result n longer latency for a transmsson sesson to go nto a far state, and hence the ndex values decrease as the number of uploadng nodes grows. The second reason s that TCP Vegas does not realze a hgh actual throughput from the hgh end-to-end bandwdth durng uploadng, though TCP Reno and Westwood do well. In competng wth multple maor transmtters n , the reactve, opportunstc, and aggressve approach of TCP Reno and Westwood s a better ft than the proactve, cautous, and altrustc approach of TCP Vegas. As the length of a transmsson sesson grows, the ntermttent traffc gets closer to the persstent traffc, and the ndex value becomes more dependent on the transmsson rate than the latency. That explans why Reno and Westwood yeld hgher ndex values than Vegas when the length s longer than or equal to 50000, as shown n Fg. 3-(b). One mght doubt that the hgher nstantaneous farness ndex values of TCP Vegas are by-products of ts lazer executon n fllng the lnk. To answer ths we have also measured and compared throughputs durng the farness experments descrbed above. Fg. 4 shows the aggregate throughput as the sum of the goodputs of all traffc sources, ncludng both persstent and ntermttent traffc, whle varyng the number of nodes n download and upload. Half of the nodes are the source of ntermttent traffc whose length per transmsson sesson s 10 Kbytes. The other half of the nodes persstently attempt to transmt as much data as possble.

14 3766 Park et al.: Instantaneous Farness of TCP n Heterogeneous Traffc Wreless LAN Aggregate Throughput (Bps) Reno Vegas Westwood Aggregate Throughput (Bps) Reno Vegas Westwood Number of Nodes Number of Nodes (a) Download (b) Upload Fg. 4. Aggregate Throughputs When Varyng the Number of Nodes In the download case shown n Fg. 4-(a), TCP Vegas always yelds at least a comparable throughput to Reno and Westwood except when the number of nodes s 2. Therefore, the better nstantaneous farness of Vegas does not come from underutlzaton of the lnk. It results nstead from sharng the lnk n a manner that mantans nstantaneous farness wthout sacrfcng throughput. In the upload case shown n Fg. 4-(b), Reno and Westwood yeld a hgher throughput than Vegas when there s no contenton or hgh contenton, specfcally, when only one or more than 4 nodes are uploadng persstently. It s true that Reno and Westwood sacrfce nstantaneous farness n favor of throughput. However, that does not mean that Vegas uses less of the lnk n favor of farness. Vegas s ust too cautous to be as hghly compettve as Reno and Westwood. Consderng that downloadng accounts for most of the traffc n , ths shortcomng of Vegas does not seem too crtcal. 5. Smple Adustments for TCPs To Enhance Instantaneous Farness 5.1 Two Adustment Strateges The expermental results show that two polces of the exstng TCPs prevent nstantaneous farness. The one s aggressveness, whch keeps the congeston wndow hgher, especally n TCP Reno. It keeps the buffer at the AP flled wth persstent traffc, and therefore when an ntermttent transmsson begns, a long ntal delay occurs. The other s cluelessness about ntermttent traffc. TCP s orented to long-term throughput and does not take much account of ntermttent traffc spurts. Not only does dle tme n the past not gve any favor n the current transmsson sesson, but also the state nformaton from the past sesson s forgotten durng the pause. It takes a long latency for an ntermttent transmsson to get a far share, begnnng from a slow start n many cases. To mprove nstantaneous farness, these two polces should be adusted. Each of the followng strateges s ntroduced as the soluton for each polcy, respectvely.

15 KSII TRANSACTIONS ON INTERNET AND INFORMATION SYSTEMS VOL. 10, NO. 8, August lmt the aggressveness of persstent traffc, encourage ntermttent traffc users to be more aggressve. Before explanng the mplementaton of those adustments n detal, t s worth notng that our mplementaton efforts have been mnmal because our goal s to valdate the approprateness and feasblty of the adaptaton strateges. Both mplementatons of the adustments are far from complete; they are nether optmal nor fne-tuned for better performance. They are only complex enough to show the effects of the adustments. The frst adustment s to lmt the effectve wndow sze. It s appled to TCP Reno because TCP Vegas already keeps the wndow sze lower. In the NS2 smulator t s smply mplemented by settng the maxcwn_ parameter of a TCP agent, whch means the upper bound on the congeston wndow for a TCP connecton, to some value. The default settng n Reno s 0, whch means there s no upper bound. As shown n the prevous secton, TCP Vegas manages comparable throughputs whle keepng the congeston wndow value around 10. Hence, we smply set the upper bound to 10 and called t TCP Reno-MaxWn10. TCP Reno-MaxWn10 has the obvous drawback of lmtng the maxmum throughput a TCP connecton can obtan. However, that drawback s not realzed as long as multple sources are competng. For example, n our smulaton envronment, the drawback sn t a problem as long as more than one node sends persstent traffc. The second adustment s to favor an aggressve wndow ncrease at the begnnng stage of a transmsson sesson after a pause. We have appled t to TCP Vegas to observe the adustment effect separately and to check whether even TCP Vegas can be mproved. Here, we adusted the Vegas parameters α and β as most Vegas extensons have done at the pont of outputtng data down to the lower layer protocol [22]. Fg. 5 shows the code segment added to the TCP Vegas code of NS2 n pseudo code. The modfed verson s called TCP Vegas-Far. Every tme a TCP data segment s sent, Vegas-Far computes the nterval between the current tme and the most recent tme that t sent a segment. If the nterval s greater than a gven threshold defnng a pause (PAUSE_INTERVAL), a new transmsson sesson s consdered detected. The amount of data sent s ntalzed, and α and β are ncremented by one and two, respectvely. Because α ndcates the stop pont for ncreasng and β does the trgger pont for decreasng the congeston wndow, ncrementng both of them gves more chance to ncrement and less chance to decrement the congeston wndow. Ths aggressve management of the congeston wndow s confned only to the begnnng of a transmsson sesson. If the amount of data sent durng ths transmsson sesson s greater than a gven threshold (INTRO_LENGTH), Vegas-Far decdes the ntroductory phase s over, and the two parameters return to ther orgnal values. The values of those thresholds are mportant because they decde when and for how long a favor s done. In ths study, we smply set them to 1 seconds and 5000 bytes to check the effectveness of the adustment strategy. Determnng optmal values for them would be desrable, but t s outsde the scope of ths paper.

16 3768 Park et al.: Instantaneous Farness of TCP n Heterogeneous Traffc Wreless LAN // nserted at the end of output() of TCP Vegas Code n NS2 currenttme = vegastme(); f (currenttme()-lastsenttme >= PAUSE_INTERVAL) { nbytethssesson = bytesegment; f (v_alpha_ == v_alpha_org) { v_alpha_ += 1; v_beta_ += 2; } } else { nbytesthssesson += bytesegment; f ( (nbytethssesson >= INTRO_LENGTH) { v_alpha_ = v_alpha_org; v_beta_ = v_beta_org; } } lastsenttme = currenttme(); Fg. 5. Code Segment of TCP Vegas-Far 5.2 Valdaton of the Adustments The expermental method for ths valdaton s the same as explaned n Secton 4.3. We measured the nstantaneous farness ndexes and aggregate throughputs of TCP Reno, Reno-MaxWn10, Vegas, and Vegas-Far. Frst, as shown n Fg. 6-(a), n download traffc Reno-MaxWn10 always gves hgher ndex values than Reno, and Vegas-Far gves hgher values than Vegas. Thus, each adustment polcy mproves nstantaneous farness. It s partcularly noteworthy that by smply lmtng the maxmum of the effectve wndow sze, Reno-MaxWn10 behaves smlarly to Vegas-Far. However, the mprovement does not come wthout cost. Fg. 6-(b) shows the aggregate throughputs n upload traffc when varyng the number of nodes. Reno-MaxWn10 loses the aggressveness of Reno and cannot thrve n hgh competton stuatons. The more crtcal problem s that the maxmum throughput wth lttle competton s also restrcted by the wndow sze lmt. It could become worse n a network envronment wth longer RTTs. An adaptve scheme seems to be requred to change the maxmum effectve wndow dependng on the network and traffc stuaton. On the other hand, Vegas-Far shows almost dentcal throughput behavor wth Vegas, ndcatng the exstence of few sde-effects. Wth more tunng of the Vegas-Far parameters could mprove, but more fundamental studes would be requred to recapture Reno s throughput n upload traffc. We leave more delberate adaptaton methods for future study.

17 KSII TRANSACTIONS ON INTERNET AND INFORMATION SYSTEMS VOL. 10, NO. 8, August Instantanesous Farness Index Length of Trasnsmsson Sesson n Bytes (The Number of Nodes = 4) (a) Download Instantaneous Farness Index Reno Reno-MaxWn10 Vegas Vegas-Far Aggregate Throughput (Bps) Number of Nodes (The Length of Transmsson Sesson = 10 Kbytes) (b) Upload Aggregate Throughput Reno Reno-MaxWn10 Vegas Vegas-Far Fg. 6. Aggregate Throughputs When Varyng the Number of Nodes 6. Concluson In ths work, we have addressed performance n a heterogeneous traffc wreless LAN envronment from the perspectve of farness. An ntermttent traffc user should be able to get far network access whle t ntends to communcate. Therefore, we set a far share of the effectve user bandwdth as the deal goal and call the degree to whch a user can mmedately acheve t nstantaneous farness. Based on measurements of the fnsh tmes of transmsson sessons, we have defned a new smple and ntutve ndex for nstantaneous farness. Then, exstng TCPs have been tested because the congeston control methods greatly affect nstantaneous farness. Overall, TCP Vegas provdes better nstantaneous farness than Reno and Westwood because ts congeston avodance polcy shortens the queue length. It s found that smply selectng a proper TCP verson made about 60% of the far share of the effectve TCP bandwdth achevable mmedately, regardless of neghbors traffc behavor. Ths mples that nstantaneous farness can also be used to estmate network performance. Fnally, we have valdated that smple TCP adustments can enhance nstantaneous farness. More experments, ncludng measurements n real networks, wll gve better nsght on the usefulness of nstantaneous farness as a performance parameter. Adustng TCPs to enhance nstantaneous farness has been valdated, but more studes are needed to consder and address potental sde effects. References [1] S. Floyd, "Metrcs for the evaluaton of congeston control mechansms," RFC 5166, Artcle (CrossRef Lnk) [2] H. Sh and H. Sethu, "An evaluaton of tmestamp-based packet schedulers usng a novel measure of nstantaneous farness," n Proc. of the 2003 IEEE Internatonal Conference on Performance, Computng, and Communcatons, pp , Artcle (CrossRef Lnk) [3] J. Deng, Y. Han, and B. Lang, "Farness Index Based on Varatonal Dstance," GLOBECOM 2009, pp. 1-6, 2009.Artcle (CrossRef Lnk) [4] S. Im, J. Kulkarn, and B. Moseley, "Temporal Farness of Round Robn: Compettve Analyss for Lk-norms of Flow Tme," n Proc. of the 27th ACM on Symposum on Parallelsm n Algorthms and Archtectures, pp , Artcle (CrossRef Lnk) [5] D. Chu and R. Jan, "Analyss of the ncrease and decrease algorthms for congeston avodance n computer networks," Computer Networks and ISDN systems, vol. 17, no. 1, pp. 1-14, Artcle (CrossRef Lnk)

18 3770 Park et al.: Instantaneous Farness of TCP n Heterogeneous Traffc Wreless LAN [6] G. Hasegawa, K. Kurata and M. Murata, "Analyss and mprovement of farness between TCP Reno and Vegas for deployment of TCP Vegas to the Internet," n Proc. of 2000 Internatonal Conference on Network Protocols, pp , Artcle (CrossRef Lnk) [7] M. Nels and et al., "Inter-protocol farness between TCP NewReno and TCP Westwood," n Proc. of 3rd EuroNGI Conference on Next Generaton Internet Networks, vol. 1, pp , [8] K. Bsoy, Sukant and P. Pattnak, "Throughput of a Network Shared by TCP Reno and TCP Vegas n Statc Mult-hop Wreless Network," Computatonal Intellgence n Data Mnng Volume 1, pp , Artcle (CrossRef Lnk) [9] S. Pokhrel and et al., "TCP Performance over W-F: Jont Impact of Buffer and Channel Losses," IEEE Transactons on Moble Computng, Artcle (CrossRef Lnk) [10] S. Prya and K. Murugan, "Enhancng TCP Farness n Wreless Networks usng Dual Queue Approach wth Optmal Queue Selecton," Wreless Personal Communcatons vol. 83, no. 2, pp , Artcle (CrossRef Lnk) [11] S. Plosof and et al., "Understandng TCP farness over wreless LAN," INFOCOM 2003, vol. 2, pp , Artcle (CrossRef Lnk) [12] Q. Wu, M. Gong, and C. Wllamson, TCP farness ssues n IEEE wreless LANs, Computer Communcatons, vol. 31, no. 10, pp , Artcle (CrossRef Lnk) [13] N. Al-Ratta, M. Al-Rodhaan, and A. Al-Dhelaan, "FMAC: Far Mac Protocol for Achevng Proportonal Farness n Mult-Rate WSNs," Communcatons and Network, vol. 7, no. 2, pp , 2015.Artcle (CrossRef Lnk) [14] H. Jamoom and K. Shn, "On the role and controllablty of persstent clents n traffc aggregates," IEEE/ACM Transactons on Networkng (TON), vol. 14, no. 2, pp , Artcle (CrossRef Lnk) [15] F. Baccell and D. Hong, "The AIMD model for TCP sessons sharng a common router," n Proc. of the Annual Allerton Conference on Communcaton Control and Computng, vol. 39, no. 2, pp , [16] R. Jan, D. Chu and W. Hawe, A quanttatve measure of farness and dscrmnaton for resource allocaton n shared computer system, vol. 38. Eastern Research Laboratory, Dgtal Equpment Corporaton, [17] S. Golestan, "A self-clocked far queueng scheme for broadband applcatons," INFOCOM '94. pp , Artcle (CrossRef Lnk) [18] "Network Smulator ns-2," Artcle (CrossRef Lnk) [19] C. Na, J. Chen and T. Rappaport, "Measured traffc statstcs and throughput of IEEE b publc WLAN hotspots wth three dfferent applcatons," IEEE Transactons on Wreless Communcatons, vol. 5, no. 11, pp , Artcle (CrossRef Lnk) [20] L. Brakmo and L. Peterson, TCP Vegas: End to end congeston avodance on a global nternet, IEEE J. of Selected Areas n Communcaton, vol. 13, pp , Artcle (CrossRef Lnk) [21] M. Massaro, C. Palazz and A. Buar. "Explotng TCP Vegas' algorthm to mprove real-tme multmeda applcatons," n Proc. of Consumer Communcatons and Networkng Conference (CCNC) 12th Annual IEEE, pp , Artcle (CrossRef Lnk) [22] E. Abolfazl and V. Shah-Mansour, "Dynamc adustment of queue levels n TCP Vegas-based networks," Electroncs Letters, vol.52, no. 5, pp , Artcle (CrossRef Lnk)

19 KSII TRANSACTIONS ON INTERNET AND INFORMATION SYSTEMS VOL. 10, NO. 8, August Young-Jn Jung receved the B.S. degrees n computer engneerng from Chung-Ang Unversty, Seoul, Korea n He s currently a M.S. Student n the School of Computer Scence and Engneerng, Chung-Ang Unversty, Seoul, Korea. Hs research nterests nclude wreless sensor network, 5G Network, and energy-effcent communcaton. Chang Y. Park receved the B.S. and M.S. degrees n computer engneerng from Seoul Natonal Unversty, Seoul, Korea n 1984 and 1986, respectvely, and receved the Ph.D. n computer scence from the Unversty of Washngton, Seattle n He s currently a Professor n the School of Computer Scence and Engneerng, Chung-Ang Unversty, Seoul, Korea. Hs research nterests nclude computer networks, and real-tme systems.