# An Analysis of MPTCP Congestion Control
## 7 MPTCP Congestion Control
### Alternative Approaches
Second, inter-packet timing in the transport protocol depends on the CC and flow control mechanisms and any attempt to control/modify flow's timing can lead to a negative impact on the connection's performance [41]. [PERSON] et al. [41] developed a passive detection method called Dynamic Window Coupling (DWC). In DWC, both loss and delay signals are used to detect shared bottlenecks. In the algorithm, subflows that share a common bottleneck are grouped in the same set. A centralised entity, called the Subflow Manager (SM), is used to manage the sets. Each set has its own independent _cwnd_ which is increased/decreased by the SM while operating in the CA phase. Flows that do not share any bottleneck with other MPTCP flows of the same connection behave as a regular TCP (NewReno CC). The process of forming a set starts with a loss congestion event, following this, delay or loss congestion events are examined to group the subflows into the set. When a subflow experiences a packet loss, the SM alerts all the other subflows of the congestion event. The subflow is then removed from its original set and a new active set is initiated. The other subflows are inspected for any congestion indicator in the near past or future of the congestion event. Any subflow that detects a packet loss or a large delay increase is removed from its current set and gets added to the active set. Subflows without any congestion signal remain in their original set. There can be no more than one active set at any instance in time. DWC showed better aggregated throughput than that for LIA over disjoint paths. The algorithm occasionally failed to detect real shared bottleneck situations. For example, packet loss may occur randomly over lossy networks. Alternatively, congestion events may get synchronised and lead to false positive shared bottleneck detection as the paths experience similar RTT or background traffic. Further experiments by [PERSON] et al. [42] showed that although DWC throughput is higher than that with LIA at distinct bottlenecks, it is often unable to achieve fair bandwidth allocation when sharing a bottleneck with TCP due to its erroneous bottleneck detection. [PERSON] and [PERSON] [43] designed a shared bottleneck detection (SBD) algorithm named MPTCP-SBD. Where a shared bottleneck is detected, MPTCP subflows use OLIA CC and in disjoint paths, the subflows use decoupled _cwnd_ (Reno). The MPTCP-SBD algorithm uses three key statistics of One Way Delay (OWD) to detect bottleneck. The MPTCP Time Stamp (TS) is modified with microsecond precision. This new TS is included in the data segment by the sender. At the receiver, the relative OWD is calculated by subtracting the arriving TS from the host's version of current time. The kernel stores the statistics for the last \(N\) intervals. Every 350 ms, the SBD decision mechanism uses OWD statistics collected over the last \(N\) intervals to group the flows. Flows are grouped into non-congested flows and shared bottleneck flows. The mechanism repeats the process for 10 sets to ensure groupings are accurate. The grouping information is identified using a group ID and is carried in the return ACK via the MPTCP option. The sender uses the SBD feedback to decouple subflows that are in distinct bottlenecks during CA phase. The SDB algorithm showed improvement in MPTCP throughput over disjoint bottlenecks when compared to OLIA. However, the algorithm was also shown to be slightly more aggressive than OLIA towards TCP flows over shared bottlenecks due to not grouping the same connection subflows, resulting in them acting as independent TCP flows. Furthermore, the background noise on disjoint paths led to a decrease in bottleneck detection accuracy. Instead of using delay and loss, [PERSON] et al. [44] designed a Shared Bottleneck based CC (SB-CC) scheme based on Explicit Congestion Notification (ECN). The packets that exceed the queue threshold at an intermediate router are marked and the receiver notifies the sender of the ECN in a return ACK.