# A Brief Review of Multipath TCP for Vehicular Networks
## 3 Congestion Control and Scheduler
### Scheduler  
#### 3.2.1 Pre-Defined Scheduler  
As mentioned above, scheduler is another important part that greatly influences MPTCP performance. Generally, a scheduler has to consider two main constraints, namely, head-of-line (HoL) blocking [64] and receive-window limitations. Round-Robin (RR) and Lowest-RTT-First (LowRTT) [65] are well-used schedulers. The RR scheduler distributes packets through every active path in a circular order, regardless of whether there are severe latency differences among different paths. On the other hand, to mitigate the effects of delay difference in heterogeneous networks, LowRTT prioritizes fast flows then relatively slow flows until the congestion window is filled up. For example, as shown in Figure 3, the MPTCP scheduler sends three packets on the fast subflow \(1\) while only sending one on the slow subflow \(2\). Figure 3: Multipath TCP scheduler. There have been many studies in regard to the scheduler. In [66], [PERSON] et al. proposed a scheduler called ReMP. The ReMP duplicates packets over all subflows in order to obtain reliability. Experiments show that ReMP halves the average round-trip time. However, this way may cause additional overhead. MPTCP implementation is available in Linux kernel [47]. The intelligent Linux-MPTCP scheduler [67] is implemented in the MPTCP Linux kernel. The scheduler first estimates the available bandwidth of each subflow, then distributes data packets based on the estimation proportionally. In addition, packets to be sent can be selected to transmit from the shared sending buffer. However, this scheduler is fragile in lossy networks. Completing all of the subflows transmissions at the same time will benefit the entire transmission for MPTCP. It is considered that the MPTCP's default scheduler is suboptimal because the default scheduler makes decisions based solely on RTT. It could cause congestion at a high speed path due to injecting too many packets into it, which would result in bufferbloat because of out-of-order packets. Therefore, a scheduler should also consider the congestion situation of paths while scheduling data packets across different subflows. In [68], [PERSON] et al. proposed a scheduler that first estimates the available bandwidth of the paths and then decides the scheduling policy based on the path capacity of the subflows. The path utilization rate can be maximized by keeping the paths longer at a saturation point. In order to complete all the subflow transmissions at the same time in heterogeneous networks, [PERSON] et al. [65] introduced a RTT-based scheduler extension, namely, opportunistic retransmission and penalization. The main purpose of this extension is for compensating the delay differences on different paths. The segment that causes HoL will be resent across other available flows in RP. Similar to RP, CMT-SCTP [69] triggers chunk rescheduling when the transmission is stalled in asymmetric paths. Similarly, [PERSON] et al. [70] proposed an algorithm, called bufferbloat mitigation (BM). The BM is for suppressing the RTT by limiting the amount of transmission data. Besides the above-mentioned studies, there are some efforts on reducing the delay difference and data-sorting cost. In [71], [PERSON] et al. proposed a data distribution method called ATLB. ATLB consists of three parts, namely, data distribution, path-failure detection, and recovery mechanism. The data distribution method is designed for reducing the data-sorting cost of the receiver buffer. The path-failure detection and recovery mechanism is for preventing transmission stalling. In [72], [PERSON] et al. proposed a scheduler called decoupled multipath scheduler (DEMS). The DEMS aims at improving data chunk download efficiency over multiple paths. DEMS is robust to diverse network conditions, especially for fetching medium size files and small size web pages. A blocking estimation-based method (BLEST) was proposed in [73]. BLEST aims to minimize HoL blocking at the receiver side in heterogeneous networks.