# An Analysis of MPTCP Congestion Control
## 6 MPTCP Schedulers  
Where multiple paths exist between end-hosts, it is the responsibility of the sender to decide which path to use when transferring data. After establishing the connection, the MPTCP scheduler segments the data in the sender buffer and selects the best available subflow for each packet. A subflow is considered available when the three-way handshake is completed. The scheduler policy is used to select the best path from all currently available subflows [18]. Random selection of a path for data transfer can lead to poor performance, such as head-of-line blocking (Section 3.1.1), window limitations (Section 3.1.2) and bufferbloat. As such, the path selection policy can have a critical impact on ultimate MPTCP throughput. Bufferbloat refers to having excessively large buffers in bottleneck routers. When paths are congested, large buffers result in packets residing in the queue for a long time and causes undesirable latency. Bufferbloat increases network delay and reduces throughput [2]. Since MPTCP became available in the Linux kernel in 2013, several multi-path schedulers have been proposed for different purposes. Each scheduler can be selected based on system and application requirements. Table 1 summarises some of the standard and non-standard schedulers along with their approach in making scheduling decisions. The default MPTCP scheduler in Linux is minRTT [25]. minRTT first sends data on the subflow with the lowest RTT until its _cwnd_ is full. Then, it starts sending data on the subflow with the next highest RTT. The aim of the scheduler is to optimise throughput and load balancing. minRTT benefits bulk transfer applications and heterogeneous networks. Unfortunately, minRTT can introduce new issues in terms of performance, such as blinder decision and biased-feeding phenomenon [18]. The blinder decision problem is caused by minRTT choosing the path solely based on the path latency, regardless of the other metrics (e.g., transmission rate, packet loss). For example, multiple subflows would choose a path with characteristics of 2 ms delay and 10 Mbps capacity in preference to a path with 3 ms delay and 100 Mbps capacity. Even though subflows travel through the low delay path, there is a risk of packet loss as all the subflows choose the same path which has a lower bandwidth [18]. Biased-feeding is due to the scheduler preferring the same path as long as it is available. The other subflow is only selected when the first subflow is no longer available, most likely due to a full _cwnd_ or loss event. As soon as the first path becomes available, it is immediately selected in preference to other paths [18]. The redundant scheduler sends the same packet over multiple subflows, the packet is likely to arrive first on the path with minimum latency. When the same packet arrives on other subflows, it is discarded. The redundant scheduler is useful when the application needs to achieve the lowest latency whilst sacrificing bandwidth. It also provides some level of resiliency [25]. The round-robin scheduler simply cycles over subflow queues. The RR scheduler is useful for testing/academic purposes. However, it tends to induce head-of-line blocking and as such often results in drastically reduced performance [25]. Non-standard MPTCP schedulers discussed in the literature focus on improving a single or various metrics to distribute data. Weighted round-robin [26] is an extension to the round-robin scheduler providing optimal load-balancing using subflow weights. Each subflow can be weighted differently Weighted method allows setting values unequally. As such, WRR distributes data based on the specified weight values. The Shortest Transfer Time First (STTF) [27] scheduler predicts the transfer time on different paths. It then assigns unsent segments to the path with shortest transfer time. STTF can be used in interactive applications which require low transmission time. The Highest Send Rate (HSR) [28] scheduler chooses a subflow based on the highest sending rate.