Congestion Control in Wireless Flow-Aware Networks

12 downloads 276 Views 191KB Size Report
Networking (FAN) for QoS assurance in wireless networks is studied in the ..... value of the wireless packet loss parameter (0.1), the efficiency of transmission in ...
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings

Congestion Control in Wireless Flow-Aware Networks Jerzy Dom˙zał, Member, IEEE, Nirwan Ansari, Fellow, IEEE, Andrzej Jajszczyk, Fellow, IEEE Abstract—Applicability of the concept of Flow-Aware Networking (FAN) for QoS assurance in wireless networks is studied in the paper. The link utilization efficiency for six versions of the TCP protocol in the FAN environment is investigated and compared. A new congestion control mechanism for FAN, referred to as RAMAF (Remove and Accept Most Active Flows), has been proposed to fulfill the wireless link requirements. While in basic FAN, new flows cannot begin transmission in congestion, the new solution ensures short acceptance times of new streaming flows in a router regardless whether the outgoing link is congested or not. As compared to other congestion control mechanisms proposed for FAN, RAMAF does not need to tune any parameters, and is thus automatic. Moreover, the proposed solution allows for more effective transmission of elastic flows in comparison to other approaches, and may be used in both wired and wireless FAN. Results of the carefully selected simulation experiments show that TCP NewJersey incorporated with the RAMAF mechanism meets the requirements of the wireless transmission in FAN. Index Terms—Flow-Aware Networks; Quality of Service; congestion control; wireless transmission; TCP

I. I NTRODUCTION The number of internet services increases rapidly every year. A user has a wide range of possibilities, not only in choosing the applications, but also in selecting the end user devices or the connection method. Guaranteeing high quality transmission for emerging bandwidth demanding services and applications is a real challenge for Internet Service Providers (ISPs) as well as large carriers. There are some well known QoS architectures, like DiffServ (Differentiated Services) [1], but they are complicated and in many cases do not work as expected. Currently, many ISPs prefer to buy some additional capacity, rather than to implement the complicated and not widely accepted solutions. In this paper, we study the applicability of the Flow-Aware Networking (FAN) concept, proposed by S. Oueslati and J. Roberts [2], to ensure QoS in networks containing wireless links. FAN is a simple architecture, which aims at providing maximum possible benefits in the perceived QoS using only the minimal knowledge of the network. It is a very promising solution that meets the requirements of current and future applications and services. J. Dom˙zał and A. Jajszczyk are with the Department of Telecommunications, AGH University of Science and Technology, Al. Mickiewicza 30, 30-059 Krakow, Poland (e-mail: {domzal, jajszczyk}@kt.agh.edu.pl). N. Ansari is with the Advanced Networking Laboratory, Department of Electrical and Computer Engineering, New Jersey Institute of Technology, University Heights, Newark, NJ 07102, USA (e-mail: [email protected]).

Many reports in the literature have analyzed transmission in a wired FAN. This paper presents a pioneering analysis of FAN in a heterogeneous environment, with wired and wireless links. The goals of this paper are twofold. Firstly, we analyze the effectiveness of TCP transmission in a heterogeneous wired-wireless FAN. It is important to note that the methods of guaranteeing the quality of service for wireless networks differ greatly from those proposed for the wired networks. In wireline networks, TCP usually assumes that all losses of ACKs are caused by congestion. In wireless networks, TCP has to react to packet loss in a different way because the loss may also be caused by wireless link errors. Improving performance of TCP in wireless IP communications has been an active research area. In this paper, we analyze the hybrid wired-wireless network operated with different versions of the TCP protocol. The goal is to observe the effectiveness of transmission when an end user is connected by a wireless link and to find the best solution for transmission in heterogeneous Flow-Aware Networks with QoS guarantees. Secondly, as the currently known congestion control mechanisms for FAN may fail in the wireless environment, we propose a new congestion control mechanism for FAN, referred to as RAMAF (Remove and Accept Most Active Flows). RAMAF ensures short acceptance times for streaming flows in congestion and facilitates significantly better conditions for transmission of elastic flows as compared to other FAN solutions. Moreover, this is the first proposal which may be successfully used in both wired and wireless FAN. The rest of the paper is organized as follows. Section II presents the main assumptions and a brief description of the FAN architecture. In Section III, six TCP versions are briefly described in the context of their usefulness in wireless networks. Section IV presents the congestion control mechanisms proposed for FAN so far as well as the new RAMAF mechanism. In Section V, the results of carefully selected simulation experiments are presented. The key point of this part is to show the effectiveness of transmission in a FAN network under control of the RAMAF mechanism. Section VI concludes the paper. II. F LOW-AWARE N ETWORKS The Flow-Aware Networking concept, first proposed in 2004 [2] is relatively new. The main goal of FAN is to achieve efficient packet transmission with the minimal knowledge of the network. In FAN, the traffic is sent as flows (streaming or elastic). The first type of flows is usually used by real-time applications while the second one carries best effort traffic.

978-1-61284-231-8/11/$26.00 ©2011 IEEE

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings

Packets

Flow analyzer

on PFL?

Scheduler

Add to PFL

o N

Accept

Ye s

Accept

MBAC

Re jec t

Dropper

Fig. 1.

Packet service in FAN

The flows are served in the cross-protect routers (also denoted as XP’s) composed of two blocks, the admission control (AC) and the scheduler. The former makes decisions of accepting or rejecting packets while the latter is responsible for periodically measuring values of the following two parameters: • fair rate — estimates the maximum rate that might be or is realized by elastic flows; • priority load — measured as a quotient of the sum of the lengths of queued packets with priority in a given time period to the length of this period. The packet service in FAN is presented in Fig. 1. In the congestion-less state, new flows are accepted in the MBAC (Measurement-Based Admission Control) block and their identifiers (IDs) are written into the protected flow list (PFL). The IDs of inactive flows are removed from PFL after a fixed time as determined by the pfl flow timeout parameter. In congestion, we cannot accept new flows. A FAN link is congested if the value of fair rate or priority load exceeds certain threshold. Note that the state of congestion is usually derived from the fair rate parameter. In congestion, only packets of flows with IDs written in PFL may be served. That is, sometimes, a new flow has to wait for a long time before it is allowed to begin transmission. This situation is unacceptable for real-time applications, like VoIP (Voice over IP) or VoD (Video on Demand). Two scheduling algorithms were proposed for FAN, PFQ (Priority Fair Queuing) [3] and PDRR (Priority Deficit Round Robin) [4]. Another proposal for realizing the FAN concept, called AFAN (Approximate FAN), was described in details in [5]. These FAN versions yield similar results. That is why the simulation analysis presented in this paper is provided only for the PFQ algorithm. FAN is a scalable solution. It was shown [6] that the complexity of the queuing algorithms does not increase with the link capacity. Moreover, fair queuing is feasible, as long as the link load is not allowed to attain saturation levels (it is ensured by the admission control). Finally, FAN conforms to the net neutrality paradigm, as the differentiation is based only on the internal, implicit node decisions. That is, services in a network may be differentiated, while fairness and neutrality are maintained. III. W IRELESS TRANSMISSION IN FAN Wireline transmission in FAN has been reported in the literature. QoS aspects as well as reliability of transmission in FAN are analyzed. However, FAN with respect to wireless transmission has not been reported. In this section, we present

a brief overview of selected TCP versions, which are further analyzed by extensive simulations. The goal is to find the best solution for realizing the wired-wireless transmission in FAN, to be used in Future Internet. TCP versions usually differ in their means of reacting to packet loss in a network. In wired networks, packet losses are usually caused by congestions while in wireless networks it is also necessary to consider losses caused by wireless link errors. TCP NewReno is a well known scheme used for transmission in data networks. NewReno is a modification of TCP Reno such that the fast recovery algorithm is not activated by each lost packet. NewReno copes with multiple losses from a single window. It assumes that the fast recovery algorithm may be terminated when all losses, indicated from one window, are recovered. One of the main drawbacks of NewReno is its inability to distinguish the cause of a packet loss. Thus, the implementation of a more effective fast recovery algorithm is not possible. TCP Sack (TCP Selective Acknowledgment Options) uses the same congestion control mechanisms as TCP Reno to steer the congestion window size. The difference between the two versions is observed when many packets, which belong to the same window, are lost. By using the additional options in a packet header, the receiver may inform the sender which segments are correctly received and which need to be retransmitted. Based on this information, the sender may immediately send the lost packets again. TCP Sack has similar drawbacks as those of TCP NewReno. TCP Tahoe uses a congestion avoidance algorithm which implements an additive-increase-multiplicative-decrease (AIMD) scheme and slow-start. It does not use the fast recovery algorithm. When Tahoe detects a congestion, it reduces congestion window to the maximum segment size, and activates the slow-start phase. In TCP Westwood, the bandwidth estimator is used at the sender side. The transmission rate is estimated based on the rate of received acknowledgements. The size of congestion window is calculated dynamically according to the number of lost packets. This version of TCP also does not consider what causes the packet losses. TCP Vegas was proposed in 1994, before TCP NewReno and TCP Sack. It differs from the above TCP versions in that the congestion is detected based on increasing Round Trip Time values of the packets in a connection. It assumes that, during congestion, the real bandwidth is smaller than the estimated value, and based on this information, the window size is increased or decreased. TCP Vegas tries to use the available capacity without causing congestions. Unfortunately, the cause of the congestion is not analyzed, either. The TCP versions presented above are well known and have been described in many papers. The last of the TCP versions analyzed here is TCP NewJersey [7], [8]. It is a relatively new TCP version, which allows proper reaction to the cause of congestion. TCP Jersey, which is a predecessor to TCP NewJersey, adopts the slow start algorithm, congestion avoidance, and fast recovery from Reno, but replaces fast re-

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings

transmit with explicit retransmit and introduces the rate control procedure based on ABE (available bandwidth estimation). If the ACK of a packet arrives at the sender without the CW (Congestion Warning) mark, it proceeds as NewReno. The rate control procedure is invoked by the ACK or third DUPACK marked with the CW bit. It adjusts the widow size for further transmission. It is assumed that a packet drop is caused by the random error when the sender receives the third DUPACK without the CW mark. In this case, the fast retransmit procedure is called without adjusting the window size. The combination of ABE and CW improves TCP’s ability to differentiate sources of packet losses. In TCP NewJersey, the performance in the heterogeneous networks is improved by modifying the inaccurate bandwidth estimation caused by the ACK burstiness. Moreover, the transmission rate is stabilized by minimizing the volatility of the flow load. TCP NewJersey works in a different way in FAN links. We do not mark any packet. Our observations show that there are almost no packet losses in congested basic FAN (without RAMAF) link. In such a case, it is not important if we mark packets or not. On the other hand, many packets losses occur in the FAN link with RAMAF. When we remove flow IDs from PFL, flows’ packets cannot be queued and are lost. However, such losses cannot be treated as congestion induced but rather like errors in a link. Therefore, we should not decrease rates of flows for lost packets are lost due to the RAMAF properties. TCP NewJersey ensures that all packets lost in a FAN link are retransmitted without adjusting the window size. IV. C ONGESTION CONTROL IN FAN Four congestion control mechanisms have been proposed for FAN [9], i.e., EFM (Enhanced Flushing Mechanism), RAEF (Remove Active Elastic Flows), RBAEF (Remove and Block Active Elastic Flows), and RPAEF (Remove and Prioritize in access Active Elastic Flows). All these mechanisms work based on partial or total periodical clearing of the PFL content in congestion. The goal is to ensure that streaming flows are accepted in a sufficiently short time. In EFM, the IDs of all elastic flows are periodically removed from PFL if the outgoing link is congested. Next, the removed flows compete for access to the XP router with other flows. RAEF removes the IDs of flows which are active for time equal or greater than the value given by the active time parameter. The rest is similar to that of EFM. The RBAEF mechanism assumes that the IDs removed from PFL are added to the Blocked Flow List for a short time. It allows for fast acceptance of new flows, but degrades the transmission of removed flows. In RPAEF, the IDs removed from PFL are added to the Priority in Access Flow List for a short time. It gives a high probability of acceptance for removed flows, but a low (but sufficient) probability for new streaming flows. In this section, we present our proposed mechanism, called RAMAF (Remove and Accept Most Active Flows). RAMAF periodically removes IDs of a number of most active flows from PFL. This number is set dynamically based on the

New ID - once „clean_el_time” is exceeded after last flush, remove IDs of all elastic flows added to PFL which began transmission prior to the value of „clean_el_time” New ID in congestion - once „cleaning_timer” is exceeded, remove N most active flows from PFL add them to PAFL 1 . N most active flows . N

ID_3 elastic ID_1 streaming ID_2 elastic

ID_2 elastic ID_1 elastic

ID_1 elastic

RAMAF New ID in congestion-less - copy all IDs from PAFL to PFL - empty PAFL - add new ID to PFL

ID_2 elastic ID_1 elastic

ID_2 elastic ID_1 elastic

ID_3 elastic ID_1 streaming

RAMAF

Fig. 2.

Packet service in FAN with the RAMAF mechanism

queue occupancy. Next, in a congestion-less state, the removed IDs are added to PFL again. It allows for dynamic changes of values of the fair rate parameter around the minimum acceptable value, and consequently gives chances to new flows to begin their transmissions. The packet service in RAMAF is presented in Fig. 2. The pseudo code for realizing the RAMAF functionality is presented in Table I. The RAMAF mechanism is invoked when a packet of a new flow arrives at the admission control block of the XP router. Regardless of the state of congestion of the outgoing link, RAMAF checks for the time that PFL was last ”cleared”. If it is greater than the value of the clear el time parameter (Lines 2-3 of Table I), IDs of each flow which began transmission prior to the value of clear el time parameter (lines 4-14) are removed. control param helps to ensure that IDs of new elastic flows are removed from PFL only once after PFL is flushed (lines 3 and 11). Next, in congestion, RAMAF periodically writes the number of queued bytes of elastic flows to the table tab (lines 1619). Then, the maximum value in the table tab is found (line 22). Next, the number N of flows to be removed from PFL is computed as the difference of the number of flows which have queued packets and the coefficient 100/min f air rate minus 1 (line 23). The estimated value of the coefficient means the number of flows which may be served with the guaranteed fair rate. Next, the function draw (line 24) is run. It draws N flows, which have max bytes bytes in the queue from table tab, removes their IDs from PFL, and puts them into PAFL (Priority in Access Flow List). At the end, the incoming packet p is discarded. In the congestion-less state, all IDs from PAFL are copied into PFL (line 32) and then removed from PAFL (line 33). At the end, the incoming packet p is accepted and sent for queuing (line 35). The RAMAF mechanism works dynamically. We only assume the maximum time of acceptance of streaming flows and

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings

TABLE I P SEUDO CODE FOR REALIZING THE RAMAF FUNCTIONALITY IN FAN 1. on a new flow packet p arrival 2. current time = Scheduler :: instance().clock() 3. If current time − last clearing > clear el time && control param = 1 then 4. begin 5. For (i = 1; i ≤ pf l size; i++) do 6. begin 7. active time(i) = current time − f irst time(i) 8. If f low bytes(i) ≥ M T U then 9. begin 10. If active time(i) clearing timer then 17. begin 18. For (i = 1; i ≤ pf l size; i++) do 19. If f low bytes(i) ≥ M T U then 20. begin 21. tab[i] = f low bytes(i) 22. max bytes = f ind max(tab); 23. N = q l − (100/min f air rate − 1); 24. draw(tab, max bytes, removed f lows); 25. last clearing = Scheduler :: instance().clock(); 26. control param = 1; 26. end 27. end 28. discard packet p ************************************************************ 29. ************** in congestion-less state *************** 30. For (i = 1; i ≤ paf l size; i++) do 31. begin 32. copy ID(i) from PAFL to PFL; 33. remove ID(i) from PAFL 34. end 35. proceed with packet p 36. ******************** end ************************* ************************************************************

the rest is performed automatically. This is a very important advantage over the other proposals. Moreover, the RAMAF mechanism is the first proposal among the existing congestion control solutions that assumes all removed flows are always accepted again after a clearing action of PFL. It allows short breaks in transmission and provides satisfactory transmission parameters for each elastic flow. Other congestion control mechanisms assume that the removed flows are accepted again with high probability or even order them to compete with new flows for acceptance in a router without any privilege. Moreover, the performance of transmission of elastic flows is further degraded in a network with wireless links susceptible to errors. Flows may increase their windows too slowly if errors occur, and thus the number of active flows also increases. On the contrary, RAMAF assumes that outages in transmission of elastic flows are short-lived, and all new elastic flows added after a flushing action are removed from PFL for a short time. This analysis shows that the RAMAF mechanism is the best solution for both wireless and wired FAN. In the next section, we present the selection of proper

L3

L1

FAN LINK L2 R1

Fig. 3.

R2

L4

Simulation topology

values of all parameters defined for the RAMAF mechanism, and simulation results which demonstrate the viability of the proposed solution and confirm its advantages. V. S IMULATION ANALYSIS In this section, we present the results of carefully selected simulation experiments of FAN with different versions of the TCP protocol. The goal is to show the impact of a particular TCP version on transmission in FAN with end users connected by wireless links. Moreover, we have analyzed the viability of the RAMAF mechanism in wired-wireless FAN. We used the NS-2 simulator and the topology shown in Fig. 3. We have observed the goodput (the number of packets received by end users) during the transmission from the source to the destination node D2. The source node S was connected to the FAN router R1 via link L1 (with 1 Gbit/s capacity). The FAN routers (R1, R2) were connected via link L2 (with 100 Mbit/s capacity). The R2 router was connected to the destination node D1 via link L3 (with 1 Gbit/s capacity) and to the destination node D2 by a wireless link L4 (with 5 Mbit/s capacity). We analyzed cases with 400 elastic flows (ftp connections) and 20 streaming flows (VoIP connections via Skype service) transmitting their traffic from the source to the destination node D1. The FAN link was heavily loaded from the beginning of the simulation experiments in both directions. The traffic pattern followed the Pareto distribution, and thus the volume of traffic to be sent by the elastic flows could be calculated accordingly. The exponential distribution for generating the time intervals between beginnings of the transmissions of the elastic flows as well as for generating the start times of streaming flows was adopted. The packet size for the elastic flows was set to be 1000 bytes, while that for the streaming flows was set to be 100 bytes. The transmission rate of streaming flows was set to be 80 kbit/s. The elastic traffic was treated as the background traffic and used to saturate the analyzed links. We also added one elastic flow which began its transmission when the simulation started and was sending its traffic during the whole simulation to the destination node D2. For this flow, we observed the goodput. The duration of each simulation run was set to 300 s, which allowed for observing the acceptance times of streaming flows (waiting time) in the R1 router. The buffers in the XP routers were sized to 1000 packets, a reasonable value for FAN links, and the MTU was set to 1500 bytes. The measurement interval for the priority load parameter was set to 50 ms while the fair rate values were estimated every 500 ms. The max priority load parameter was set to 70% and the min fair rate parameter was set to 5%. The flow time out parameter was set to 20 s. We assumed that the random link

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings

Efficiency (Goodput/Wireless Link Capacity) [%]

error rate at the wireless bottleneck link varied from 0.01% (0.0001 in Fig. 4 and Fig. 5) to 10% (0.1 in the figures). Each simulation experiment was repeated at least 10 times. 95% confidence intervals were calculated by using the Student’s t-distribution. The assumed value of the warm-up parameter used in the simulation experiments was 20 s, which ensured that the results of each simulation run represented the steadystate. The efficiency of the wireless link (goodput / wireless link capacity) versus the packet loss rate for the basic FAN is presented in Fig. 4. 100 Newreno SACK Tahoe Vegas Westwood Newjersey

80

60

in Section IV. In the second simulation experiment, we analyzed the new proposal, the RAMAF mechanism. We assumed that each streaming flow should be accepted at the latest in 6 s. We had to determine the value of the clearing timer parameter, which decided how often the IDs of the most active elastic flows had to be removed from PFL. We assumed that the sum of time interval between two fair rate estimations multiplied by two (there were cases when congestion was not eliminated after the first update), the value of the clearing timer and the interval between the time instant when the link became congestion-less and when the first packet of a new streaming flow arrived at the XP router had to be less than 6 s. Based on this estimation, the value of the clearing timer parameter was set to 3 s. In the specification of the RAMAF mechanism, we assumed that the number of removed flows from PFL (N ) ought to be calculated from the following equation:

40

N = q l − (100/min f air rate − 1)

20

0 1e-005

0.0001

0.001

0.01

0.1

1

Wireless Packet Loss Rate

Fig. 4.

TCP efficiency in basic FAN

We can see that for low values of the wireless packet loss, the results are similar for all TCP versions. It is also shown that for the first two values of the wireless packet loss (0.0001 or 0.001), the values of the efficiency are constant for each case. The observed values begin to decrease when the wireless packet loss is equal to 0.01. For the last analyzed value of the wireless packet loss parameter (0.1), the efficiency of transmission in the wireless link is by far the worst in each case. Of course, the obtained results are in accordance with our presumptions. However, it is worth noting that the efficiency of the observed link in case when the wireless packet loss was set to 0.1 for the TCP NewJersey version is about twice greater than those for the other analyzed cases (see also Table II). In TCP NewJersey, the window size is not decreased if packets are lost due to wireless link errors when the buffer occupance threshold is not exceeded. In the other TCP versions, the window size is changed each time a packet is lost. This is a very strong advantage of the NewJersey proposal. The results show that this version of TCP may be the best choice for transmission in wireless links with a high level of errors. In Table II, we also see the mean values of the waiting time for the streaming flows. They show that time needed to begin the transmission by such flows ranges from tens to even hundreds of seconds. While the streaming flows usually realize the real-time transmissions, these values are completely unacceptable. According to [10], the acceptable values of the setup time (post-selection delay) for international calls should not be greater than 11 seconds for 95% of the calls, while for the local calls it should not exceed 6 seconds. The values of the waiting time parameter may be decreased by implementing the congestion control mechanisms described

(1)

where q l is the number of flows, which have at least one packet in the queue. It means that in our experiments, after a clearing action, 19 IDs are left in PFL. It ensured that usually after the next fair rate estimation, the outgoing link became congestion-less, and new flows were able to begin their transmission. We also assumed that the value of the clear el time parameter was set to 1.5 s, implying that the new elastic flows accepted after a clearing action were removed from PFL after 1.5 s from the time when the link became congestion-less. This value was chosen experimentally and ensured that all new elastic flows were removed from PFL in a sufficiently short time. The rest of the simulation parameters were set as in the previous experiment. The results presented in Table II show that the values of the waiting time are sufficiently low for each TCP version, if we implement the RAMAF mechanism. The results presented in Fig. 5 show that the implementation of the RAMAF mechanism degrades the transmission of elastic flows. However, the obtained results are significantly better than those for the other congestion control mechanisms proposed for FAN. In the RAMAF proposal, the elastic flows are, in fact, slowed down from time to time to allow the new streaming flows to begin their transmission, while in the other mechanisms the elastic flows rarely continue their transmission after PFL is flushed. This is a very strong advantage of the RAMAF mechanism. We also have to note that the results are similar for all TCP versions (TCP Vegas looks to be slightly better than other cases) when the wireless packet loss rate is low. TCP NewJersey achieves the best efficiency when the wireless packet loss rate is high. We may conclude that for wireless links without packet losses, we may use any TCP version, while in the links susceptible to packet losses the best choice would be TCP NewJersey. Moreover, we see some possibilities for improving TCP NewJersey in FAN under the control of the RAMAF mechanism.

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings

TABLE II T HE PROPERTIES TCP VERSIONS IN FAN WITH WIRELESS LINK

TCP vers.

0.0001 0.001 0.01 0.1 0.0001 0.001 0.01 0.1 0.0001 0.001 0.01 0.1 0.0001 0.001 0.01 0.1 0.0001 0.001 0.01 0.1 0.0001 0.001 0.01 0.1

Newreno

Sack

Tahoe

Vegas

Westwood

NewJersey

Efficiency (Goodput/Wireless Link Capacity) [%]

Efficiency [%] waiting time [s] Basic FAN 64,44±5,99 138.83±39.81 61.97±11.41 130.97±38.78 62.10±4.90 131.76±50.97 8.70±0.39 120.37±46.66 73.85±2.55 73.31±20.72 72.90±9.54 70.86±32.92 69.99±2.60 71.07±28.96 7.51±1.14 62.66±14.27 76.50±3.54 62.86±13.13 74.08±2.92 72.36±35.47 59.85±1.89 76.46±16.95 6.86±1.14 86.06±18.99 68.91±9.67 80.02±17.06 68.34±12.36 68.46±17.95 71.21±8.05 74.97±20.42 6.86±0.72 72.37±30.69 68.03±2.38 94.45±26.83 69.79±3.69 96.90±23.75 57.97±3.75 96.35±15.43 6.86±1.18 114.90±17.30 62.74±5.41 93.22±27.29 67.21±4.76 84.72±20.87 68.32±2.56 86.62±22.67 18.08±0.52 80.37±18.33

Pkt Loss Rate

100

The simulation results confirm our assumptions and show that in networks with error-free wireless links it is not important which TCP version we use for elastic flows. However, in links with a high packet loss rate the best transmission efficiency is observed for TCP NewJersey. Moreover, we are convinced that it is possible to improve TCP NewJersey if the transmission in a wireless link is stable (without errors).

Newreno SACK Tahoe Vegas Westwood Newjersey

80

60

40

20

0 1e-005

0.0001

0.001

0.01

0.1

1

Wireless Packet Loss Rate

Fig. 5.

Efficiency [%] waiting time [s] RAMAF 41.82±7.21 3.17±1.01 41.82±6.39 2.82±0.96 39.82±6.06 3.12±1.12 7.62±0.78 3.12±1.11 45.69±4.16 2.57±0.64 49.11±5.99 3.17±1.11 39.51±6.02 4.32±1.07 7.23±0.94 2.82±1.03 49.87±7.12 3.22±1.00 45.41±5.86 2.77±0.96 42.51±4.11 2.47±0.66 7.40±0.74 2.57±0.64 54.33±11.10 2.51±0.54 54.94±7.48 2.10±0.15 51.81±8.13 2.11±0.15 7.11±0.53 2.36±0.68 42.40±5.50 3.65±1.11 38.54±4.78 3.80±1.07 33.22±3.92 4.00±1.63 6.24±0.87 3.90±1.25 51.33±7.22 2.66±0.98 45.29±7.49 2.86±0.83 47.10±12.22 2.31±0.68 16.91±0.66 2.31±0.18

TCP efficiency in FAN with the RAMAF mechanism

ACKNOWLEDGEMENTS The work described in this paper was carried out with the support of the BONE-project (Building the Future Optical Network in Europe), a Network of Excellence funded by the European Commission through the 7th ICT-FP. R EFERENCES

VI. C ONCLUSION The paper presents the feasibility of realizing the wireless transmission in FAN, and proposes a new congestion control mechanism to improve the transmission of streaming flows. Many papers in the literature have described the wireline FAN networks. To the best of our knowledge, this is the first attempt to analyze wireless transmission in FAN. The simulations of six TCP versions, i.e., NewReno, Tahoe, Sack, Vegas, Westwood and NewJersey, were conducted to show their properties when an end user was connected to the network by a wireless link with a heavily loaded FAN link. The second goal of the paper was to present the new congestion control mechanism for FAN, called RAMAF. RAMAF ensures expedient acceptance of streaming flows in FAN routers. Moreover, the performance of transmission realized by elastic flows is significantly better than those in the other congestion control mechanisms proposed for FAN.

[1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, “An Architecture for Differentiated Services,” IETF RFC 2475, Dec. 1998. [2] S. Oueslati and J. Roberts, “A new direction for quality of service: Flow-aware networking,” in NGI 2005, Rome, Italy, April 2005. [3] A. Kortebi, S. Oueslati, and J. Roberts, “Cross-protect: implicit service differentiation and admission control,” in IEEE HPSR 2004, Phoenix, USA, April 2004. [4] ——, “Implicit Service Differentiation using Deficit Round Robin,” in ITC19, Beijing, China, August/September 2005. [5] J. Domzal and A. Jajszczyk, “Approximate Flow-Aware Networking,” in IEEE ICC 2009, Dresden, Germany, June 2009. [6] A. Kortebi, L. Muscariello, S. Oueslati, and J. Roberts, “On the scalability of fair queueing,” in ACM HotNets-III, San Diego, USA, November 2004. [7] K. Xu, Y. Tian, and N. Ansari, “Improving TCP Performance in Integrated Wireless Communications Networks,” Computer Networks, vol. 47, pp. 219–237, February 2005. [8] ——, “TCP-Jersey for Wireless IP Communications,” IEEE Journal on Selected Areas in Communications, vol. 22, pp. 747–756, May 2004. [9] J. Domzal and A. Jajszczyk, “New Congestion Control Mechanisms for Flow-Aware Networks,” in IEEE ICC 2008, Beijing, China, May 2008. [10] “Network grade of service parameters and target values for circuitswitched services in the evolving ISDN,” Rec. ITU-T E.721, May 1999.