Receiver-centric Buffer Blocking-aware Multipath Data Distribution in MPTCP-based Heterogeneous Wireless Networks

Abstract

One major concern of applying Multipath TCP (MPTCP) to data delivery in heterogeneous wireless networks is that the utilization of asymmetric paths with diverse networking-related parameters may cause severe packet reordering and receive buffer blocking (RB²LOC). Although many efforts are devoting to addressing MPTCP's packet reordering problems, their sender-controlled solutions do not consider balancing overhead between an MPTCP sender and receiver, and their fully MPTCP mode cannot make MPTCP achieve a desired performance. This paper proposes a novel receiver-centric buffer blocking-aware data scheduling strategy for MPTCP (dubbed MPTCP-rec) necessitating the following aims: (1) alleviating MPTCP's packet reordering and RB²LOC problems, (2) improving the MPTCP performance, and (3) balancing load between the MPTCP sender and receiver. Simulation results show that the proposed MPTCP-rec solution outperforms the existing MPTCP solutions in terms of data delivery performance in heterogeneous wireless networks.

1. Introduction

Over the past few years, wireless access technologies (e.g., WiFi, 3G, and LTE) have undergone a period of extremely rapid growth and developments. These significant achievements provide mobile device users ubiquitous wireless Internet access, e.g., wireless local area networks, cellular data networks, and mobile broadband wireless networks [1]. Spurred by the latest advancements in these wireless communications and networking technologies, a growing number of modern mobile devices are now equipped with two or more network interfaces [2] (e.g., the Samsung Galaxy S5 phones now enables “Download Booster” feature which combines WiFi and LTE networks simultaneously to boost data speed [3]). Such multi-homed mobile devices provide multiple heterogeneous access ability and can increase the goodput performance by aggregating bandwidth of multiple network interfaces, supported by the Multipath TCP (MPTCP) [4-5], a promising transport layer technology standardized by the Internet Engineering Task Force (IETF).

The MPTCP is an extension to TCP, allowing the use of multiple interfaces for concurrently scheduling packets across multiple independent end-to-end paths, without requiring any modification or addition to the applications and still being compatible on today’s Internet [6]. Due to its concurrent transmission and bandwidth aggregation features, MPTCP provide a multi-homed host with numerous and attractive benefits including goodput improvement, latency reduction, robustness enhancement, and high-quality service provisioning [7]. Fig. 1 illustrates a basic MPTCP usage in a heterogeneous wireless network condition. It shows how an MPTCP-based mobile device uses three paths (Path A, Path B, and Path C) simultaneously to communicate with the server. Such a multi-path communication way is beneficial to improve the transmission efficiency, maximize the network utilization, and protect against the TCP-like single-path failure [8-9]. Therefore, MPTCP has been recognized as the desired transport layer protocol for parallel data transmission in the heterogeneous wireless network conditions.

Fig. 1.MPTCP-based data delivery in a heterogeneous wireless network

Although the benefits of applying MPTCP to data transmission have been demonstrated to be extremely useful, there is still significant ongoing work addressing several remaining gaps and challenges. The primary concern of MPTCP-based data transmission is related to handling packet reordering. The regular MPTCP’s scheduler splits packets over all available paths without considering the fact that asymmetric paths with diverse networking-related parameters may cause large numbers of out-of-order (O3) packet arrivals at the receiver [10]. These O3 packets need to be reassembled in-order at receive buffer before being delivered to the application. Therefore, in the regular MPTCP context, it is recommended that the receive buffer size should be large enough to contain all packets until the O3 or missing packets arrive. However, the typical mobile devices used in multi-homed wireless mobile networks have in general very limited memory size and little free space for the receive buffer. Correspondingly, severe packet reordering in the constraint receive buffer will lead to a “hot potato” receive buffer blocking (RB2LOC) problem and further leads to serious application-level throughput degradation.

Recent MPTCP efforts are devoted to addressing the packet reordering and optimizing the MPTCP performance [11-28], however, they still have some remaining challenges on this topic: 1) their sender-controlled operations (e.g., flow/congestion control, packet scheduling, and path management) do not consider balancing overhead between an MPTCP sender and receiver, and 2) they mostly use a traditional full-MPTCP bandwidth aggregation mode, in which all paths are used for data delivery, may fail to achieve a desired performance when the paths within the MPTCP session are with highly dissimilar characteristics. Our previous work [29-30] moves some operations, such as sending rate control, and path evaluation and selection, from the sender onto receiver in order to achieve a desired load balancing between the sender and receiver, and the supporting performance study convinces the advantages of using a receiver-driven Stream Control Transmission Protocol (SCTP) / Concurrent Multipath Transmission (CMT) [31-32] for multi-homed mobile device in wireless heterogeneous environment. However, like SCTP, all above SCTP extensions do not take into consideration any of the retro-compatibility benefits brought by MPTCP, as we discuss in the next section.

This paper jointly considers the benefits of MPTCP standard and our previous receiver-driven SCTP extensions [29-30] to propose a novel receiver-centric buffer blocking-aware data scheduling strategy for MPTCP (MPTCP-rec). The goals of MPTCP-rec are (i) to make MPTCP aware of RB2LOC timely, (ii) to ensure possible in-order packet arrivals and improve the MPTCP performance, and (iii) to possible balance overhead between an MPTCP sender and receiver. Our MPTCP-rec solution makes fundamental contributions against the state of art in the literature, in the following aspects:

 

2. Related Work

In the recent years, the growing interest in MPTCP has gained variety of attentions. Khalili et al. [6] proposed an opportunistic linked-increases algorithm (OLIA) to satisfy the Pareto-optimal design goals of MPTCP. Pearce et al. [7] investigated the implications for network security both in the transitional state and in a future, where MPTCP is partially supported and every device supports MPTCP, respectively. Zhou et al. [8] extended MPTCP’s congestion control mechanism for a user cooperation scenario in a LTE network environment. Peng et al. [9] designed a fluid model for MPTCP congestion control algorithm and identified design principles that guarantee the uniqueness and stability of system equilibrium. Arzani et al. [11] investigated the impact of the initial sub-path selection on the MPTCP performance. Park et al. [12] designed a greedy traffic scheduler in order to minimize the cost while satisfying the delay constraints. Li et al. [13], Cao et al. [14], and Raiciu et al. [15] extended the MPTCP’s congestion control and/or scheduling algorithms in order to mitigate the incast problem and improve goodput in the Data Center Networks (DCNs).

Apart from the transport layer information-dependent MPTCP extensions, there has been extensive interest in and research activity on cross-layer MPTCP designs. Corbillon et al. [16] developed a cross-layer MPTCP scheduler which utilizes information from both application-layer and transport-layer in order to re-order the transmission of packet and prioritize the most significant parts of the video content. Sinky et al. [17] presented a handoff-aware cross-layer assisted MPTCP (CLA-MPTCP) congestion control algorithm to alleviate handoff induced issues. Their simulation results showed that CLA-MPTCP outperforms the regular MPTCP technology in terms of handoff performance in heterogeneous wireless networks. Lim et al. [18] proposed a cross-layer path management mechanism for MPTCP, dubbed as MPTCP-MA, which uses MAC-Layer information to locally estimate path quality and connectivity. Their experimental results showed that the proposed MPTCP-MA solution can efficiently utilize an intermittently available path based on the associated link status.

Lately, there has been a growing interest in the research on MPTCP-based multimedia distribution. Wu et al. [19] presented an analytical framework to model the MPTCP-based video delivery performance, and developed a novel quality-driven MPTCP approach which integrates the Forward Error Correction (FEC) coding and rate allocation to minimize the end-to-end video distortion. Xu et al. [20] introduced PR-MPTCP, a partially reliable extension of MPTCP which offers a flexible QoS trade-off between timeliness and reliability for real-time multimedia applications. Wu et al. [21] developed a mathematical framework to analyze the frame-level energy-quality tradeoff for delay-constrained multihomed multimedia system, and extended MPTCP scheduler for prioritized frame scheduling and unequal loss protection to achieve high-quality video streaming while minimizing device energy consumption. Diop et al. [22] investigated and analyzed the QoS benefits induced by applying the “partial reliability” concept to MPTCP for interactive video applications. Our previous work PR-MPTCP+ [23] introduced a ‘prioritized reliable service’ and a ‘timed reliable service’ concept to an MPTCP implementation.

More recently, an increasing number of researchers have concentrated their efforts to address the packet reordering issue. Oh et al. [24] presented a novel feedback-based path failure detection and a new buffer blocking protection method to alleviate the packet reordering and buffer blocking problems. Alheid et al. [25] investigated the effect of out-of-order packets on the performance of MPTCP, and recommended a proper packet reordering algorithm for MPTCP in order to achieve a better throughput performance. Li et al. [26] extended MPTCP and proposed a SC-MPTCP solution, by applying linear systematic coding to MPTCP, to reduce packet reordering and improve system performance with bounded receive buffers. Cao et al. [27] designed a delay-based congestion controller for MPTCP, by making use of packet queuing delay as congestion signals, to achieve fine-grained load balancing while occupying fewer link buffers. Yang et al. [28] presented Non-Renegable Selective Acknowledgments (NR-SACKs) for MPTCP, and analyzed the impact of NR-SACKs in situations where an MPTCP receiver never discards received out-of-order packet from the receive buffer.

As discussed earlier, all above MPTCP solutions use a traditional sender-controlled mode. Our previous work [29-30] provids SCTP and CMT with a novel receiver-driven traffic schduling and path management algorithm in order to achieve a better load balancing between an SCTP sender and receiver. However, SCTP is not compatible with the current network infrastructure primarily due to: 1) it presents an entirely new API to applications and cannot support the socket API (Hosts cannot establish a SCTP connection by using the existing socket APIs); 2) it is not widely integrated in today’s TCP/IP stacks and has difficulty traversing Network Address Translators (NATs) and any middleboxes. The limitations constraint the success of SCTP in today’s and future architectures. This paper considers the benefits of our previous receiver-driven SCTP extensions and introduces a receiver-centric multipathing solution to the promising MPTCP.

 

3. The Motivation and Overview of MPTCP-rec

In regular MPTCP, given a flow with a small amount of subflows, each of them using an individual path, the sender tries to schedule traffic across those subflows (paths). However, because the latency and other networking-related characteristics of asymmetric paths can be significantly different and sensitive to variations, there is a high probability that a packet with lower sequence number sent over a low-quality path (e.g., a slower path) arrive at the receiver later than a packet with higher sequence number sent over a high-quality path (e.g., a faster path). As a result, the receiver needs to buffer the O3 packet until the packets with higher sequence number are received successfully. Once a great number of O3 packets held by the constrained receiver buffer for reordering, MPTCP undoubtedly suffers from significant receiver buffer blocking problems.

In order to ensure packets possible in-order arriving, the current MPTCP extensions generically optimize the operations at the sender side in order to evaluate each path’s real-time transmission efficiency and schedule packets over these paths accordingly. However, such sender-centric and receiver-passive approaches fail to consider the following aspects including:

In practice, a receiver may be adjacent to the wireless last-hop, thus it is more aware of the wireless link condition than its corresponding sender. Moreover, shifting some operations from the sender onto receiver can possibly balance the overhead between the sender and receiver. Motivated by these facts, we introduce MPTCP-rec, a receiver-centric backwards-compatible MPTCP extension. In the MPTCP-rec, the receiver is in charge of flow/congestion control operations and controls the data sending rate, while the sender merely responds based on the receiver’s feedback. In this context, the receiver do not need to give feedback to the sender the network parameters obtained in its forward paths but rather immediately use the first-hand knowledge to determine its desired sending rate (DSR). This feature makes MPTCP-rec support the real-time processing of network information.

Fig. 2 illustrates the architecture of MPTCP-rec system. As an extension to MPTCP, the MPTCP-rec is constructed by two major modules, which are Desired Sending Rate Estimator (DSRor) that runs at the receiver side, and Path Collector & Data Scheduler (PCDer) that runs at the sender side. The main functions of the two modules are detailed below:

Fig. 2.MPTCP-rec architecture

As shown in Fig. 2, there are seven states running at the MPTCP-rec receiver for flow/congestion control, which are Slow Start (SS), Slow Start Ready (SR), Congestion Avoidance (CA), Congestion Avoidance Ready (CR), Timeout (TO), GAP and Fast Recovery (FR). The general behavior of the seven states (e.g. state transitions among the seven states) is inherited from the TEAR solution [33], which is a well-known receiver-centric TCP extension. Running the flow/congestion control at the receiver side can possibly help the sender to reduce its overhead and share the workload between the sender and receiver.

 

4. MPTCP-rec Detail Design

4.1 Desired Sending Rate Estimator (DSRor)

As mentioned previously, the responsibility of DSRor is that performing congestion control and sending rate estimation at the MPTCP-rec receiver side. To this end, we draw on idea in the design of our previous SCTP-Rev’s SRE-rev (receiver-based sending rate estimator) [29] to develop the DSRor module, more precisely, the DSR estimation function of DSRor is a clone of the general behavior of the SCTP-Rev’s SRE-rev module. In order to make the paper self-contained, this subsection introduces the procedures how the MPTCP-rec’s DSRor, also SCTP-Rev’s SRE-rev module runs the DSR calculation at receiver.

In order to estimate the DSR value at receiver, MPTCP-rec’s DSRor employs a round information [33] to help the receiver to calculates the round-trip time (rtt) and retransmission timeout (rto). We introduce the definition and usage of round as following. Next the rtt calculation, also the major design of DSRor is detailed, respectively.

Based on the round information, the MPTCP-rec, like our SCTP-Rev solution [29], runs the rtt and rto calculation at receiver following the steps below:

which is the current round trip time, the weighting factors ξ and η use default values of and , respectively. The rto calculation at MPTCP-rec receiver is same as that does at the standard MPTCP sender.

Based on the rtt and rto information, MPTCP-rec receiver can further determine its desired sending rate for each path, and inform the sender of the DSR value. For per-path’s DSR calculation, let us suppose that there are δ paths (d1,d2,⋯,dδ) within the MPTCP session, and taking path dℓ(1≤ ℓ ≤δ) for example, each time a packet is sent on dℓ and is received successfully, the receiver calculates the DSR value ford dℓ by

where n is the number of packets received by receiver within one round. Ρsize is the packet size. The weighting factors ϕ and ϑ use a default value for fairness. As analyzed in our SCTP-rev solution [29], using the above DSR calculation equation can help the transport-layer protocols with AIMD-like congestion control mechanism (e.g., SCTP, MPTCP) to avoid bursty transmission fluctuation in lossy wireless transmission while maximizing the wireless resource utilization.

Before informing the sender of the estimated DSR value, the receiver further smoothes the value by using the following equation,

where is a matrix which is used to store the σ historical values of DSR for path dℓ. is a weighting coefficient vector, where Fψ(ψ∈[1,σ]) can be obtained by

Like our SCTP-Rev solution [29], the MPTCP-rec receiver will launch a timer with 1 rtt in length for each path once having a new round starts. When a timeout event occurs, or the sending rate the sender used is not equal to the advertised value, the receiver informs the sender of the current by using an extended MPTCP NR-SACK option [28], shown in Fig. 3. The extended NR-SACK chunk includes three additional parameters, which are timestamp that is used to order the NR-SACKs received from the different paths, pid (namely path identifier) that is used to identify paths between the sender and receiver [34], and Desired Sending Rate (DSR) that is devoted to informing the sender of the advertised DSR value for each path. The extended NR-SACK not only reports the block containing the most recently received data, but also provides a MPTCP sender with the most up-to-date information about per-path’s DSR value and the state of a MPTCP receive buffer.

Fig. 3.Formats of (a) MPTCP NR-SACK chunk, and (b) extended MPTCP NR-SACK chunk.

4.2 Path Collector & Data Scheduler (PCDer)

As mentioned previously, because underlying heterogeneity of Internet, asymmetric paths with highly dissimilar characteristics in terms of propagation delay and other network-related parameters are more common. In such a heterogeneous environment, the traditional full-MPTCP mode, in which all paths are used for data delivery, is bound to buffer blocking, with a great number of out-of-order packet arrivals and severe data reordering in the constrained receive buffer.

In view of the above problem, the MPTCP-rec includes a Path Collector & Data Scheduler (PCDer) aiming to mitigate the RB2LOC problem while maximizing the network resource utilization, in which the sender adaptively chooses all or a subset of its available paths to construct an optimal candidate path list (denoted as Plist) for multipath data delivery and bandwidth aggregation. To find a suitable group of paths, the MPTCP-rec sender needs to: 1) calculate and distinguish per-path’s transmission quality, and 2) monitor and predict a RB2LOC event timely.

For path quality calculation and distinguishing, different from existing MPTCP extensions, in MPTCP-rec, the sender does not need to calculate the transmission quality for each path; it just only receives per-path’s DSR value from the receiver and sorts its paths according to their DSR value. This receiver-assisted sending rate control feature possibly helps MPTCP reduce the sender’s computation overhead and share the load between the sender and receiver.

For the RB2LOC prediction, the MPTCP-rec sender monitors the jitter indicator of the advertised receiver window (awnd) [35], awndΔ, in order to recognize the RB2LOC event timely. Let awndcurr, awndmax, awndmin and awndavg be the current value, the maximum value, the minimum value, and the average value of awnd, respectively. The awndΔ can be calculated by using the following equation,

where the average value of awnd, awndavg, can be calculated by

Meanwhile, assuming the observed values of awnd are (awnd1, awnd2, ..., awndm), the values of awndmax and awndmin can be computed by and respectively.

Then, the MPTCP-rec sender simply monitors the variation of awndΔ to predict whether or not a RB2LOC event is upcoming. We determine a RB2LOC is to be occurred if the below condition is detected,

which tκ and tκ−1 (tκ > tκ−1) are the observed time. When awndΔ < 0, the continuous decrease of awndΔ indicates a RB2LOC event is to be occurred.

In the case of an upcoming RB2LOC event is detected, in order to reduce the RB2LOC problem, the MPTCP-rec sender removes the path that minimizes the objective function from the candidate path list Plist and then marks the state of as UNUSED for data transmission,

subject to

While in the case of non-RB2LOC event is detected, in order to maximize the network resource utilization, the MPTCP-rec needs to switch to Full-MPTCP mode, which refers to the regular MPTCP operations where the sender uses all of its available paths to construct the Plist for multipath data scheduling. This approach helps MPTCP-rec fully utilize all the available bandwidth and increase the packet delivery speeds up. The PCDer-based data delivery strategy is as follow, and the corresponding pseudo code is presented in Algorithm 1. We also present a basic operation of MPTCP-rec (shown in Fig. 4) to make the reader easily understand the formula’s step process and MPTCP-rec algorithm’s operation.

Fig. 4.A basic operation of MPTCP-rec

 

5. Simulations and Analysis

5.1 Simulation topology

A comprehensive performance evaluation has been carried out on the NS-2.35 (Network Simulator version 2.35) [36], in which the MPTCP patch [37] for NS-2 has been extended and embedded. The simulations considered a MPTCP-based heterogeneous wireless network environment shown in Fig. 5. Both MPTCP endpoints have three asymmetric paths (denoted Path A, Path B, and Path C) with different network-related parameters. Path A’s bandwidth is set to 384Kbps and 20-50 ms propagation delay, which corresponds to a 3G/UMTS link. Path B experiences 11Mbps bandwidth with 10-20 ms propagation delay which is encountered in WiFi/IEEE 802.11b standard. Path C’s bandwidth is set to 10 Mbps and 20-50 ms propagation delay, which is representative for a WiMax/IEEE 802.16 link. The main configurations of the three paths are illustrated in Table 1. The other MPTCP parameters just use the default values provided in the NS-2 MPTCP patch.

Fig. 5.Simulation topology

Table 1.Path configuration used in the simulation

In order to simulate the data-link layer’s frame loss, we attach two loss models for each wireless link, which are the Uniform loss model that represents distributed loss caused by random contention or wireless interference, and the Gilbert loss model (also refer to as the two-state Markov loss model) that represents infrequent continuous loss caused by signal fading or stream bursty injection. To consume per-path’s available bandwidth, we attach each path with a Variable Bit Rate (VBR) generator in order to send VBR-based Internet background traffic to its corresponding VBR receiver. Like [38], the packet size (in bytes) used for the VBR background traffic are chosen as follows: 50% are 44-byte, 25% are 576-byte, and the rest 25% have 1500-byte. 90% of the total bytes are carried by TCP connection and the other 10% are over UDP connection. The aggregate VBR background traffic on each path varies randomly between 0-50% of the access-link’s bandwidth. The total simulation run time is 120 seconds.

5.2 Simulation results

We note that applying some promising technologies (i.e., cross-layer activities, network coding) to MPTCP is a widely-researched topic. However, the proposed MPTCP-rec solution is devoted to improving MPTCP protocol itself depended solely upon the information provided by the transport layer. Therefore, in this subsection, we only present the performance evaluation and comparison between the standard MPTCP and the proposed MPTCP-rec. To make it convenient, we portray the results of the standard MPTCP as ‘MPTCP’ in the test result figures, and the results with the proposed solution are portrayed as ‘MPTCP-rec’, respectively.

1) Data sending and receiving times

Fig. 6 illustrates the sending and arrival times of several data when the standard MPTCP and MPTCP-rec are used, respectively. We can observe that MPTCP-rec attains a greater number of sending and receiving Data Sequence Number (DSN) than the standard MPTCP. That is because the standard MPTCP allocates traffic fairly over all its available paths, ignoring the fact that in a heterogeneous network environment different paths have different transmission capacities. Such “blind” scheduling strategy is bound to buffer blocking, with a very large amount of out-of-order data chunks arrivals and severe packet reordering in the overloaded receive buffer, which constrains the sender from sending any new data chunk. In contrast, the MPTCP-rec adaptively selects a set of good paths for each MPTCP flow, by making MPTCP aware of path sending rate and RB2LOC event. Thereby, MPTCP-rec achieves higher sending and receiving DSN than the standard MPTCP.

Fig. 6.Comparison of sending and receiving DSN

2) Out-of-order data chunks

The out-of-order DSN (O3-DSN) metric, which is measured by the offset between the DSNs of two consecutively received data chunks, is a good metric selection used to reflect the performance of multipath data delivery in a heterogeneous wireless network environment. Fig. 7 illustrates the O3-DSN metric variation between simulation time t=0s and t=120s. As the figures shown, the standard MPTCP generates more out-of-order data chunks and requires increased packet reordering than the MPTCP-rec. This is because in the standard MPTCP, the sender schedules packets over all paths, without considering the fact that huge quality differences among these paths will result in a large number of outstanding data chunks. In contrast, MPTCP-rec selects a set of path accordingly and schedules packets over the preselected paths. This way helps MPTCP-rec reduce the out-of-order data arrival and consequently performs better than the standardMPTCP.When comparing the two solutions, it can be seen that the peak out-of-order data reception at the receiver is close to 3×105 using the standard MPTCP, while it is approximately 1.8×105 when using the proposed MPTCP-rec solution.

Fig. 7.Comparison of out-of-order DSN

3) Average throughput

Fig. 8 shows the comparison of average throughput when using the standard MPTCP and MPTCP-rec, respectively. Since MPTCP-rec jointly considers the delay variation, packet loss, and RB2LOC probability to estimate per-path’s sending rate. This feature makes MPTCP-rec reduce the packet loss, RB2LOC probability, increase the packet sending and receiving times, and improve the goodput performance. While the standard MPTCP simply splits packets over all its asymmetric paths, regardless of the fact that some paths with low quality will cause the overall throughput degradation of an receive buffer-constrained MPTCP session. Compared with the standard MPTCP, the MPTCP-rec throughput is about 40.93% higher than that of the standard MPTCP scheme.

Fig. 8.Comparison of throughput performance

4) Comparisons of end-to-end delay and Jitter

Fig. 9 shows the end-to-end delay comparison when using the standard MPTCP and MPTCP-rec, respectively. As mentioned above, MPTCP-rec takes into consideration the delay variations during per-path’s sending rate estimation and path selection. This feature helps MPTCP-rec flows avoid passing the more congested links in a heterogeneous network environment. As a result, MPTCP-rec achieves significantly lower end-to-end delay performance than the standard MPTCP. Compared with the standard MPTCP, the MPTCP-rec’s end-to-end delay is about 48.73% lower than that of the standard MPTCP scheme. Jitter is a variation in packet transport delay caused by link transient failure, stream burst, and other networking-related factors effects on transmission performance. Lower levels of jitter are more likely to occur on satisfactory transport solution and vice verse. Therefore, jitter has been recognized as a very useful metric to convince the performance of transport protocols. Fig. 10 illustrates the jitter comparison results when the standard MPTCP and the proposed MPTCP-rec are used, respectively. Since the MPTCP-rec solution can identify per-path’s sending rate, it further enables a sending rate-driven RB2LOC-aware algorithm to select a set of good paths for data delivery. Thereby, it outperforms the standard MPTCP in terms of jitter performance.

Fig. 9.Comparison of end-to-end delay

Fig. 10.Comparison of jitter

 

6. Conclusions

Motivated by the facts that a receiver may be adjacent to the wireless last-hop and it can be more aware of the wireless link condition than its corresponding sender, this paper presents a novel receiver-centric buffer blocking-aware data scheduling strategy for MPTCP (dubbed as MPTCP-rec), by jointly considering the benefits of MPTCP technology and our previous receiver-driven SCTP-based data delivery solution. In MPTCP-rec, the receiver is devoted to controlling how much data can be sent, while the sender is responsible for determining which paths can be used. Such a sender-receiver cooperation-based multipath data transmission is beneficial for MPTCP to: (1) alleviate the packet reordering and RB2LOC problems, (2) improve the performance, and (3) balance load between the sender and receiver. Simulation results show that the proposed MPTCP-rec solution outperforms the existing MPTCP solutions in terms of data delivery performance in heterogeneous wireless networks.