# An Analysis of MPTCP Congestion Control
## 8 Conclusions  
Recent developments in Internet applications have increased the need for higher network bandwidth. In an environment where multi-homed hosts are becoming more common, the limitations of TCP in being able to only use a single path to transmit data are becoming more apparent. Where multiple paths exist between end-hosts on the Internet, these paths can be used to provide robustness, higher throughput and load-balancing benefits to applications. MPTCP was designed to take advantage of these benefits to provide increased throughput, balancing congestion and improving resiliency in the event of failure. MPTCP performs these functions through both scheduling and congestion control algorithms. It's compatibility with TCP means that MPTCP can be more easily deployed on the Internet where middle-boxes can often interfere with flows that are not TCP or UDP. However, MPTCP needs to co-exist with existing TCP traffic on the Internet. Current MPTCP congestion control implementations can be divided into uncoupled CC and coupled CC. With uncoupled CC, the CC algorithm on each subflow is independent of the performance of other subflows. This allows each subflow to achieve maximum throughput and behave as an independent TCP connection. However, this leads to unfairness in bandwidth allocation when multiple subflows compete with a TCP connection over the same shared link. As each subflow is independent, each subflow achieves similar throughput to a single TCP flow, leading to MPTCP achieving a multiple of the throughput a TCP flow can attain. An MPTCP connection with \(N\) subflows (hence \(N\)_cwnd_) will approximately grow the overall connection window \(N\) times faster than a single TCP flow over a shared bottleneck. As such, when the path is shared, using uncoupled CC cannot provide fairness towards TCP flows. With coupled CC, a shared congestion window is used across all the subflows in a connection. As such, the overall throughput of an MPTCP connection cannot be higher than that of a single TCP on the best end-to-end path. As MPTCP is designed to operate over the Internet. It is expected that MPTCP CC should provide good performance across a range of diverse paths. However, all current coupled CC algorithms assume that subflows always share a bottleneck, even if the paths are fully separated. As such, an MPTCP subflow tends to increase its _cwnd_ much less aggressively than a TCP connection on the same path. If the paths are disjoint, this puts MPTCP at a disadvantage and can lead to reduced throughput. Further, if the path characteristics (RTT and/or bandwidth) differ significantly, the shared congestion window can also result in the subflows being less aggressive in growing their window size. An analysis and simulation of these scenarios indicate that the performance of current coupled CC algorithms might not perform well if the network topology diverges from a simple topology of a shared bottleneck and paths with similar characteristics. This outcome was verified through experimental validation of MPTCP running over disjoint paths. If being deployed over complex networks such as the Internet, current MPTCP proposals may not achieve the potential benefits of using multiple paths. It is likely that MPTCP might not even perform as well as TCP. Further work is required on MPTCP CC to provide better outcomes over these diverse network conditions. To address the shortcoming of the coupled CC algorithms, some researchers explored the benefits of implementing a shared bottleneck detection mechanism at the transport layer. The idea is to use network feedback to detect bottlenecks and couple/decouple the subflows _cwnd_ accordingly. However, these proposals are yet to be tested in a real implementation with a variety of settings (e.g., different delay and bandwidth).