- Email: [email protected]
A multipath variant of SCTP with optimized flow division extension
ARTICLE IN PRESS
JID: COMCOM
[m5G;July 3, 2015;22:10]
Computer Communications 000 (2015) 1–10
Contents lists available at ScienceDirect
Computer Communications journal homepage: www.elsevier.com/locate/comcom
A multipath variant of SCTP with optimized flow division extension Samar Shailendra a,∗, R. Bhattacharjee b, Sanjay K. Bose b a b
CTO Networks Lab, Bangalore, India Department of Electronics & Electrical Engineering, I.I.T. Guwahati, Guwahati, India
a r t i c l e
i n f o
Article history: Received 26 September 2014 Revised 20 April 2015 Accepted 12 June 2015 Available online xxx Keywords: Stream control transmission protocol Multipath stream control transmission protocol Flow division at source Transport protocol
a b s t r a c t In the literature, Multipath Stream Control Transmission Protocol (MPSCTP) has been proposed as a multipath variant of Stream Control Transmission Protocol (SCTP). Unlike SCTP, MPSCTP uses the multiple available paths between the source and the destination in concurrent fashion using the multihoming feature of SCTP. MPSCTP in its original form implicitly assumes no acknowledgment loss. In this work, a modified algorithm for MPSCTP is proposed to mitigate this limitation and its performance is compared with Concurrent Multipath Transfer (CMT) using ns2 based simulation. A new path selection strategy for data transmission is incorporated and its results are compared with the RTX-CWND strategy proposed in the literature. This paper also presents a heuristic to implement delay insensitive optimization. The performance of this optimization for MPSCTP has been studied using ns2 based simulations. We have also presented the performance results of MPSCTP implementation in the Linux Kernel. © 2015 Elsevier B.V. All rights reserved.
1. Introduction In the recent past, there has been significant increase in the demand for high data rate and better quality of service for various types of multimedia traffic. These requirements have created tremendous pressure on the service providers to achieve better network utilization and provide better QoS to the end user. These requirements triggered various research activities to look for better throughput, resource utilization, and error resilience. As part of this effort, IETF standardized the Stream Control Transmission Protocol (SCTP) in 2001. SCTP [1–4] added features like multistreaming, multihoming and a cookie-based mechanism with 4-way handshake to mitigate various denial of service attacks [5]. SCTP’s multistreaming feature helps in reducing the head of line blocking that may occur in TCP [6,7] where a packet is not passed to the upper layer until all packets with smaller sequence number have been received. However, in certain scenarios, it may be acceptable if some part of the data is delivered out of sequence. For example, let us consider a scenario when a user is browsing a website which contains both images and normal text. We can send the images and normal text using two different streams so that even if the packets of the stream with the images are lost, the text can still be rendered for the user and vice versa.
∗
Corresponding author. Tel.: +91 9886227956. E-mail address: [email protected] (S. Shailendra).
SCTP’s multihoming feature may be useful when the end hosts have more than one IP address. Unlike TCP, an SCTP association is created using a combination of the host’s multiple IP addresses and one port. Using SCTP’s multihoming feature, all the IP addresses can participate in sending and receiving of data. SCTP assumes one of the paths as the primary path and uses it for data transmission. In the event of primary path degradation or data loss, SCTP may choose any of the alternative paths to transmit data. This provides better error resilience in case of network outages. Several issues related to SCTP multihoming are discussed in [8]. SCTP’s multihoming feature is extended to design multipath variants [9–11] which can use all the available paths to transfer data in a concurrent fashion. We had earlier proposed Multipath SCTP (MPSCTP) as a multipath variant of SCTP that uses all available candidate disjoint paths concurrently. In the literature, CMT has been proposed that also uses all the candidate paths concurrently. However, unlike CMT which uses only one sequence number, MPSCTP uses two levels of sequence numbering. This reduces the complexity of the algorithms significantly and makes MPSCTP more scalable than the CMT protocol. However, in its original form, MPSCTP [9] implicitly assumes that there is no acknowledgment loss in the network. Such an assumption may restrict the scope of usage of MPSCTP in high loss networks and wireless scenarios. The implementation of MPSCTP requires several other issues to be considered. A basic requirement for such multipath protocols is to properly divide a data stream on multiple candidate paths. The flow on the candidate paths will depend on the characteristics of the paths, which will in turn depend upon the performance of each link and
http://dx.doi.org/10.1016/j.comcom.2015.06.005 0140-3664/© 2015 Elsevier B.V. All rights reserved.
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
ARTICLE IN PRESS
JID: COMCOM 2
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
Type = 3
Chunk Flags
Chunk Length
Cumulative TSN Ack Cumulative PSN Ack Advertised Receiver Window Number of Duplicate PSN (X)
Number of Gap Ack Blocks (N)
Gap Ack Block #1 End
Gap Ack Block #1 Start ..... Gap Ack Block #N Start
Gap Ack Block #N End Duplicate PSN #1 ..... Duplicate PSN #X Fig. 1. SACK Structure for MPSCTP.
node on the path being considered. Several optimization techniques such as Delay Insensitive Optimization (DIO) have been proposed for this in the literature [12]. However, these techniques typically require the complete path statistics to be known at the source. It is somewhat difficult to obtain such statistics in an Internet like scenario. In this paper, we present the performance evaluation of the modified MPSCTP algorithm using ns2 based simulations. We have proposed Tx-CWND, a novel path selection policy for MPSCTP, and have compared its performance with RTX-CWND [11,13]. We also present here a heuristic to implement DIO in MPSCTP to divide the data on multiple available paths. Finally, we have implemented MPSCTP in the Linux Kernel and have presented its performance results. The rest of the paper is organized as follows. Section 2 presents the modified fast retransmission algorithm and looks at its performance. In Section 3 we present a heuristic for path selection policy. In Sections 4 and 5, a heuristic for delay insensitive optimization and its performance has been presented. Section 6 presents the MPSCTP performance in the Linux Kernel followed by the conclusion in Section 7. 2. Modified fast retransmission algorithm and its performance analysis Though, it was proposed with a multihoming feature, SCTP in its original form does not use multiple candidate paths concurrently. However, SCTP can be extended to divide data on multiple available paths in a parallel fashion. This division is expected to improve the overall throughput of the network. This multipath usage also provides better error resilience from path failure and path degradation and leads to better utilization of the overall network resources. However, such flow division causes certain side effects as well. The first one is that the flow division at source gives rise to false holes in the sequence numbers received at the destination. These false holes cause unnecessary fast retransmissions from the sender side because the receiver interprets these false holes as loss of packets and does not implement delayed acknowledgment. Due to gap indications in the acknowledgment, the congestion window is also not updated regularly. This generates bursty growth in the congestion window value. To overcome these side effects of multipath usage, we had earlier proposed MPSCTP [9] as a multipath extension of SCTP. The primary issue in MPSCTP is to distinguish the path sequence numbers from the data sequencing required by the upper layer. For this purpose, MPSCTP uses two levels of sequence numbers. One is
the Transmission Sequence Number (TSN). This is a single sequence space across all the candidate paths. The other one is the Path Sequence Number (PSN). PSNs are sequence numbers specific to individual paths and are monotonically increasing numbers. These are used to isolate the reordering due to multipath from the chunk loss on each path. Because PSNs are monotonically increasing, a packet lost on one path can be retransmitted on any alternate available path as well. MPSCTP also assumes that acknowledgments are retransmitted back on the same path over which the data was transmitted. This ensures that the RTT values are calculated properly for each path. The introduction of PSNs can take care of the false holes that arise in the packet sequence due to reordering of packets on multiple paths. Since, the acknowledgments are sent back based on the PSN values, this also obviates the problem of increased acknowledgment traffic due to holes in the packet sequence. Moreover, due to the PSNs, the MPSCTP receiver can clearly distinguish between chunk loss, sender induced reordering, and also does not require the Delayed Acknowledgment for CMT (DAC) algorithm and RTT heuristics as being used by CMT. However, this requires several changes in the chunk header and the SACK structure to accommodate the details related to the PSN values as presented in [9]. 2.1. Handling SACK losses MPSCTP in its original form implicitly assumes that there is no SACK loss on the reverse path. The SACKs have smaller probability of error in comparison to data packets. However, the assumption of no SACK loss on the reverse path limits the usage of MPSCTP on paths with high losses. To avoid this limitation of the protocol, we have earlier proposed a change in the SACK structure and the fast retransmission algorithm [14]. In this paper, we investigate the performance of MPSCTP with CMT for different retransmission strategies. The change in SACK structure and the algorithm are presented in Figs. 1 and 2, respectively. As shown in Fig. 1, we have added the cumulative TSN Acknowledgment (cumTSNAck) along with the cumulative PSN Acknowledgment (cumPSNAck) in the SACK structure. The cumTSNAck indicates the largest TSN received at the destination among all the paths. The sender removes a particular TSN from its send buffer if and only if the cumTSNAck value is greater than TSN itself. If a timeout happens for a particular PSN on that path, then the corresponding PSN is retransmitted (Fig. 2).
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
ARTICLE IN PRESS
JID: COMCOM
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
For every SACK received (at sender side): if (SACK contains GAP reports), For each destination (di ): For each TSN Ta , set count Ca = 0; if (TSN for di .PSN == Ta ), Ca ++ ; if (Ca ≥ 3), Initiate Fast Transmit; if (CumTSNAck ≥ TSN in send buffer), Do not remove from SendBuffer; For each destination (di ): if(timeout for di .PSN) Initiate Fast Transmit; Fig. 2. Modified fast retransmission algorithm for handling gap reports in MPSCTP.
2.2. Performance analysis In this section, we have compared the performance of the modified fast retransmission algorithm for MPSCTP with the CMT [11] algorithm for different retransmission strategies. In [11], the authors have also proposed several strategies for data retransmission. In this work, we have compared the performance of MPSCTP with CMT for two different retransmission strategies, namely RTX-SAME and RTXCWND. In the event of data loss, RTX-SAME strategy uses the same path for the retransmission of the packet, while RTX-CWND chooses the path with the largest congestion window. To compare the performance of this modified MPSCTP, we have considered an example with simple dual homed source and destination nodes with two disjoint paths between them. The bandwidth of both the paths is assumed to be 2 Mbps and the propagation delay for the two paths is 50 ms. Path-1 has a fixed packet loss probability of 1% but the probability of packet loss on path-2 is varied from 1% to 10%. However, both paths have been assumed to have a probability of acknowledgment loss of 1%. For our tests, we assume an ftp application transferring a 60 MB file using both MPSCTP and CMT with varying packet loss probabilities for path-2. Though, the above topology is relatively simple, it effectively models the network as seen by the transport layer between the end-hosts.
550
Fig. 3 shows the average file transmission times for the file using CMT and the modified MPSCTP. The results also show the 95% confidence interval for the average file transmission time. To obtain the above confidence interval, we have used 11 different runs and for each run different seed values are being used for the probability of packet error as well as the probability of SACK Error. We have compared the results for two different retransmission strategies. We have considered RTX-SAME and RTX-CWND strategies for our comparison. We notice that the modified MPSCTP with RTX-CWND strategy performs significantly better than CMT with RTX-CWND. However, MPSCTP with RTX-SAME strategy performs only marginally better than CMT with RTX-SAME strategy as this modification in the fast retransmission algorithm makes MPSCTP relatively more sensitive to acknowledgment losses than CMT. It may be noted that unlike the Delayed Acknowledgment algorithm in MPSCTP, the DAC algorithm always delays the SACK transmission. However, in the event of an actual SACK loss, this has an undesirable effect because it then delays the recovery of lost chunks due to delay in the SACK and thereby increases the overall file transmission time. 3. Tx-CWND path selection policy In this section, we propose Tx-CWND, a novel policy for path selection in MPSCTP. In [13], the authors have proposed several retransmission strategies. RTX-CWND was demonstrated to perform the best among them. However, retransmitting packets other than on its original path requires higher processing at the sender side. To reduce this increased processing, we propose the new Tx-CWND path selection policy. Tx-CWND is a path selection policy, which selects the path based on the congestion window and uses the same retransmission policy as RTX-SAME. In Tx-CWND, we always transmit the packet on the path with the largest congestion window. However, we do not change the path for retransmission and the packet is retransmitted on the same path as the one on which it was originally transmitted unless the path is marked inactive due to failure. In case of path failure the path with the current largest congestion window is selected for retransmission. The Tx-CWND strategy reduces the book-keeping as well as the processing required for retransmission path selection. Hence, it is simpler to implement this strategy in the Linux Kernel. It must be noted that Tx-CWND is a path selection policy and currently uses RTX-SAME as the retransmission policy. It is possible to
CMT RTX-SAME MPSCTP RTX-SAME CMT RTX-CWND MPSCTP RTX-CWND
500 Average File Transmission Time(Sec)
3
450 400 350 300 250 200 150 0.01
0.02
0.03
0.04
0.05 0.06 0.07 Probability of Error
0.08
0.09
0.1
0.11
Fig. 3. Average file transmission time for CMT and MPSCTP with RTX-SAME and RTX-CWND retransmission strategies.
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
ARTICLE IN PRESS
JID: COMCOM 4
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
Path−1
2 Mbps, 50 ms N3
N1 10 Mbps, 50 ms
10 Mbps, 50 ms
Source
Destination 10 Mbps, 50 ms
10 Mbps, 50 ms
2 Mbps, 50 ms N2
N4
Path−2 Fig. 4. Network layout.
incorporate any other retransimission policy as well, if so desired, including RTX-CWND though the latter may make the implementation much more difficult and increase the processing required. We compare the performance of Tx-CWND and RTX-CWND using ns2 based simulations for the network scenario shown in Fig. 4. The packet error probability of path-1 has been fixed at 1% while that of path-2 is varied from 1% to 10%. The bandwidths of both the paths are as shown in Fig. 4. The source (S) runs an ftp application to transmit a 60 MB file to the destination. The average time to transmit this file is shown in Fig. 5. The results are presented for both the RTX-CWND and Tx-CWND strategies. As discussed earlier Tx-CWND, a path selection policy, does the path selection during initial transmission of a packet. It selects the path based upon the current cwnd size. As mentioned earlier, Tx-CWND does not perform any path selection during retransmission(unless the path is marked inactive due to failure) and retransmits the packet on the same path as that of the original transmission. On the other hand, RTX-CWND is a retransmission policy. With RTX-CWND, the sender transmits a full cwnd number of packets on a path before starting transmission on another path. RTX-CWND selects the path during retransmission based upon the cwnd size. We observe in Fig. 5 that for smaller probabilities of error, average file transmission time for Tx-CWND strategy is more than that for the RTX-CWND strategy. This is because, when the probability of error is low, Tx-CWND experiences much more packet reordering than the RTX-CWND strategy as RTX-CWND keeps transmitting data on a path until its cwnd is completely exhausted while Tx-CWND transmits a packet on the path with the higher congestion window (i.e. more network resources). Since, cwnd is inversely proportional to the probability of error, the Tx-CWND strategy results in more packets being transmitted on paths with lower probabilities of error. This leads to relatively better performance when the probability of error is high. This can be seen in the normalized file transfer time results shown in Fig. 6. Here, the file transfer times are normalized with respect to the file transfer time when the probability of error is zero. We notice that at higher probability of error RTX-CWND has higher normalized transfer time than the Tx-CWND strategy. This indicates that the performance of RTX-CWND degrades much more rapidly than the Tx-CWND strategy as the probability of error increases. This makes Tx-CWND a better choice for channels with higher probability of error and for devices with limited processing power.
4. Heuristic for delay insensitive optimization algorithm The implementation of MPSCTP requires the flow to be divided on multiple candidate paths in an optimal way. The optimal division on candidate paths will depend not only upon the network parameters but will also depend upon the nature of the application supported on this network. Several optimizations are proposed in the literature to divide the data on multiple paths in parallel [12]. Let us consider a general network G(V,E) where V is set of nodes and E is the set of directional links. This network consists of N disjoint paths with the ith path consisting of Li nodes where i is indexed from 1 to N. Let wi be the mean total delay of the ith path. If λi is the arriving flow at the ith path, Delay Insensitive Optimization (DIO) ensures that the delay of any of the candidate paths does not exceed the target delay (Ti ). Hence, this parameter can be considered as a QoS parameter for the network. This parameter will typically depend upon the nature of application [12] and the range for this parameter may be known apriori for a given application [12]. The implementation of DIO will also require that the Ti information is available at the transport layer. This information can be provided by the underlying application through function calls between the application and the transport layers. maximize: N
λi
(1)
i=1
subject to:
wi ≤ Ti
λi ≥ 0
∀i = 1, 2, . . . , N
(2) (3)
where, Ti is the agreed upon end-to-end target delay for ith path. True implementation of DIO will require complete network statistics to be known at the source in order to calculate total delay. Moreover, solving the optimization problem for every change of the parameters is time consuming as well as computationally infeasible in most systems. Hence, in this section we propose a heuristic which closely approximates the above optimization. The basic requirement to implement DIO is that no packet should experience an end-to-end delay on any path which is more than the
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
ARTICLE IN PRESS
JID: COMCOM
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
280
5
RTX-CWND Tx-CWND
Average File Transmission Time
260 240 220 200 180 160 140 120 0
0.02
0.04
0.06
0.08
0.1
Probability of Error Fig. 5. Average file transmission time for Tx-CWND and RTX-CWND.
Normalized Average File Transmission Time
2
RTX-CWND Tx-CWND
1.9 1.8 1.7 1.6 1.5 1.4 1.3 1.2 1.1 1 0
0.02
0.04
0.06
0.08
0.1
Probability of Error Fig. 6. Normalized average file transmission time for Tx-CWND and RTX-CWND.
target delay (Ti ). The end-to-end delay on each path is also a function of the flow sent on that path. Hence, it is possible to adjust the end-toend delay experienced by any packet on a path by adjusting the flow on that path. The flow on any path should be adjusted such that the end-to-end delay experienced by a packet should not go beyond the agreed target delay (Ti ). Since path properties are dynamic in nature, an exact analysis of the flow to be carried on a path would be a costly operation both in terms of time and the resources required. Hence, we use the round trip time (RTT) measurement for the end-to-end delay calculations. It has also been demonstrated in earlier work that RTT measurements in Internet scenario are good approximations and give results which are close to those obtained using auto regressive models [15]. In a typical MPSCTP scenario, the congestion window is used to control the amount of data in the network in a single RTT. At any point of time, any path cannot have more than cwnd bytes outstanding on it. According to the modified congestion control for MPSCTP,
the cwnd is increased on every SACK received. As the flow on a path is increased, the delay encountered by a packet on that path also increases. Therefore, a change in cwnd based on the RTT measurements can be used to adjust the delay experienced by a packet in the network. A simple modification in the congestion control algorithm is observed to take care of the delay experienced by any packet on the network (Fig. 7). According to this algorithm, when the RTT approaches with-in a limit of the target delay, it does not increase the cwnd anymore. The network delay depends upon the several other activities in the network, and if the delay exceeds the RTT beyond a certain value of the target delay, the algorithm enters into congestion detection phase and reduces the congestion window to adjust the flow on the network. However, it does not perform another adjustment unless at least cwnd bytes are not received since the last adjustment. This is because cwnd value indicates the currently outstanding bytes on the network and hence it will take at least cwnd bytes to be received
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
ARTICLE IN PRESS
JID: COMCOM 6
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
This algorithm requires a penalty to be paid in terms of the loss of throughput for the application. However, we argue that this algorithm helps in improving the throughput of other fellow flows on the network because if the network is not able to provide the agreed delay performance, the algorithm will not increase the flow on that path. This gives an opportunity to other flows to use the network resources and hence helps in running the network in a fairer fashion. For this network, we measure the Fairness index using the Jain formula as given in [16]. We also measure the Link utilization for the shared bottleneck link in the network as
if (RTTi <(1-q) ∗ 2 ∗ Ti ) if (cwnd ssthresh) Apply Congestion Avoidance. if (at least cwnd bytes are received since last cwnd adjustment) if (RTTi > (1-q) ∗ 2 ∗ Ti && RTTi ≤ (1+q) ∗ 2 ∗ Ti ) Do Not Increase cwnd. if (cwnd > (1+q) ∗ 2 ∗ Ti ) Decrease cwnd as per congestion detection algorithm. Fig. 7. Algorithm for delay insensitive optimization.
n
before the effect of the adjustment is visible. The upper and the lower bounds of this limit are decided by the value of bounding factor (q). This bounding factor depends on the variance of the delay over the network i.e. its value is decided by how much maximum delay jitter exists in the network. In this paper, we have assumed q to be 0.1. That indicates that the maximum delay jitter in the network is not more than the 10% of the target delay. In networks with different delay jitters, the value of q can be chosen accordingly.
i=1
10 Mbps, 50 ms
N3
D1
U11
U1 Sources U2
Source
10 Mbps, 50 ms
T 11
T1
S
(4)
Bottleneck link bandwidth
where λi is the throughput of ith flow entering on the bottleneck link, and ‘n’ is the total number of flows entering the bottleneck link. The purpose of this parameter is to measure the utilization of the bottleneck link. These two factors jointly indicate both the reliability and the fairness of the proposed algorithm. By observing these two parameters (i.e. fairness index and link utilization) together, we
0.5 Mbps, 50 ms
N1
S1
Link utilization =
λ
Destinations T22
T2
S2
D Destination
U22
10 Mbps, 50 ms
D2 10 Mbps, 50 ms
0.5 Mbps, 50 ms
N2
N4
Fig. 8. Network graph for delay insensitive optimization.
350
Average throughput for MPSCTP
Average Throughput (Kpbs)
300 250 200 150 100 50 0 160
180
200 220 240 260 Target delay (T i) in milliseconds
280
300
Fig. 9. Average throughput for MPSCTP for various target delays.
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
ARTICLE IN PRESS
JID: COMCOM
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
demonstrate that though the optimization reduces the throughput of the source to satisfy the QoS constraint and increases the relative unfairness, it gives other fellow flows an opportunity to transmit more data and the overall network’s resource utilization would still not decrease by much.
7
Table 1 Fairness index and Link utilization for link N1 − N3 .
With optimization Without optimization
Fairness index
Link utilization
% Packet delayed
210 ms
270 ms
210 ms
270 ms
210 ms
270 ms
0.9787 0.9893
0.9802 0.9892
0.9359 0.9361
0.9357 0.9364
46.79 81.31
27.79 80.54
5. Performance study of MPSCTP with DIO Let us consider a network as shown in Fig. 8. The network consists of two UDP sources (U1 & U2 ), two TCP sources (T1 & T2 ), and one dual homed source (S) with an MPSCTP agent attached to it. There are ftp sources attached at T1 , T2 and S while U1 and U2 have CBR sources attached to them. All the links are assumed to have packet loss probability of 10%. For some of the links the bandwidths have been explicitly shown in Fig. 8; all the other links have bandwidth of 2 Mpbs each and propagation delay of 50 ms. We have measured the average throughput achieved by the MPSCTP source for various target delay (Ti ) and the results are presented in Fig. 9. The results indicate that when the target delay is less than or equal to 160 ms, no data can be carried on the network because the minimum round trip delay of a path in the network is 300 ms. Once the target delay increases beyond 260 ms, there is no significant increase in the throughput because there are other queuing and processing delays in the network and congestion window does not allow data to be carried on the network. Beyond 180 ms, we notice a continual increase in the data carried on the network with the increase in the target delay. However, beyond 260 ms the throughput does not increase further because it then gets limited by the other sources present in the network and is also limited by its own congestion window. Hence, this parameter can be used as a QoS parameter to provide the agreed quality of service to the users. Figs. 10 and 11 present the packet delay variation with the delay sensitive optimization and without the optimization. These results are plotted for the target delay of 210 ms and 270 ms, respectively. The results show that with delay optimization, the variance of delay of the packets as well as the maximum delay experienced in the network is reduced. However, this algorithm requires a penalty to be paid in terms of the loss of throughput for the application. However, as already mentioned, we argue that this algorithm helps in improving the throughput of the other fellow flows on the network because if the network is not able to provide the agreed delay performance,
Packet Delay (milliseconds)
4000
6. MPSCTP implementation in Linux Kernel We have implemented MPSCTP protocol in the Linux Kernel to demonstrate a feasible implementation of the protocol and measure its performance in a real network. Currently, the Linux Kernel supports SCTP as a loadable module. However, this module has no support for concurrent multipath usage for multihomed end-hosts. We
With Optimization
3000 2000 1000 4000 0
Packet Delay (milliseconds)
the algorithm will not increase the flow on that path. This gives an opportunity to other flows to use the network resources and hence helps in running the network in a fairer fashion as can be observed in Table 1. We notice in Table 1 that there is a decrease in the Fairness index for target delays of 210 ms and 270 ms because the optimization reduces the data to be carried on the links. However, there is no significant effect on link utilization; this indicates that other fellow flows are able to carry more data on that link. However, this behavior is useful to provide the end users a better quality of service and also allows other fellow flows to transmit their data on this link without compromising the resource utilization. Table 1 also shows the percentage of packets which do not comply with the target delay. It may be noted that there is a significant reduction in this percentage when the proposed optimization is used. As expected, significantly fewer packets will encounter delays more than the target delay. This indicates that this algorithm is able to provide better QoS to the end user without affecting much the overall resource utilization. For this optimization to be effective in a larger network, statistically more number of flows must be implementing the DIO algorithm. However, since DIO does not adversely affect any of the existing flows, it would be able to provide a viable migration path from current design approaches to the proposed DIO based approach. It may also be noted that DIO is a generic algorithm which can also be adapted to other multipath protocols such as Multipath TCP [17].
Without Optimization
3000 2000 1000 0 0
50
100
150
200 250 300 Time (seconds)
350
400
450
500
Fig. 10. End-to-end packet delay for the target delay of 210 ms.
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
ARTICLE IN PRESS
JID: COMCOM 8
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
Packet Delay (milliseconds)
4000
With Optimization
3000 2000 1000
Packet Delay (milliseconds)
4000 0
Without Optimization
3000 2000 1000 0 0
50
100
150
200 250 300 Time (seconds)
350
400
450
500
Fig. 11. End-to-end packet delay for the target delay of 270 ms.
Fig. 12. Network diagram for MPSCTP implementation in Linux Kernel.
have modified the SCTP module to incorporate concurrent multipath usage. This implementation is tested in an emulated network using dummynet. We have considered two dual homed machines PC1 and PC2 connected as shown in Fig. 12. The interfaces of these machines are connected through two CISCO switches to create two disjoint paths between the source and the destination. The delay and loss rate of each path is controlled using dummynet. The delay for each path between the two machines is set to 50 ms. The packet drop probability of one path is fixed at 1% while the packet drop probability on the other path is varied from 1% to 10%. The bandwidth of the two paths is also controlled using dummynet and each of them is set to 2 Mbps (Fig. 12). We transmit a 60 MB file using MPSCTP. The path selection policy used by MPSCTP is Tx-CWND with retransmissions made on the same path as the original path of transmission. We use a receiver buffer of 64 KB, as this is the most commonly used value in most practical scenarios.
1.9
Dummynet NS-2
Normalized File Transmission Time
1.8 1.7 1.6 1.5 1.4 1.3 1.2 1.1 1 0
0.02
0.04 0.06 Probability of Error
0.08
0.1
Fig. 13. Probability of error vs normalized file transfer time.
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
ARTICLE IN PRESS
JID: COMCOM
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
300
9
Dummynet NS-2
Average File Transmission Time
280 260 240 220 200 180 160 140 0
0.02
0.04
0.06
0.08
0.1
Probability of Error Fig. 14. Probability of error vs average file transfer time. Table 2 Average file transfer time in emulated network using dummynet and simulated network using ns2. dummynet
ns2
Probability of error
Average file transfer time (s)
Normalized file transfer time (s)
Average file transfer time (s)
Normalized file transfer time (s)
0.00 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.10
160 181 193 213 225 232 242 255 266 279 285
1.00 1.13 1.21 1.33 1.41 1.45 1.51 1.59 1.66 1.74 1.78
145 170 183 199 205 214 219 227 236 245 256
1.00 1.17 1.26 1.37 1.41 1.48 1.51 1.57 1.63 1.69 1.77
Fig. 13 shows the normalized file transfer time for transferring 60 MB of file using MPSCTP. The corresponding average file transfer time values are plotted in Fig. 14. The exact values for the transfer time and the normalized transfer time are shown in Table 2. For each point on the curves, we take the average over 11 independent runs. The results in Fig. 13 show that the delay trends for the MPSCTP implementation are similar to those obtained through simulations using ns2. However, on comparing the absolute values in Table 2, we find that the delay values with kernel implementation are higher than the simulation values. This difference is primarily due to the deterministic nature of dummynet. A 10% packet drop probability drops exactly 10% of the packets in dummynet, whereas in ns2 packets are dropped in a statistical fashion. 7. Conclusion In this paper, we have proposed a modified version of MPSCTP and compared its performance with the CMT algorithm. The results indicate that the modification increases the sensitivity of MPSCTP for the acknowledgment losses; however, MPSCTP still performs better than the CMT protocol for RTX-CWND strategy. We have proposed the Tx-CWND strategy which is much easier to implement in the kernel than RTX-CWND strategy without causing any significant impact on the performance of the protocol. We have also implemented MPSCTP in the Linux Kernel and reported its comparative performance with the simulation results. We have also proposed a suitable heuristic
to practically implement delay insensitive optimization and demonstrated that it is effective in providing the agreed QoS to the end user. The performance of this heuristic will depend upon the value of the bounding factor ‘q’. Hence, a suitable study is required to calculate the value of ‘q’ to be used for a given network.
References [1] R. Stewart, Stream Control Transmission Protocol, 2007, (RFC 4960 (Proposed Standard)), updated by RFCs 6096, 6335, 7053 (Sep. 2007). URL. [2] S. Fu, M. Atiquzzaman, Sctp: state of the art in research, products, and technical challenges, Commun. Mag. IEEE 42 (4) (2004) 64–76, doi:10.1109/MCOM.2004.1284931. [3] P. Natarajan, F. Baker, P. Amer, J. Leighton, Sctp: what, why, and how, Internet Comput. IEEE 13 (5) (2009) 81–85, doi:10.1109/MIC.2009.114. [4] A.L. Caro Jr., J.R. Iyengar, P.D. Amer, G.J. Heinz, R.R. Stewart, Using sctp multihoming for fault tolerance and load balancing, SIGCOMM Comput. Commun. Rev. 32 (3) (2002) 23. http://doi.acm.org/10.1145/571697.571712. [5] E. Rathgeb, C. Hohendorf, M. Nordhoff, On the robustness of sctp against dos attacks, in: Proceedings of the Third International Conference on Convergence and Hybrid Information Technology, 2008. ICCIT ’08, 2, 2008, pp. 1144–1149, doi:10.1109/ICCIT.2008.196. [6] K.-J. Grinnemo, T. Andersson, A. Brunstrom, Performance benefits of avoiding head-of-line blocking in sctp, in: Proceedings of the International Conference on Autonomic and Autonomous Systems and Networking and Services, 2005. ICASICNS 2005. Joint International Conference on, 2005, pp. 1–8, doi:10.1109/ICASICNS.2005.73. [7] M. Scharf, S. Kiesel, Head-of-line blocking in tcp and sctp: Analysis and measurements, in: Proceedings of the Conference on Global Telecommunications, 2006. GLOBECOM ’06. IEEE, 2006, pp. 1–5, doi:10.1109/GLOCOM.2006.333.
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
JID: COMCOM 10
ARTICLE IN PRESS
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
[8] T. Wallace, A. Shami, A review of multihoming issues using the stream control transmission protocol, Commun. Surv. Tutori. IEEE 14 (2) (2012) 565–578, doi:10.1109/SURV.2011.051111.00096. [9] S. Shailendra, R. Bhattacharjee, S.K. Bose, Mpsctp: A simple and efficient multipath algorithm for sctp, Commun. Lett. IEEE 15 (10) (2011) 1139–1141, doi:10.1109/LCOMM.2011.080811.110866. [10] Y. Yuan, Z. Zhang, J. Li, J. Shi, J. Zhou, G. Fang, E. Dutkiewicz, Extension of sctp for concurrent multi-path transfer with parallel subflows, in: Proceedings of the Conference on Wireless Communications and Networking (WCNC), 2010 IEEE, 2010, pp. 1–6, doi:10.1109/WCNC.2010.5506559. [11] J. Iyengar, P. Amer, R. Stewart, Concurrent multipath transfer using sctp multihoming over independent end-to-end paths, Netw. IEEE/ACM Trans. 14 (5) (2006) 951–964, doi:10.1109/TNET.2006.882843. [12] S. Shailendra, R. Bhattachrjee, S.K. Bose, Optimized flow division modeling for multi-path transport, in: Proceedings of the Annual IEEE India Conference (INDICON), 2010, pp. 1–4, doi:10.1109/INDCON.2010.5712713.
[13] J.R. Iyengar, P.D. Amer, R. Stewart, Retransmission policies for concurrent multipath transfer using SCTP multihoming, in: Proceedings of 12th IEEE International Conference on Networks, 2004 (ICON 2004), 2, 2004, pp. 713–719, doi:10.1109/ICON.2004.1409269. [14] S. Shailendra, R. Bhattacharjee, S.K. Bose, Mpsctp: a multipath variant of sctp and its performance comparison with other multipath protocols, in: Proceedings of the IEEE International Conference on Communication Systems (ICCS), 2012, pp. 1– 4, doi:10.1109/ICCS.2012.6406154. [15] L. Lam, K. Su, C. Chan, X. Liu, Modeling of round trip time over the internet, in: Proceedings of the ASCC 7th Asian Control Conference, 2009, pp. 292–297. [16] R. Jain, D. Chiu, W. Hawe, A quantitative measure of fairness and discrimination for resource allocation in shared computer systems, Technical Report, DEC Research Report TR-301, 1984. [17] A. Ford, C. Raiciu, M. Handley, O. Bonaventure, TCP Extensions for Multipath Operation with Multiple Addresses, RFC 6824 (Experimental) (2013). < http://www.ietf.org/rfc/rfc6824.txt>
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
JID: COMCOM
[m5G;July 3, 2015;22:10]
Computer Communications 000 (2015) 1–10
Contents lists available at ScienceDirect
Computer Communications journal homepage: www.elsevier.com/locate/comcom
A multipath variant of SCTP with optimized flow division extension Samar Shailendra a,∗, R. Bhattacharjee b, Sanjay K. Bose b a b
CTO Networks Lab, Bangalore, India Department of Electronics & Electrical Engineering, I.I.T. Guwahati, Guwahati, India
a r t i c l e
i n f o
Article history: Received 26 September 2014 Revised 20 April 2015 Accepted 12 June 2015 Available online xxx Keywords: Stream control transmission protocol Multipath stream control transmission protocol Flow division at source Transport protocol
a b s t r a c t In the literature, Multipath Stream Control Transmission Protocol (MPSCTP) has been proposed as a multipath variant of Stream Control Transmission Protocol (SCTP). Unlike SCTP, MPSCTP uses the multiple available paths between the source and the destination in concurrent fashion using the multihoming feature of SCTP. MPSCTP in its original form implicitly assumes no acknowledgment loss. In this work, a modified algorithm for MPSCTP is proposed to mitigate this limitation and its performance is compared with Concurrent Multipath Transfer (CMT) using ns2 based simulation. A new path selection strategy for data transmission is incorporated and its results are compared with the RTX-CWND strategy proposed in the literature. This paper also presents a heuristic to implement delay insensitive optimization. The performance of this optimization for MPSCTP has been studied using ns2 based simulations. We have also presented the performance results of MPSCTP implementation in the Linux Kernel. © 2015 Elsevier B.V. All rights reserved.
1. Introduction In the recent past, there has been significant increase in the demand for high data rate and better quality of service for various types of multimedia traffic. These requirements have created tremendous pressure on the service providers to achieve better network utilization and provide better QoS to the end user. These requirements triggered various research activities to look for better throughput, resource utilization, and error resilience. As part of this effort, IETF standardized the Stream Control Transmission Protocol (SCTP) in 2001. SCTP [1–4] added features like multistreaming, multihoming and a cookie-based mechanism with 4-way handshake to mitigate various denial of service attacks [5]. SCTP’s multistreaming feature helps in reducing the head of line blocking that may occur in TCP [6,7] where a packet is not passed to the upper layer until all packets with smaller sequence number have been received. However, in certain scenarios, it may be acceptable if some part of the data is delivered out of sequence. For example, let us consider a scenario when a user is browsing a website which contains both images and normal text. We can send the images and normal text using two different streams so that even if the packets of the stream with the images are lost, the text can still be rendered for the user and vice versa.
∗
Corresponding author. Tel.: +91 9886227956. E-mail address: [email protected] (S. Shailendra).
SCTP’s multihoming feature may be useful when the end hosts have more than one IP address. Unlike TCP, an SCTP association is created using a combination of the host’s multiple IP addresses and one port. Using SCTP’s multihoming feature, all the IP addresses can participate in sending and receiving of data. SCTP assumes one of the paths as the primary path and uses it for data transmission. In the event of primary path degradation or data loss, SCTP may choose any of the alternative paths to transmit data. This provides better error resilience in case of network outages. Several issues related to SCTP multihoming are discussed in [8]. SCTP’s multihoming feature is extended to design multipath variants [9–11] which can use all the available paths to transfer data in a concurrent fashion. We had earlier proposed Multipath SCTP (MPSCTP) as a multipath variant of SCTP that uses all available candidate disjoint paths concurrently. In the literature, CMT has been proposed that also uses all the candidate paths concurrently. However, unlike CMT which uses only one sequence number, MPSCTP uses two levels of sequence numbering. This reduces the complexity of the algorithms significantly and makes MPSCTP more scalable than the CMT protocol. However, in its original form, MPSCTP [9] implicitly assumes that there is no acknowledgment loss in the network. Such an assumption may restrict the scope of usage of MPSCTP in high loss networks and wireless scenarios. The implementation of MPSCTP requires several other issues to be considered. A basic requirement for such multipath protocols is to properly divide a data stream on multiple candidate paths. The flow on the candidate paths will depend on the characteristics of the paths, which will in turn depend upon the performance of each link and
http://dx.doi.org/10.1016/j.comcom.2015.06.005 0140-3664/© 2015 Elsevier B.V. All rights reserved.
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
ARTICLE IN PRESS
JID: COMCOM 2
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
Type = 3
Chunk Flags
Chunk Length
Cumulative TSN Ack Cumulative PSN Ack Advertised Receiver Window Number of Duplicate PSN (X)
Number of Gap Ack Blocks (N)
Gap Ack Block #1 End
Gap Ack Block #1 Start ..... Gap Ack Block #N Start
Gap Ack Block #N End Duplicate PSN #1 ..... Duplicate PSN #X Fig. 1. SACK Structure for MPSCTP.
node on the path being considered. Several optimization techniques such as Delay Insensitive Optimization (DIO) have been proposed for this in the literature [12]. However, these techniques typically require the complete path statistics to be known at the source. It is somewhat difficult to obtain such statistics in an Internet like scenario. In this paper, we present the performance evaluation of the modified MPSCTP algorithm using ns2 based simulations. We have proposed Tx-CWND, a novel path selection policy for MPSCTP, and have compared its performance with RTX-CWND [11,13]. We also present here a heuristic to implement DIO in MPSCTP to divide the data on multiple available paths. Finally, we have implemented MPSCTP in the Linux Kernel and have presented its performance results. The rest of the paper is organized as follows. Section 2 presents the modified fast retransmission algorithm and looks at its performance. In Section 3 we present a heuristic for path selection policy. In Sections 4 and 5, a heuristic for delay insensitive optimization and its performance has been presented. Section 6 presents the MPSCTP performance in the Linux Kernel followed by the conclusion in Section 7. 2. Modified fast retransmission algorithm and its performance analysis Though, it was proposed with a multihoming feature, SCTP in its original form does not use multiple candidate paths concurrently. However, SCTP can be extended to divide data on multiple available paths in a parallel fashion. This division is expected to improve the overall throughput of the network. This multipath usage also provides better error resilience from path failure and path degradation and leads to better utilization of the overall network resources. However, such flow division causes certain side effects as well. The first one is that the flow division at source gives rise to false holes in the sequence numbers received at the destination. These false holes cause unnecessary fast retransmissions from the sender side because the receiver interprets these false holes as loss of packets and does not implement delayed acknowledgment. Due to gap indications in the acknowledgment, the congestion window is also not updated regularly. This generates bursty growth in the congestion window value. To overcome these side effects of multipath usage, we had earlier proposed MPSCTP [9] as a multipath extension of SCTP. The primary issue in MPSCTP is to distinguish the path sequence numbers from the data sequencing required by the upper layer. For this purpose, MPSCTP uses two levels of sequence numbers. One is
the Transmission Sequence Number (TSN). This is a single sequence space across all the candidate paths. The other one is the Path Sequence Number (PSN). PSNs are sequence numbers specific to individual paths and are monotonically increasing numbers. These are used to isolate the reordering due to multipath from the chunk loss on each path. Because PSNs are monotonically increasing, a packet lost on one path can be retransmitted on any alternate available path as well. MPSCTP also assumes that acknowledgments are retransmitted back on the same path over which the data was transmitted. This ensures that the RTT values are calculated properly for each path. The introduction of PSNs can take care of the false holes that arise in the packet sequence due to reordering of packets on multiple paths. Since, the acknowledgments are sent back based on the PSN values, this also obviates the problem of increased acknowledgment traffic due to holes in the packet sequence. Moreover, due to the PSNs, the MPSCTP receiver can clearly distinguish between chunk loss, sender induced reordering, and also does not require the Delayed Acknowledgment for CMT (DAC) algorithm and RTT heuristics as being used by CMT. However, this requires several changes in the chunk header and the SACK structure to accommodate the details related to the PSN values as presented in [9]. 2.1. Handling SACK losses MPSCTP in its original form implicitly assumes that there is no SACK loss on the reverse path. The SACKs have smaller probability of error in comparison to data packets. However, the assumption of no SACK loss on the reverse path limits the usage of MPSCTP on paths with high losses. To avoid this limitation of the protocol, we have earlier proposed a change in the SACK structure and the fast retransmission algorithm [14]. In this paper, we investigate the performance of MPSCTP with CMT for different retransmission strategies. The change in SACK structure and the algorithm are presented in Figs. 1 and 2, respectively. As shown in Fig. 1, we have added the cumulative TSN Acknowledgment (cumTSNAck) along with the cumulative PSN Acknowledgment (cumPSNAck) in the SACK structure. The cumTSNAck indicates the largest TSN received at the destination among all the paths. The sender removes a particular TSN from its send buffer if and only if the cumTSNAck value is greater than TSN itself. If a timeout happens for a particular PSN on that path, then the corresponding PSN is retransmitted (Fig. 2).
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
ARTICLE IN PRESS
JID: COMCOM
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
For every SACK received (at sender side): if (SACK contains GAP reports), For each destination (di ): For each TSN Ta , set count Ca = 0; if (TSN for di .PSN == Ta ), Ca ++ ; if (Ca ≥ 3), Initiate Fast Transmit; if (CumTSNAck ≥ TSN in send buffer), Do not remove from SendBuffer; For each destination (di ): if(timeout for di .PSN) Initiate Fast Transmit; Fig. 2. Modified fast retransmission algorithm for handling gap reports in MPSCTP.
2.2. Performance analysis In this section, we have compared the performance of the modified fast retransmission algorithm for MPSCTP with the CMT [11] algorithm for different retransmission strategies. In [11], the authors have also proposed several strategies for data retransmission. In this work, we have compared the performance of MPSCTP with CMT for two different retransmission strategies, namely RTX-SAME and RTXCWND. In the event of data loss, RTX-SAME strategy uses the same path for the retransmission of the packet, while RTX-CWND chooses the path with the largest congestion window. To compare the performance of this modified MPSCTP, we have considered an example with simple dual homed source and destination nodes with two disjoint paths between them. The bandwidth of both the paths is assumed to be 2 Mbps and the propagation delay for the two paths is 50 ms. Path-1 has a fixed packet loss probability of 1% but the probability of packet loss on path-2 is varied from 1% to 10%. However, both paths have been assumed to have a probability of acknowledgment loss of 1%. For our tests, we assume an ftp application transferring a 60 MB file using both MPSCTP and CMT with varying packet loss probabilities for path-2. Though, the above topology is relatively simple, it effectively models the network as seen by the transport layer between the end-hosts.
550
Fig. 3 shows the average file transmission times for the file using CMT and the modified MPSCTP. The results also show the 95% confidence interval for the average file transmission time. To obtain the above confidence interval, we have used 11 different runs and for each run different seed values are being used for the probability of packet error as well as the probability of SACK Error. We have compared the results for two different retransmission strategies. We have considered RTX-SAME and RTX-CWND strategies for our comparison. We notice that the modified MPSCTP with RTX-CWND strategy performs significantly better than CMT with RTX-CWND. However, MPSCTP with RTX-SAME strategy performs only marginally better than CMT with RTX-SAME strategy as this modification in the fast retransmission algorithm makes MPSCTP relatively more sensitive to acknowledgment losses than CMT. It may be noted that unlike the Delayed Acknowledgment algorithm in MPSCTP, the DAC algorithm always delays the SACK transmission. However, in the event of an actual SACK loss, this has an undesirable effect because it then delays the recovery of lost chunks due to delay in the SACK and thereby increases the overall file transmission time. 3. Tx-CWND path selection policy In this section, we propose Tx-CWND, a novel policy for path selection in MPSCTP. In [13], the authors have proposed several retransmission strategies. RTX-CWND was demonstrated to perform the best among them. However, retransmitting packets other than on its original path requires higher processing at the sender side. To reduce this increased processing, we propose the new Tx-CWND path selection policy. Tx-CWND is a path selection policy, which selects the path based on the congestion window and uses the same retransmission policy as RTX-SAME. In Tx-CWND, we always transmit the packet on the path with the largest congestion window. However, we do not change the path for retransmission and the packet is retransmitted on the same path as the one on which it was originally transmitted unless the path is marked inactive due to failure. In case of path failure the path with the current largest congestion window is selected for retransmission. The Tx-CWND strategy reduces the book-keeping as well as the processing required for retransmission path selection. Hence, it is simpler to implement this strategy in the Linux Kernel. It must be noted that Tx-CWND is a path selection policy and currently uses RTX-SAME as the retransmission policy. It is possible to
CMT RTX-SAME MPSCTP RTX-SAME CMT RTX-CWND MPSCTP RTX-CWND
500 Average File Transmission Time(Sec)
3
450 400 350 300 250 200 150 0.01
0.02
0.03
0.04
0.05 0.06 0.07 Probability of Error
0.08
0.09
0.1
0.11
Fig. 3. Average file transmission time for CMT and MPSCTP with RTX-SAME and RTX-CWND retransmission strategies.
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
ARTICLE IN PRESS
JID: COMCOM 4
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
Path−1
2 Mbps, 50 ms N3
N1 10 Mbps, 50 ms
10 Mbps, 50 ms
Source
Destination 10 Mbps, 50 ms
10 Mbps, 50 ms
2 Mbps, 50 ms N2
N4
Path−2 Fig. 4. Network layout.
incorporate any other retransimission policy as well, if so desired, including RTX-CWND though the latter may make the implementation much more difficult and increase the processing required. We compare the performance of Tx-CWND and RTX-CWND using ns2 based simulations for the network scenario shown in Fig. 4. The packet error probability of path-1 has been fixed at 1% while that of path-2 is varied from 1% to 10%. The bandwidths of both the paths are as shown in Fig. 4. The source (S) runs an ftp application to transmit a 60 MB file to the destination. The average time to transmit this file is shown in Fig. 5. The results are presented for both the RTX-CWND and Tx-CWND strategies. As discussed earlier Tx-CWND, a path selection policy, does the path selection during initial transmission of a packet. It selects the path based upon the current cwnd size. As mentioned earlier, Tx-CWND does not perform any path selection during retransmission(unless the path is marked inactive due to failure) and retransmits the packet on the same path as that of the original transmission. On the other hand, RTX-CWND is a retransmission policy. With RTX-CWND, the sender transmits a full cwnd number of packets on a path before starting transmission on another path. RTX-CWND selects the path during retransmission based upon the cwnd size. We observe in Fig. 5 that for smaller probabilities of error, average file transmission time for Tx-CWND strategy is more than that for the RTX-CWND strategy. This is because, when the probability of error is low, Tx-CWND experiences much more packet reordering than the RTX-CWND strategy as RTX-CWND keeps transmitting data on a path until its cwnd is completely exhausted while Tx-CWND transmits a packet on the path with the higher congestion window (i.e. more network resources). Since, cwnd is inversely proportional to the probability of error, the Tx-CWND strategy results in more packets being transmitted on paths with lower probabilities of error. This leads to relatively better performance when the probability of error is high. This can be seen in the normalized file transfer time results shown in Fig. 6. Here, the file transfer times are normalized with respect to the file transfer time when the probability of error is zero. We notice that at higher probability of error RTX-CWND has higher normalized transfer time than the Tx-CWND strategy. This indicates that the performance of RTX-CWND degrades much more rapidly than the Tx-CWND strategy as the probability of error increases. This makes Tx-CWND a better choice for channels with higher probability of error and for devices with limited processing power.
4. Heuristic for delay insensitive optimization algorithm The implementation of MPSCTP requires the flow to be divided on multiple candidate paths in an optimal way. The optimal division on candidate paths will depend not only upon the network parameters but will also depend upon the nature of the application supported on this network. Several optimizations are proposed in the literature to divide the data on multiple paths in parallel [12]. Let us consider a general network G(V,E) where V is set of nodes and E is the set of directional links. This network consists of N disjoint paths with the ith path consisting of Li nodes where i is indexed from 1 to N. Let wi be the mean total delay of the ith path. If λi is the arriving flow at the ith path, Delay Insensitive Optimization (DIO) ensures that the delay of any of the candidate paths does not exceed the target delay (Ti ). Hence, this parameter can be considered as a QoS parameter for the network. This parameter will typically depend upon the nature of application [12] and the range for this parameter may be known apriori for a given application [12]. The implementation of DIO will also require that the Ti information is available at the transport layer. This information can be provided by the underlying application through function calls between the application and the transport layers. maximize: N
λi
(1)
i=1
subject to:
wi ≤ Ti
λi ≥ 0
∀i = 1, 2, . . . , N
(2) (3)
where, Ti is the agreed upon end-to-end target delay for ith path. True implementation of DIO will require complete network statistics to be known at the source in order to calculate total delay. Moreover, solving the optimization problem for every change of the parameters is time consuming as well as computationally infeasible in most systems. Hence, in this section we propose a heuristic which closely approximates the above optimization. The basic requirement to implement DIO is that no packet should experience an end-to-end delay on any path which is more than the
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
ARTICLE IN PRESS
JID: COMCOM
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
280
5
RTX-CWND Tx-CWND
Average File Transmission Time
260 240 220 200 180 160 140 120 0
0.02
0.04
0.06
0.08
0.1
Probability of Error Fig. 5. Average file transmission time for Tx-CWND and RTX-CWND.
Normalized Average File Transmission Time
2
RTX-CWND Tx-CWND
1.9 1.8 1.7 1.6 1.5 1.4 1.3 1.2 1.1 1 0
0.02
0.04
0.06
0.08
0.1
Probability of Error Fig. 6. Normalized average file transmission time for Tx-CWND and RTX-CWND.
target delay (Ti ). The end-to-end delay on each path is also a function of the flow sent on that path. Hence, it is possible to adjust the end-toend delay experienced by any packet on a path by adjusting the flow on that path. The flow on any path should be adjusted such that the end-to-end delay experienced by a packet should not go beyond the agreed target delay (Ti ). Since path properties are dynamic in nature, an exact analysis of the flow to be carried on a path would be a costly operation both in terms of time and the resources required. Hence, we use the round trip time (RTT) measurement for the end-to-end delay calculations. It has also been demonstrated in earlier work that RTT measurements in Internet scenario are good approximations and give results which are close to those obtained using auto regressive models [15]. In a typical MPSCTP scenario, the congestion window is used to control the amount of data in the network in a single RTT. At any point of time, any path cannot have more than cwnd bytes outstanding on it. According to the modified congestion control for MPSCTP,
the cwnd is increased on every SACK received. As the flow on a path is increased, the delay encountered by a packet on that path also increases. Therefore, a change in cwnd based on the RTT measurements can be used to adjust the delay experienced by a packet in the network. A simple modification in the congestion control algorithm is observed to take care of the delay experienced by any packet on the network (Fig. 7). According to this algorithm, when the RTT approaches with-in a limit of the target delay, it does not increase the cwnd anymore. The network delay depends upon the several other activities in the network, and if the delay exceeds the RTT beyond a certain value of the target delay, the algorithm enters into congestion detection phase and reduces the congestion window to adjust the flow on the network. However, it does not perform another adjustment unless at least cwnd bytes are not received since the last adjustment. This is because cwnd value indicates the currently outstanding bytes on the network and hence it will take at least cwnd bytes to be received
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
ARTICLE IN PRESS
JID: COMCOM 6
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
This algorithm requires a penalty to be paid in terms of the loss of throughput for the application. However, we argue that this algorithm helps in improving the throughput of other fellow flows on the network because if the network is not able to provide the agreed delay performance, the algorithm will not increase the flow on that path. This gives an opportunity to other flows to use the network resources and hence helps in running the network in a fairer fashion. For this network, we measure the Fairness index using the Jain formula as given in [16]. We also measure the Link utilization for the shared bottleneck link in the network as
if (RTTi <(1-q) ∗ 2 ∗ Ti ) if (cwnd
n
before the effect of the adjustment is visible. The upper and the lower bounds of this limit are decided by the value of bounding factor (q). This bounding factor depends on the variance of the delay over the network i.e. its value is decided by how much maximum delay jitter exists in the network. In this paper, we have assumed q to be 0.1. That indicates that the maximum delay jitter in the network is not more than the 10% of the target delay. In networks with different delay jitters, the value of q can be chosen accordingly.
i=1
10 Mbps, 50 ms
N3
D1
U11
U1 Sources U2
Source
10 Mbps, 50 ms
T 11
T1
S
(4)
Bottleneck link bandwidth
where λi is the throughput of ith flow entering on the bottleneck link, and ‘n’ is the total number of flows entering the bottleneck link. The purpose of this parameter is to measure the utilization of the bottleneck link. These two factors jointly indicate both the reliability and the fairness of the proposed algorithm. By observing these two parameters (i.e. fairness index and link utilization) together, we
0.5 Mbps, 50 ms
N1
S1
Link utilization =
λ
Destinations T22
T2
S2
D Destination
U22
10 Mbps, 50 ms
D2 10 Mbps, 50 ms
0.5 Mbps, 50 ms
N2
N4
Fig. 8. Network graph for delay insensitive optimization.
350
Average throughput for MPSCTP
Average Throughput (Kpbs)
300 250 200 150 100 50 0 160
180
200 220 240 260 Target delay (T i) in milliseconds
280
300
Fig. 9. Average throughput for MPSCTP for various target delays.
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
ARTICLE IN PRESS
JID: COMCOM
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
demonstrate that though the optimization reduces the throughput of the source to satisfy the QoS constraint and increases the relative unfairness, it gives other fellow flows an opportunity to transmit more data and the overall network’s resource utilization would still not decrease by much.
7
Table 1 Fairness index and Link utilization for link N1 − N3 .
With optimization Without optimization
Fairness index
Link utilization
% Packet delayed
210 ms
270 ms
210 ms
270 ms
210 ms
270 ms
0.9787 0.9893
0.9802 0.9892
0.9359 0.9361
0.9357 0.9364
46.79 81.31
27.79 80.54
5. Performance study of MPSCTP with DIO Let us consider a network as shown in Fig. 8. The network consists of two UDP sources (U1 & U2 ), two TCP sources (T1 & T2 ), and one dual homed source (S) with an MPSCTP agent attached to it. There are ftp sources attached at T1 , T2 and S while U1 and U2 have CBR sources attached to them. All the links are assumed to have packet loss probability of 10%. For some of the links the bandwidths have been explicitly shown in Fig. 8; all the other links have bandwidth of 2 Mpbs each and propagation delay of 50 ms. We have measured the average throughput achieved by the MPSCTP source for various target delay (Ti ) and the results are presented in Fig. 9. The results indicate that when the target delay is less than or equal to 160 ms, no data can be carried on the network because the minimum round trip delay of a path in the network is 300 ms. Once the target delay increases beyond 260 ms, there is no significant increase in the throughput because there are other queuing and processing delays in the network and congestion window does not allow data to be carried on the network. Beyond 180 ms, we notice a continual increase in the data carried on the network with the increase in the target delay. However, beyond 260 ms the throughput does not increase further because it then gets limited by the other sources present in the network and is also limited by its own congestion window. Hence, this parameter can be used as a QoS parameter to provide the agreed quality of service to the users. Figs. 10 and 11 present the packet delay variation with the delay sensitive optimization and without the optimization. These results are plotted for the target delay of 210 ms and 270 ms, respectively. The results show that with delay optimization, the variance of delay of the packets as well as the maximum delay experienced in the network is reduced. However, this algorithm requires a penalty to be paid in terms of the loss of throughput for the application. However, as already mentioned, we argue that this algorithm helps in improving the throughput of the other fellow flows on the network because if the network is not able to provide the agreed delay performance,
Packet Delay (milliseconds)
4000
6. MPSCTP implementation in Linux Kernel We have implemented MPSCTP protocol in the Linux Kernel to demonstrate a feasible implementation of the protocol and measure its performance in a real network. Currently, the Linux Kernel supports SCTP as a loadable module. However, this module has no support for concurrent multipath usage for multihomed end-hosts. We
With Optimization
3000 2000 1000 4000 0
Packet Delay (milliseconds)
the algorithm will not increase the flow on that path. This gives an opportunity to other flows to use the network resources and hence helps in running the network in a fairer fashion as can be observed in Table 1. We notice in Table 1 that there is a decrease in the Fairness index for target delays of 210 ms and 270 ms because the optimization reduces the data to be carried on the links. However, there is no significant effect on link utilization; this indicates that other fellow flows are able to carry more data on that link. However, this behavior is useful to provide the end users a better quality of service and also allows other fellow flows to transmit their data on this link without compromising the resource utilization. Table 1 also shows the percentage of packets which do not comply with the target delay. It may be noted that there is a significant reduction in this percentage when the proposed optimization is used. As expected, significantly fewer packets will encounter delays more than the target delay. This indicates that this algorithm is able to provide better QoS to the end user without affecting much the overall resource utilization. For this optimization to be effective in a larger network, statistically more number of flows must be implementing the DIO algorithm. However, since DIO does not adversely affect any of the existing flows, it would be able to provide a viable migration path from current design approaches to the proposed DIO based approach. It may also be noted that DIO is a generic algorithm which can also be adapted to other multipath protocols such as Multipath TCP [17].
Without Optimization
3000 2000 1000 0 0
50
100
150
200 250 300 Time (seconds)
350
400
450
500
Fig. 10. End-to-end packet delay for the target delay of 210 ms.
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
ARTICLE IN PRESS
JID: COMCOM 8
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
Packet Delay (milliseconds)
4000
With Optimization
3000 2000 1000
Packet Delay (milliseconds)
4000 0
Without Optimization
3000 2000 1000 0 0
50
100
150
200 250 300 Time (seconds)
350
400
450
500
Fig. 11. End-to-end packet delay for the target delay of 270 ms.
Fig. 12. Network diagram for MPSCTP implementation in Linux Kernel.
have modified the SCTP module to incorporate concurrent multipath usage. This implementation is tested in an emulated network using dummynet. We have considered two dual homed machines PC1 and PC2 connected as shown in Fig. 12. The interfaces of these machines are connected through two CISCO switches to create two disjoint paths between the source and the destination. The delay and loss rate of each path is controlled using dummynet. The delay for each path between the two machines is set to 50 ms. The packet drop probability of one path is fixed at 1% while the packet drop probability on the other path is varied from 1% to 10%. The bandwidth of the two paths is also controlled using dummynet and each of them is set to 2 Mbps (Fig. 12). We transmit a 60 MB file using MPSCTP. The path selection policy used by MPSCTP is Tx-CWND with retransmissions made on the same path as the original path of transmission. We use a receiver buffer of 64 KB, as this is the most commonly used value in most practical scenarios.
1.9
Dummynet NS-2
Normalized File Transmission Time
1.8 1.7 1.6 1.5 1.4 1.3 1.2 1.1 1 0
0.02
0.04 0.06 Probability of Error
0.08
0.1
Fig. 13. Probability of error vs normalized file transfer time.
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
ARTICLE IN PRESS
JID: COMCOM
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
300
9
Dummynet NS-2
Average File Transmission Time
280 260 240 220 200 180 160 140 0
0.02
0.04
0.06
0.08
0.1
Probability of Error Fig. 14. Probability of error vs average file transfer time. Table 2 Average file transfer time in emulated network using dummynet and simulated network using ns2. dummynet
ns2
Probability of error
Average file transfer time (s)
Normalized file transfer time (s)
Average file transfer time (s)
Normalized file transfer time (s)
0.00 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.10
160 181 193 213 225 232 242 255 266 279 285
1.00 1.13 1.21 1.33 1.41 1.45 1.51 1.59 1.66 1.74 1.78
145 170 183 199 205 214 219 227 236 245 256
1.00 1.17 1.26 1.37 1.41 1.48 1.51 1.57 1.63 1.69 1.77
Fig. 13 shows the normalized file transfer time for transferring 60 MB of file using MPSCTP. The corresponding average file transfer time values are plotted in Fig. 14. The exact values for the transfer time and the normalized transfer time are shown in Table 2. For each point on the curves, we take the average over 11 independent runs. The results in Fig. 13 show that the delay trends for the MPSCTP implementation are similar to those obtained through simulations using ns2. However, on comparing the absolute values in Table 2, we find that the delay values with kernel implementation are higher than the simulation values. This difference is primarily due to the deterministic nature of dummynet. A 10% packet drop probability drops exactly 10% of the packets in dummynet, whereas in ns2 packets are dropped in a statistical fashion. 7. Conclusion In this paper, we have proposed a modified version of MPSCTP and compared its performance with the CMT algorithm. The results indicate that the modification increases the sensitivity of MPSCTP for the acknowledgment losses; however, MPSCTP still performs better than the CMT protocol for RTX-CWND strategy. We have proposed the Tx-CWND strategy which is much easier to implement in the kernel than RTX-CWND strategy without causing any significant impact on the performance of the protocol. We have also implemented MPSCTP in the Linux Kernel and reported its comparative performance with the simulation results. We have also proposed a suitable heuristic
to practically implement delay insensitive optimization and demonstrated that it is effective in providing the agreed QoS to the end user. The performance of this heuristic will depend upon the value of the bounding factor ‘q’. Hence, a suitable study is required to calculate the value of ‘q’ to be used for a given network.
References [1] R. Stewart, Stream Control Transmission Protocol, 2007, (RFC 4960 (Proposed Standard)), updated by RFCs 6096, 6335, 7053 (Sep. 2007). URL
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005
JID: COMCOM 10
ARTICLE IN PRESS
[m5G;July 3, 2015;22:10]
S. Shailendra et al. / Computer Communications 000 (2015) 1–10
[8] T. Wallace, A. Shami, A review of multihoming issues using the stream control transmission protocol, Commun. Surv. Tutori. IEEE 14 (2) (2012) 565–578, doi:10.1109/SURV.2011.051111.00096. [9] S. Shailendra, R. Bhattacharjee, S.K. Bose, Mpsctp: A simple and efficient multipath algorithm for sctp, Commun. Lett. IEEE 15 (10) (2011) 1139–1141, doi:10.1109/LCOMM.2011.080811.110866. [10] Y. Yuan, Z. Zhang, J. Li, J. Shi, J. Zhou, G. Fang, E. Dutkiewicz, Extension of sctp for concurrent multi-path transfer with parallel subflows, in: Proceedings of the Conference on Wireless Communications and Networking (WCNC), 2010 IEEE, 2010, pp. 1–6, doi:10.1109/WCNC.2010.5506559. [11] J. Iyengar, P. Amer, R. Stewart, Concurrent multipath transfer using sctp multihoming over independent end-to-end paths, Netw. IEEE/ACM Trans. 14 (5) (2006) 951–964, doi:10.1109/TNET.2006.882843. [12] S. Shailendra, R. Bhattachrjee, S.K. Bose, Optimized flow division modeling for multi-path transport, in: Proceedings of the Annual IEEE India Conference (INDICON), 2010, pp. 1–4, doi:10.1109/INDCON.2010.5712713.
[13] J.R. Iyengar, P.D. Amer, R. Stewart, Retransmission policies for concurrent multipath transfer using SCTP multihoming, in: Proceedings of 12th IEEE International Conference on Networks, 2004 (ICON 2004), 2, 2004, pp. 713–719, doi:10.1109/ICON.2004.1409269. [14] S. Shailendra, R. Bhattacharjee, S.K. Bose, Mpsctp: a multipath variant of sctp and its performance comparison with other multipath protocols, in: Proceedings of the IEEE International Conference on Communication Systems (ICCS), 2012, pp. 1– 4, doi:10.1109/ICCS.2012.6406154. [15] L. Lam, K. Su, C. Chan, X. Liu, Modeling of round trip time over the internet, in: Proceedings of the ASCC 7th Asian Control Conference, 2009, pp. 292–297. [16] R. Jain, D. Chiu, W. Hawe, A quantitative measure of fairness and discrimination for resource allocation in shared computer systems, Technical Report, DEC Research Report TR-301, 1984. [17] A. Ford, C. Raiciu, M. Handley, O. Bonaventure, TCP Extensions for Multipath Operation with Multiple Addresses, RFC 6824 (Experimental) (2013). < http://www.ietf.org/rfc/rfc6824.txt>
Please cite this article as: S. Shailendra et al., A multipath variant of SCTP with optimized flow division extension, Computer Communications (2015), http://dx.doi.org/10.1016/j.comcom.2015.06.005