# Background Traffic-Based Retransmission Algorithm for Multimedia Streaming Transfer over Concurrent Multipaths

Authors: Yuanlong Cao; Changqiao Xu; Jianfeng Guan; Hongke Zhang
Journal: International Journal of Digital Multimedia Broadcasting
 (2012)

---

## Abstract

The content-rich multimedia streaming will be the most attractive services in the next-generation networks. With function of distribute data across multipath end-to-end paths based on SCTP's multihoming feature, concurrent multipath transfer SCTP (CMT-SCTP) has been regarded as the most promising technology for the efficient multimedia streaming transmission. However, the current researches on CMT-SCTP mainly focus on the algorithms related to the data delivery performance while they seldom consider the background traffic factors. Actually, background traffic of realistic network environments has an important impact on the performance of CMT-SCTP. In this paper, we firstly investigate the effect of background traffic on the performance of CMT-SCTP based on a close realistic simulation topology with reasonable background traffic in NS2, and then based on the localness nature of background flow, a further improved retransmission algorithm, namedRTX_CSI, is proposed to reach more benefits in terms of average throughput and achieve high users' experience of quality for multimedia streaming services.


---

## Body

## 1. Introduction

The content-rich multimedia streaming, such as video-on-demand (VoD) [1, 2] and Internet Protocol Television (IPTV) will be the most attractive services in the next-generation networks. Most researches have proved the Stream Control Transmission Protocol (SCTP) will be the most promising technology for the large bandwidth consumption of multimedia streaming services [2–4]. Particularly in the future wireless heterogeneous network that the terminals will be equipped with multiple network interfaces and attached multiple heterogeneous access capability at the same time, the SCTP can provide the effective transmission for multimedia streaming services and balance the overhead among multiple access networks.The SCTP [5] has been proposed and standardized by the Internet Engineering Task Force (IETF) in order to effectively utilize the multihoming environment and support real-time signaling transmission over IP networks, since SS7 has been the only bearer for the signaling traffic in telecommunication networks [6] for many years. SCTP has some important features including: (1) multi-homing. The destination nodes can be reached under the several IP addresses (multi-homed). In SCTP, both sides of the association provide multiple IP addresses combined with a single SCTP port number [7]. (2) Multistreaming which means the parallel transmission of messages over the same association between sender and the receiver. The stream independently carries fragmented messages from one terminal to another, which can achieve a cumulative throughput [8] than other protocols (e.g., TCP). SCTP manages more than one communication path with two major functions: (a) using SACK (selective acknowledgment) to probes primary path connectivity and HEARTBEAT to probe the alternative paths, respectively; (b) fail-over which means once the primary path breaks and selects an alternative path as the primary path.As an improved version of SCTP, Concurrent Multipath Transfer (CMT) [9] uses the SCTP’s multi-homing feature to distribute data across multiple end-to-end paths in a multi-homed SCTP association. CMT is the concurrent transfer of new data from a source to a destination via more than one end-to-end paths, and it is used between multi-homed source and destination hosts to increase the throughputs. Moreover, a CMT sender can maintain more accurate information (such as available bandwidth, loss rate, and RTT) of all the paths, since new data are sent to all destinations concurrently. This feature allows the CMT sender to better decide where to retransmit once data is lost.There is more and more researches pay attention to multimedia streaming, and CMT-SCTP had been employed as transport protocol as well to study the performance of multimedia streaming services. For example, Stegel et al. [10] proposed solutions on how to provisioning SCTP multi-homing in converged IP-based multimedia environment. Huang and Lin [11] proposed a partially reliable-concurrent multipath transfer (PR-CMT) protocol for multimedia streaming in order to improve the throughput and video quality degrade. In our previous work, we designed a novel Evalvid-CMT platform [3, 4] to investigate and evaluate the performance of CMT for real-time video distribution, and then a meaningful suggestion was pointed out on which strategies for real-time video concurrent multipath transmissions.Although the advantages of CMT-SCTP has been investigated in variety of attractive services, however, existing evaluation works [1–16] of CMT-SCTP do not consider the impact of background traffic. Actually, Internet measurement studies showed complex behaviors of Internet traffic [17, 18] that are necessary for realistic testing environments. There are several reasons why background traffic is important in performance testing. First, the aggregate behavior of background traffic can induce a rich set of dynamics such as queue fluctuations, patterns of packet losses, and fluctuations of the total link utilization at bottleneck links and can have a significant impact on the performance of CMT-SCTP. Second, network environments without any randomness in packet arrivals and delays are highly susceptible to the phase effect [19], and a good mix of background traffic reduces the likelihood of synchronization [20]. Third, the core of the Internet allows a high degree of statistical multiplexing. Therefore, the performance evaluation of network protocols with little or no background traffic does not fully investigate the CMT-SCTP behaviors that are likely to be observed when it is deployed in the Internet.On the other hand, there are five retransmission algorithms proposed in [12] to enhance the performance of CMT-SCTP. Previous work [9, 14] take major researching focus on the effects of different retransmission algorithms with different limited receive buffer (rbuf) sizes. However, all of the five retransmission algorithms are designed with only one of paths’ condition as metric. Liu et al. [16] combines some paths’ conditions to select the retransmission path but with an unreasonable metric since loss rate is not be recommended according to RFC4460.In this paper, taking reasonable background traffic into account, we firstly investigate the effect of background traffic on the performance of CMT-SCTP based on a more realistic simulation topology in NS2 [21]. Considering the nature of background traffic and taking paths’ previous states into account, we further propose an improved retransmission algorithm named RTX_CSI to achieve more benefits in terms of average throughput and high users’ experience of quality for multimedia streaming services.The rest of paper is organized as follows. Section2 explains our experimental design for network redundancy in CMT-SCTP. Section 3 presents how effects occurred by designed background traffic. Section 4 addresses the proposed RTX_CSI algorithm and its performance evaluation. Section 5 concludes this paper and discusses the future work.


## 2. Preliminary Work

### 2.1. Background Traffic Design

In accordance with the Internet survey [22], TCP traffic on the Internet is about 80–83%, and UDP traffic is about 17–20%. Moreover, the content-rich multimedia streaming will be the most attractive services in the future networks, more and more multimedia encoded by VBR will be deployed in Internet. Thus, more reasonable background traffic consists of TCP traffic, CBR traffic, and VBR traffic should be taken into account to evaluate the performance of data delivering.With the purpose of investigating the effect of background traffic on the performance of CMT-SCTP, our experiments adopt a more realistic simulation scenario for network redundancy in CMT-SCTP, that is, TCP traffic, CBR traffic, and VBR traffic will be employed in our simulation topology designing. Test scenario consists of one path with TCP traffic and UDP/CBR traffic as background traffic (TCP : UDP/CBR is 4 : 1) and another with TCP traffic and UDP/VBR traffic as background traffic (TCP : UDP/VBR is 4 : 1) which is represented byTCP+UDP/CBR and VBR in below.


### 2.2. VBR Traffic Generator Loading

Since NS2 still cannot support VBR traffic, in order to enable VBR traffic generator in NS2, we addPT_VBR as packet enumeration and then set VBR for PT_VBR’s value in packet information function [23]. The default values for VBR traffic are set as shown in Table 1.Table 1
Parameter settings of VBR traffic.
Variable
Value
Application/traffic/VBR set rate_
448 Kb
Application/traffic/VBR set random_
0
Application/traffic/VBR set max
pkts_
268435456
Application/traffic/VBR set max
Size_
200
Application/traffic/VBR set min
Size_
100
Application/traffic/VBR set intervaltime_
200


### 2.3. Simulation Topology Setup

To investigate the impact of background traffic on the performance of CMT-SCTP completely, a more realistic simulation topology with reasonable background traffic is proposed, which is shown in Figure1. In the dual dumbbell topology, each router (R1~R4) connects to five edge nodes. The edge nodes are single interfaces and connect to the routes to generate the background traffic. Each edge node attaches with a traffic generator, and four edge nodes generate 80% TCP traffic and one edge node generates 20% UDP traffic (CBR or VBR). According to [24], the propagation delay between the edge nodes and routers is set to 5 ms in order to create the maximum effect occurred by background traffic, and bandwidth is set to 100 Mb. The propagation delay between two routers is set to 45 ms with 10 Mb of bandwidth in accordance with article [25] (CMT-PF addressed in this article is not employed in our experiments for pure study of the impact occurred by background traffic).Figure 1
Simulation topology for studying the impact of background traffic.TheS and R stand for CMT-SCTP sender and receiver, respectively, and connected to the network through two interfaces. CMT-SCTP uses concurrent multipath transfer to send data on both paths with the default parameters recommended by RFC4460. After 0.5 seconds of simulation, the CMT-SCTP sender begins to initiate the association with CMT-SCTP receiver. At 1.0 seconds, edge nodes generate the background traffic, and the total simulation time is 30 seconds.


## 2.1. Background Traffic Design

In accordance with the Internet survey [22], TCP traffic on the Internet is about 80–83%, and UDP traffic is about 17–20%. Moreover, the content-rich multimedia streaming will be the most attractive services in the future networks, more and more multimedia encoded by VBR will be deployed in Internet. Thus, more reasonable background traffic consists of TCP traffic, CBR traffic, and VBR traffic should be taken into account to evaluate the performance of data delivering.With the purpose of investigating the effect of background traffic on the performance of CMT-SCTP, our experiments adopt a more realistic simulation scenario for network redundancy in CMT-SCTP, that is, TCP traffic, CBR traffic, and VBR traffic will be employed in our simulation topology designing. Test scenario consists of one path with TCP traffic and UDP/CBR traffic as background traffic (TCP : UDP/CBR is 4 : 1) and another with TCP traffic and UDP/VBR traffic as background traffic (TCP : UDP/VBR is 4 : 1) which is represented byTCP+UDP/CBR and VBR in below.


## 2.2. VBR Traffic Generator Loading

Since NS2 still cannot support VBR traffic, in order to enable VBR traffic generator in NS2, we addPT_VBR as packet enumeration and then set VBR for PT_VBR’s value in packet information function [23]. The default values for VBR traffic are set as shown in Table 1.Table 1
Parameter settings of VBR traffic.
Variable
Value
Application/traffic/VBR set rate_
448 Kb
Application/traffic/VBR set random_
0
Application/traffic/VBR set max
pkts_
268435456
Application/traffic/VBR set max
Size_
200
Application/traffic/VBR set min
Size_
100
Application/traffic/VBR set intervaltime_
200


## 2.3. Simulation Topology Setup

To investigate the impact of background traffic on the performance of CMT-SCTP completely, a more realistic simulation topology with reasonable background traffic is proposed, which is shown in Figure1. In the dual dumbbell topology, each router (R1~R4) connects to five edge nodes. The edge nodes are single interfaces and connect to the routes to generate the background traffic. Each edge node attaches with a traffic generator, and four edge nodes generate 80% TCP traffic and one edge node generates 20% UDP traffic (CBR or VBR). According to [24], the propagation delay between the edge nodes and routers is set to 5 ms in order to create the maximum effect occurred by background traffic, and bandwidth is set to 100 Mb. The propagation delay between two routers is set to 45 ms with 10 Mb of bandwidth in accordance with article [25] (CMT-PF addressed in this article is not employed in our experiments for pure study of the impact occurred by background traffic).Figure 1
Simulation topology for studying the impact of background traffic.TheS and R stand for CMT-SCTP sender and receiver, respectively, and connected to the network through two interfaces. CMT-SCTP uses concurrent multipath transfer to send data on both paths with the default parameters recommended by RFC4460. After 0.5 seconds of simulation, the CMT-SCTP sender begins to initiate the association with CMT-SCTP receiver. At 1.0 seconds, edge nodes generate the background traffic, and the total simulation time is 30 seconds.


## 3. Study of the Impact of Background Traffic

To analyze the impact of the background traffic, this section evaluates the average throughput (delay) of CMT-SCTP with and without background traffic, respectively. To measure the presence of background traffic affecting the performance of CMT-SCTP, we define a metric calledImpact Degree (denoted as Θ) which can be expressed by
(1)Φ(Θα)=|Φ(xα)-Φ(yα)|Φ(xα)×100%,
where α stands for rbuf; x stands for CMT-SCTP without background traffic condition and y for CMT-SCTP with TCP + UDP/CBR and VBR traffic condition; Φ(xα) is on behalf of average throughput or average delay achieved by CMT-SCTP without background traffic under different α; Φ(yα) for average throughput or average delay created by CMT-SCTP with TCP + UDP/CBR and VBR traffic under different α; Φ(Θα) stands for impact degree arisen by TCP + UDP/CBR and VBR traffic. High Φ(Θα) means that background traffic has high side effects on CMT-SCTP in terms of throughput and delay, that is, low average throughput (high average delay) CMT-SCTP will be reached.Since defaultrbuf size commonly used in operating systems today is varied from 16 KB to 64 KB and beyond. Herein, we investigate the impact of background traffic on CMT-SCTP under rbuf size with 16 KB, 32 KB, 64 KB, 128 KB, and 256 KB. Figures 2, 3, 4, 5, and 6 show throughput reached by CMT-SCTP with or without background under different size of rbuf, respectively (the measuring interval is 0.5 s).Figure 2
Comparison withrbuf  = 16 KB.Figure 3
Comparison withrbuf  = 32 KB.Figure 4
Comparison withrbuf  = 64 KB.Figure 5
Comparison withrbuf  = 128 KB.Figure 6
Comparison withrbuf = 256 KB.As illustrated in Figures2, 3, 4, 5, and 6, we can point out that: (1) the background traffic presents an impact on throughput clearly; (2) with the increase of the receive buffer, the impact of the background traffic is increased.Figure7 shows the comparison on average throughput with and without background traffic under different rbuf.Figure 7
Comparison on average throughput.Figure8 shows the comparison on average delay with and without background traffic under different rbuf, respectively.Figure 8
Comparison on average delay.Based on (1) and above simulation results, Figure 9 shows the corresponding impact degree which occurred by the designed background traffic.Figure 9
Impact degree on average throughput and delay.As it shown in Figure7, when TCP + UDP/CBR and VBR is employed as the background traffic, the impact degree on average throughput can be calculated as Φ(Θ16)≈0.0025, Φ(Θ32)≈0.0047, Φ(Θ64)≈0.0278, Φ(Θ128)≈0.2652, and Φ(Θ256)≈0.5238. Figure 9 illustrates that larger rbufwill lead to larger impact degree, namely, larger side effect will occur by background traffic in terms of average throughput.As it shown in Figure8, when TCP + UDP/CBR and VBR is employed as the background traffic, the impact degree on average delay can be calculated as Φ(Θ16)≈0.05019, Φ(Θ32)≈0.0721, Φ(Θ64)≈0.1235, Φ(Θ128)≈0.4941, and Φ(Θ256)≈0.3037. From Figure 9, we note that larger rbufwill lead to larger impact degree. However, when rbuf is set more than 256 KB, the impact will be reduced, the reason maybe that data can be received timely as greater receive buffer is used.From above experiments and analysis, we can conclude that the background traffic can present an obvious impact on CMT-SCTP’s performance in terms of throughput and delay, and it will lead to some known problems like congestion. Thus, we need to take background traffic condition into account during designing the retransmission algorithm.


## 4.RTX_CSI Algorithm

Retransmission algorithms play a more important role in achieving high users’ experience of quality for multimedia streaming services. As mentioned in Section1, there are five retransmission schemes proposed [12] for CMT-SCTP, we call them as existing retransmission algorithms. However, all of exiting retransmission algorithms do not consider the nature of background traffic. This section will simply introduce theexisting retransmission algorithm firstly, and then a further improved retransmission algorithm named RTX_CSI will be addressed with considering background traffic condition, a necessary performance evaluation will be presented lastly.


### 4.1. Existing Retransmission Algorithm

RTX-SAME. Once a new data chunk is scheduled and sent to a destination, all retransmissions of the chunk thereafter are sent to the same destination (until the destination is deemed inactive due to failure).RTX-ASAP. A retransmission of a data chunk is sent to any destination for which the sender has cwnd space available at the time the retransmission needs to be sent. If the sender has available cwnd space for multiple destinations, one is chosen randomly.RTX-LOSSRATE. A retransmission of a data chunk is sent to the destination with the lowest loss rate path. If multiple destinations have the same loss rate, one is selected randomly.RTX-CWND. A retransmission of a data chunk is sent to the destination for which the sender has the largest cwnd. A tie is broken randomly.RTX-SSTHRESH. A retransmission of a data chunk is sent to the destination for which the sender has the largest ssthresh. A tie is broken randomly.However, according to RFC4460, only theRTX-CWND and RTX-SSTHRESH are recommended retransmission policies, and the others are just for experimental sake. Moreover, the RTX-CWND is recommended as the default retransmission strategy since it can present the best performance [12].


### 4.2.RTX_CSI Description

As mentioned in Section1, all of existing retransmission algorithms do not take the impact of background traffic into account. To fix this issue, we consider the localness nature of background flow [19], that is, coming packets will belong to the flow as previously arrived ones in a short period. Correspondingly, the side effect on CMT-SCTP caused by background flow will be the same in short period. As countermeasure of the localness nature of background traffic, paths’ previous states should be considered during designing of retransmission algorithm. Therefore, we take paths’ previous states into account to design an improved retransmission algorithm named RTX_CSI which consists of four more reasonable paths’ conditions during selecting retransmission destination. RTX_CSI follows the below steps to select candidate path for data retransmission.(1)
A retransmission is sent to the destination that has the largestcwnd;(2)
if more than one destination has the largestcwnd, then a retransmission is sent to the one that has the largest ssthresh value;(3)
if there are more than one destination has the largestssthresh value, then a retransmission is sent to the one that has the lowest Time Out Records (tor) in specified time span (denoted asτ);(4)
if more than one destination has lowest timeout records in specified timeslot, then a retransmission is sent to the one that has the largest intervaltinterval (tinterval stands for the interval between the last timeout’s time and current time);(5)
if multiple destinations have the largesttinterval, then a tie will be broken by random selection.The details of RTX_CSI algorithm are shown in Algorithm1.Algorithm 1:
RTX_CSI Algorithm.
Definition:
d
i: the  ith  path in the destination list of core node
d
list: the active destination list of core node
d
i
c
w
n
d: the cwnd value of the ith path
d
i
s
s
t
h: the ssthresh value of the ith path
d
i
tor: total timeouts on di in timeslot τ
d
interval: the tinterval of the ith path
d
r
t
x
Dest: the destination selected to retransmit loss data
Once having packet to resend
1:for each destination di  do//scan all paths’ condition
2:if status of di == ACTIVE then
3:  putdi into dlist;  //ignore the inactive paths
4:end if
5:end for
6: setdscwnd=dlist0cwnd,dtssth=dlist0ssth,dwinterval=dlist0interval;
7:for (i=1,i<=count(dlist),i++) do
//select the destination which has largestcwnd value in loop
8:if (dscwnd<dlist(i)cwnd) then
9:    sets=i;set dscwnd=dlisticwnd;
10:end if
//select the destination which has largestssthresh value in loop
11:if(dtssth<dlistissth) then
12:    sett=i;set dtssth=dlistissth;
13:end if
//select the destination which has lowesttor value in loop
14:if(dttor>dlistitor) then
15:    sett=i;set dttor=dlistitor;
16:end if
//select the destination which has largesttinterval value in loop
17:if(dwinterval<dlistiinterval) then
18:   setw=i;set dwinterval=dlistiinterval;
19:end if
20:end for
21:if !((dj∈dlist)&&(djcwnd == dscwnd)&&(j <> s)) then
//path with largest cwnd is set as retransmission destination
22:   setdrtxDest=ds;
23:else if !((dj∈dlist)&&(djssth == dtssth)&&(j <> t)) then
//path with largest ssthresh is set as retransmission destination
24:   setdrtxDest=dt; //
25:else if !((dj∈dlist)&&(djtor==dttor)&&(j <> t)) then
//path with lowest tor is set as retransmission destination
26:   setdrtxDest=dt;
27:else if !((dj∈dlist)&&(djinterval==dwinterval)&&(j <> w))
//path with largest tinterval is set as retransmission destination
28:   setdrtxDest=dw;
//a tie will be broken by random selection
29:else set drtxDest with random di (di∈dlist);
30:end if
let loss data be retransmitted ondrtxDest


### 4.3. Simulation Topology Setup

In this section, we adopt the average throughput as the metric in our experiments. Figure10 shows the simulation topology. Related simulation parameters are set the same as that mentioned in Section 3.Figure 10
Simulation topology for evaluatingRTX_CSI.We perform two experimental scenarios named Case1 and Case 2 are examined as follows to study the performance of RTX_CSI. In our experiments, the rbuf is set to 16 KB, 32 KB, 64 KB, 128 KB, and 256 KB, respectively, and τ is set to 30 s.Case 1.
The loss rate onTCP + UDP/VBR traffic path is always kept at 1%, and on TCP + UDP/CBRtraffic path, it is varied from 1% to 10%;Case 2.
The loss rate onTCP + UDP/VBR traffic path is varied from 1% to 10%, and on TCP + UDP/CBR traffic path, it is always kept at 1%.


### 4.4. Performance Evaluation

As mentioned above, according to RFC4460, only theRTX-CWND and RTX-SSTHRESH are recommended retransmission policy. So we compare the performance of RTX_CSI with the RTX-CWND and RTX-SSTHRESH.To compare conveniently, we use (2) illustrated below to express the advantage in terms of average throughput achieved by algorithm A (denoted as Aadv) over algorithm B. 								(2)Aadv=AaveTh-BaveThBaveTh×100%,
where AaveTh and BaveTh are on behalf of average throughput achieved by retransmission algorithm A and B, respectively.Firstly, we evaluate the performance ofRTX_CSI, RTX_CWND, and RTX_SSTHESH with experimental condition illustrated in Case 1; Figure 11 shows the performance of the three algorithms under different rbuf. We can get that the average throughput achieved by the RTX_CWND, RTX_SSTHRESH, and proposed RTX_CSI will rise with the increase of the rbuf. But when rbuf is set to more than 64 KB, the increments of average throughput are reduced whichever the three algorithms is employed. This phenomenon verifies again that the background traffic presents more serious side effects on performance of CMT-SCTP as larger rbuf is used. However, the RTX_CSI performs the best performance in the three algorithms, the RTX_CWND comes next, and the RTX_SSTHRESH presents the worst behavior.Figure 11
Path 1 loss rate is varied from 1–10%, Path 2 is always kept at 1%.For Case1, per calculated by (2), detailed comparison on the average throughput can be pointed out as follows.(1)
Comparing to the RTX_SSTHRESH, the RTX_CWND achieves a more advantage about −4.42%, 4.94%, 18.2%, 56.39%, and 55.15% whenrbuf is 16 KB, 32 KB, 64 KB, 128 KB, and 256 KB, respectively. So, it can be conculded that the RTX_CWND can also present better performance over the RTX_SSTHRESH [12] even under background traffic condition (Case 1).(2)
Comparing to the RTX_CWND, the proposed RTX_CSI achieves more benefits about 1.14%, 0.56%, and 1.62% when rbuf is set to 16 KB, 32 KB, and 64 KB, respectively. Since larger rbuf leads to less packet loss; therefore, when the rbuf is set to 128 KB and 256 KB, the proposed RTX_CSI presents same performance in terms of throughput as the RTX-CWND algorithm.Secondly, we compare the performance of theRTX_CWND and RTX_SSTHRESH with the proposed RTX_CSI under different rbuf with designed experimental scenario addressed in Case 2. As it shown in Figure 12, the average throughput achieved by the three algorithms will rise with the increase of rbuf. But with same reason mentioned in Case 1, when rbuf is set to more than 64 KB, the increments of average throughput are reduced whichever the three algorithms are employed. In this case, the RTX_CSI still performs the best performance. But different from conclusion addressed in [12] and Case 1, only if rbuf is larger than 64 KB, the RTX_CWND presents a better performance than the RTX_SSTHRESH.Figure 12
Path 2 loss rate is varied from 1–10%, Path 1 is always kept at 1%.Likewise, for Case2, detailed comparisons are pointed out per calculated by (2).(1)
Comparing to theRTX_SSTHRESH, the RTX_CWND achieves a more advantage about 7.26%, −0.15%, −8.02%, 12.05%, and 12.57% when rbuf is 16 KB, 32 KB, 64 KB, 128 KB, and 256 KB, respectively. The comparison results are different from the conclusion mentioned in [12], in our experiment (Case 2), comparing to the RTX_SSTHRESH, the RTX_CWDN only can achieve obvious more advantages in terms of average throughput when rbuf is set to the value which is larger than the default rbuf (64 KB). The reason may be that when enormous of variable bite rate packets are lost, their retransmissions not only deteriorate the path’s quality but also enlarge the unpredictability of path’s condition. Those unexpected conditions make the CMT-SCTP sender cannot tune its congestion window accurately. But when the rbuf is set to larger one (more than 64 KB), the sender can correct its congestion window since lots of packets can be received and acknowledged timely thus, the RTX_CWND can outperform the RTX_SSTHRESH. This phenomenon further verifies the proposed RTX_CSI more reasonable with considering the nature of background traffic. Our future work will investigate the reason in detail.(2)
Comparing to theRTX_CWND, the proposed RTX_CSI achieves more benefits about 0.47%, 0.57%, and 17.56% when rbuf is set to 16 KB, 32 KB, and 64 KB, respectively. As Case 1, when the rbuf is set to 128 KB and 256 KB, the proposed RTX_CSI presents same performance in terms of throughput as the RTX_CWND with the reason that larger rbuf leads to less packet loss.From experiments and analysis for Case1 and Case 2 respectively, we can conclude that the proposed RTX_CSI algorithm can achieve a better performance than the existing retransmission algorithm, especially for rbuf such as 16 KB, 32 KB, and 64 KB which are used commonly. The reason RTX_CSI can achieve a more advantage over the two existing retransmission algorithm is that the RTX_CSI can select a more efficient path as the retransmission destination with considering more reasonable rules such as paths’ cwnd, ssthresh value, and historical states to meet some known problems like congestion and packet loss caused by background traffic.


## 4.1. Existing Retransmission Algorithm

RTX-SAME. Once a new data chunk is scheduled and sent to a destination, all retransmissions of the chunk thereafter are sent to the same destination (until the destination is deemed inactive due to failure).RTX-ASAP. A retransmission of a data chunk is sent to any destination for which the sender has cwnd space available at the time the retransmission needs to be sent. If the sender has available cwnd space for multiple destinations, one is chosen randomly.RTX-LOSSRATE. A retransmission of a data chunk is sent to the destination with the lowest loss rate path. If multiple destinations have the same loss rate, one is selected randomly.RTX-CWND. A retransmission of a data chunk is sent to the destination for which the sender has the largest cwnd. A tie is broken randomly.RTX-SSTHRESH. A retransmission of a data chunk is sent to the destination for which the sender has the largest ssthresh. A tie is broken randomly.However, according to RFC4460, only theRTX-CWND and RTX-SSTHRESH are recommended retransmission policies, and the others are just for experimental sake. Moreover, the RTX-CWND is recommended as the default retransmission strategy since it can present the best performance [12].


## 4.2.RTX_CSI Description

As mentioned in Section1, all of existing retransmission algorithms do not take the impact of background traffic into account. To fix this issue, we consider the localness nature of background flow [19], that is, coming packets will belong to the flow as previously arrived ones in a short period. Correspondingly, the side effect on CMT-SCTP caused by background flow will be the same in short period. As countermeasure of the localness nature of background traffic, paths’ previous states should be considered during designing of retransmission algorithm. Therefore, we take paths’ previous states into account to design an improved retransmission algorithm named RTX_CSI which consists of four more reasonable paths’ conditions during selecting retransmission destination. RTX_CSI follows the below steps to select candidate path for data retransmission.(1)
A retransmission is sent to the destination that has the largestcwnd;(2)
if more than one destination has the largestcwnd, then a retransmission is sent to the one that has the largest ssthresh value;(3)
if there are more than one destination has the largestssthresh value, then a retransmission is sent to the one that has the lowest Time Out Records (tor) in specified time span (denoted asτ);(4)
if more than one destination has lowest timeout records in specified timeslot, then a retransmission is sent to the one that has the largest intervaltinterval (tinterval stands for the interval between the last timeout’s time and current time);(5)
if multiple destinations have the largesttinterval, then a tie will be broken by random selection.The details of RTX_CSI algorithm are shown in Algorithm1.Algorithm 1:
RTX_CSI Algorithm.
Definition:
d
i: the  ith  path in the destination list of core node
d
list: the active destination list of core node
d
i
c
w
n
d: the cwnd value of the ith path
d
i
s
s
t
h: the ssthresh value of the ith path
d
i
tor: total timeouts on di in timeslot τ
d
interval: the tinterval of the ith path
d
r
t
x
Dest: the destination selected to retransmit loss data
Once having packet to resend
1:for each destination di  do//scan all paths’ condition
2:if status of di == ACTIVE then
3:  putdi into dlist;  //ignore the inactive paths
4:end if
5:end for
6: setdscwnd=dlist0cwnd,dtssth=dlist0ssth,dwinterval=dlist0interval;
7:for (i=1,i<=count(dlist),i++) do
//select the destination which has largestcwnd value in loop
8:if (dscwnd<dlist(i)cwnd) then
9:    sets=i;set dscwnd=dlisticwnd;
10:end if
//select the destination which has largestssthresh value in loop
11:if(dtssth<dlistissth) then
12:    sett=i;set dtssth=dlistissth;
13:end if
//select the destination which has lowesttor value in loop
14:if(dttor>dlistitor) then
15:    sett=i;set dttor=dlistitor;
16:end if
//select the destination which has largesttinterval value in loop
17:if(dwinterval<dlistiinterval) then
18:   setw=i;set dwinterval=dlistiinterval;
19:end if
20:end for
21:if !((dj∈dlist)&&(djcwnd == dscwnd)&&(j <> s)) then
//path with largest cwnd is set as retransmission destination
22:   setdrtxDest=ds;
23:else if !((dj∈dlist)&&(djssth == dtssth)&&(j <> t)) then
//path with largest ssthresh is set as retransmission destination
24:   setdrtxDest=dt; //
25:else if !((dj∈dlist)&&(djtor==dttor)&&(j <> t)) then
//path with lowest tor is set as retransmission destination
26:   setdrtxDest=dt;
27:else if !((dj∈dlist)&&(djinterval==dwinterval)&&(j <> w))
//path with largest tinterval is set as retransmission destination
28:   setdrtxDest=dw;
//a tie will be broken by random selection
29:else set drtxDest with random di (di∈dlist);
30:end if
let loss data be retransmitted ondrtxDest


## 4.3. Simulation Topology Setup

In this section, we adopt the average throughput as the metric in our experiments. Figure10 shows the simulation topology. Related simulation parameters are set the same as that mentioned in Section 3.Figure 10
Simulation topology for evaluatingRTX_CSI.We perform two experimental scenarios named Case1 and Case 2 are examined as follows to study the performance of RTX_CSI. In our experiments, the rbuf is set to 16 KB, 32 KB, 64 KB, 128 KB, and 256 KB, respectively, and τ is set to 30 s.Case 1.
The loss rate onTCP + UDP/VBR traffic path is always kept at 1%, and on TCP + UDP/CBRtraffic path, it is varied from 1% to 10%;Case 2.
The loss rate onTCP + UDP/VBR traffic path is varied from 1% to 10%, and on TCP + UDP/CBR traffic path, it is always kept at 1%.


## 4.4. Performance Evaluation

As mentioned above, according to RFC4460, only theRTX-CWND and RTX-SSTHRESH are recommended retransmission policy. So we compare the performance of RTX_CSI with the RTX-CWND and RTX-SSTHRESH.To compare conveniently, we use (2) illustrated below to express the advantage in terms of average throughput achieved by algorithm A (denoted as Aadv) over algorithm B. 								(2)Aadv=AaveTh-BaveThBaveTh×100%,
where AaveTh and BaveTh are on behalf of average throughput achieved by retransmission algorithm A and B, respectively.Firstly, we evaluate the performance ofRTX_CSI, RTX_CWND, and RTX_SSTHESH with experimental condition illustrated in Case 1; Figure 11 shows the performance of the three algorithms under different rbuf. We can get that the average throughput achieved by the RTX_CWND, RTX_SSTHRESH, and proposed RTX_CSI will rise with the increase of the rbuf. But when rbuf is set to more than 64 KB, the increments of average throughput are reduced whichever the three algorithms is employed. This phenomenon verifies again that the background traffic presents more serious side effects on performance of CMT-SCTP as larger rbuf is used. However, the RTX_CSI performs the best performance in the three algorithms, the RTX_CWND comes next, and the RTX_SSTHRESH presents the worst behavior.Figure 11
Path 1 loss rate is varied from 1–10%, Path 2 is always kept at 1%.For Case1, per calculated by (2), detailed comparison on the average throughput can be pointed out as follows.(1)
Comparing to the RTX_SSTHRESH, the RTX_CWND achieves a more advantage about −4.42%, 4.94%, 18.2%, 56.39%, and 55.15% whenrbuf is 16 KB, 32 KB, 64 KB, 128 KB, and 256 KB, respectively. So, it can be conculded that the RTX_CWND can also present better performance over the RTX_SSTHRESH [12] even under background traffic condition (Case 1).(2)
Comparing to the RTX_CWND, the proposed RTX_CSI achieves more benefits about 1.14%, 0.56%, and 1.62% when rbuf is set to 16 KB, 32 KB, and 64 KB, respectively. Since larger rbuf leads to less packet loss; therefore, when the rbuf is set to 128 KB and 256 KB, the proposed RTX_CSI presents same performance in terms of throughput as the RTX-CWND algorithm.Secondly, we compare the performance of theRTX_CWND and RTX_SSTHRESH with the proposed RTX_CSI under different rbuf with designed experimental scenario addressed in Case 2. As it shown in Figure 12, the average throughput achieved by the three algorithms will rise with the increase of rbuf. But with same reason mentioned in Case 1, when rbuf is set to more than 64 KB, the increments of average throughput are reduced whichever the three algorithms are employed. In this case, the RTX_CSI still performs the best performance. But different from conclusion addressed in [12] and Case 1, only if rbuf is larger than 64 KB, the RTX_CWND presents a better performance than the RTX_SSTHRESH.Figure 12
Path 2 loss rate is varied from 1–10%, Path 1 is always kept at 1%.Likewise, for Case2, detailed comparisons are pointed out per calculated by (2).(1)
Comparing to theRTX_SSTHRESH, the RTX_CWND achieves a more advantage about 7.26%, −0.15%, −8.02%, 12.05%, and 12.57% when rbuf is 16 KB, 32 KB, 64 KB, 128 KB, and 256 KB, respectively. The comparison results are different from the conclusion mentioned in [12], in our experiment (Case 2), comparing to the RTX_SSTHRESH, the RTX_CWDN only can achieve obvious more advantages in terms of average throughput when rbuf is set to the value which is larger than the default rbuf (64 KB). The reason may be that when enormous of variable bite rate packets are lost, their retransmissions not only deteriorate the path’s quality but also enlarge the unpredictability of path’s condition. Those unexpected conditions make the CMT-SCTP sender cannot tune its congestion window accurately. But when the rbuf is set to larger one (more than 64 KB), the sender can correct its congestion window since lots of packets can be received and acknowledged timely thus, the RTX_CWND can outperform the RTX_SSTHRESH. This phenomenon further verifies the proposed RTX_CSI more reasonable with considering the nature of background traffic. Our future work will investigate the reason in detail.(2)
Comparing to theRTX_CWND, the proposed RTX_CSI achieves more benefits about 0.47%, 0.57%, and 17.56% when rbuf is set to 16 KB, 32 KB, and 64 KB, respectively. As Case 1, when the rbuf is set to 128 KB and 256 KB, the proposed RTX_CSI presents same performance in terms of throughput as the RTX_CWND with the reason that larger rbuf leads to less packet loss.From experiments and analysis for Case1 and Case 2 respectively, we can conclude that the proposed RTX_CSI algorithm can achieve a better performance than the existing retransmission algorithm, especially for rbuf such as 16 KB, 32 KB, and 64 KB which are used commonly. The reason RTX_CSI can achieve a more advantage over the two existing retransmission algorithm is that the RTX_CSI can select a more efficient path as the retransmission destination with considering more reasonable rules such as paths’ cwnd, ssthresh value, and historical states to meet some known problems like congestion and packet loss caused by background traffic.


## 5. Conclusions

In this paper, we designed realistic simulation topologies and examined the performance of CMT-SCTP in terms of throughput, end-to-to packet delay by considering reasonable background traffic. We discussedhow the presence of background traffic affects the performance of CMT-SCTP in detail, which are generally ignored by most current researchers.Based on above work, we proposed an improved retransmission algorithm calledRTX_CSIfor CMT-SCTP. RTX_CSItakes background traffic into account and considers paths’ comprehensive characteristics during selecting retransmission destination to meet the localness nature of background traffic. The simulation results show RTX_CSI achieves better efficiency than CMT-SCTP’s original retransmission algorithm. So the proposed RTX_CSI can be employed to improve the users’ experience of quality for multimedia streaming service when CMT-SCTP is used for the multimedia transport protocol.



---

*Source: 789579-2012-08-13.xml*