coupled congestion control for multipath transmission

The reasons to develop coupled congestion control have been proposed in [1]

Goal 1 (Improve Throughput) A multipath flow should perform at least as well as a single path flow would on the best of the paths available to it.
Goal 2 (Do no harm) A multipath flow should not take up more capacity from any of the resources shared by its different path than if it were a single flow using only one of these paths. This guarantees it will not unduly harm other flows.
Goal 3 (Balance congestion) A multipath flow should move as much traffic as possible off its most congested paths, subject to meeting the first two goals.

Theory on LIA

 Based on the congestion window control rule of Reno, several congestion control methods (LIA, OLIA, Balia) have beed developed.
 The congesition window adjustment rule of Reno is：
$$w(t+1)\leftarrow \{\begin{array}{ll}w(t)+I& \text{when an ack is received}\\ w(t)-D& \text{when loss is detected}\end{array}\text{\hspace{1em}(1)}$$
 In Reno,$I=\frac{\alpha }{w}$, $D=\beta w$. 对于Reno，$\alpha =1,\beta =0.5$.
 According to [2], the differential equation of TCP Reno is:
x ˙ = 1 − p r t t 2 − x 2 p 2 = x r t t { I ( 1 − p ) − D p } (2) \dot x=\frac{1-p}{rtt^2}-\frac{x^2p}{2}=\frac{x}{rtt}\{I(1-p)-Dp\}\tag{2} x˙=rtt21−p​−2x2p​=rttx​{I(1−p)−Dp}(2)
 Here, $x=\frac{w}{rtt}$.
 Let $\dot{x}=0$, the theory throughput of tcp is，
$$x=\frac{1}{rtt}\sqrt{\frac{\alpha (1-p)}{p\ast \beta }}\text{\hspace{1em}(3)}$$
 The congestion window incremental rule of LIA is：
$$I_{mptcp}=\frac{\max \frac{w_r}{rt{t}_r^2}}{({\sum }_{k\in S}\frac{w_k}{rt{t}_k}{)}^2}=\frac{\max \frac{w_r}{rt{t}_r^2}}{({\sum }_{k\in S}{x}_k{)}^2}\text{\hspace{1em}(4)}$$
 Substituting (4) to (1), $I(1-p)=Dp=\frac{wp}{2}$。The theory throughput of LIA：
$$\sum _{k\in S}{x}_k=\frac{1}{rtt}\sqrt{\frac{2(1-p)}{p}}$$
 That guaratees the multipath LIA session can maintail bottleneck fairness when sharing the same bottlenck with single path session.
 The way to calculate $\alpha$ in LIA is:
$$\alpha =\frac{\max \frac{w_r}{rt{t}_r^2}}{({\sum }_{k\in S}\frac{w_k}{rt{t}_k}{)}^2}=\frac{w_{best}}{({\sum }_{k\in S}\frac{w_k\ast rt{t}_{best}}{rt{t}_k}{)}^2}$$
 After every $\frac{1}{\alpha }$ acknowledged packets, the size of congestion widnow will be increaased by 1.
 The implementation in Linux kernel。

static void mptcp_ccc_recalc_alpha(const struct sock *sk)
{
	const struct mptcp_cb *mpcb = tcp_sk(sk)->mpcb;
	const struct mptcp_tcp_sock *mptcp;
	int best_cwnd = 0, best_rtt = 0, can_send = 0;
	u64 max_numerator = 0, sum_denominator = 0, alpha = 1;

	if (!mpcb)
		return;

	/* Do regular alpha-calculation for multiple subflows */

	/* Find the max numerator of the alpha-calculation */
	mptcp_for_each_sub(mpcb, mptcp) {
		const struct sock *sub_sk = mptcp_to_sock(mptcp);
		struct tcp_sock *sub_tp = tcp_sk(sub_sk);
		u64 tmp;

		if (!mptcp_ccc_sk_can_send(sub_sk))
			continue;

		can_send++;

		/* We need to look for the path, that provides the max-value.
		 * Integer-overflow is not possible here, because
		 * tmp will be in u64.
		 */
		tmp = div64_u64(mptcp_ccc_scale(sub_tp->snd_cwnd,
				alpha_scale_num), (u64)sub_tp->srtt_us * sub_tp->srtt_us);

		if (tmp >= max_numerator) {
			max_numerator = tmp;
			best_cwnd = sub_tp->snd_cwnd;
			best_rtt = sub_tp->srtt_us;
		}
	}

	/* No subflow is able to send - we don't care anymore */
	if (unlikely(!can_send))
		goto exit;

	/* Calculate the denominator */
	mptcp_for_each_sub(mpcb, mptcp) {
		const struct sock *sub_sk = mptcp_to_sock(mptcp);
		struct tcp_sock *sub_tp = tcp_sk(sub_sk);

		if (!mptcp_ccc_sk_can_send(sub_sk))
			continue;

		sum_denominator += div_u64(
				mptcp_ccc_scale(sub_tp->snd_cwnd,
						alpha_scale_den) * best_rtt,
						sub_tp->srtt_us);
	}
	sum_denominator *= sum_denominator;
	if (unlikely(!sum_denominator)) {
		pr_err("%s: sum_denominator == 0\n", __func__);
		mptcp_for_each_sub(mpcb, mptcp) {
			const struct sock *sub_sk = mptcp_to_sock(mptcp);
			struct tcp_sock *sub_tp = tcp_sk(sub_sk);
			pr_err("%s: pi:%d, state:%d\n, rtt:%u, cwnd: %u",
			       __func__, sub_tp->mptcp->path_index,
			       sub_sk->sk_state, sub_tp->srtt_us,
			       sub_tp->snd_cwnd);
		}
	}

	alpha = div64_u64(mptcp_ccc_scale(best_cwnd, alpha_scale_num), sum_denominator);

	if (unlikely(!alpha))
		alpha = 1;

exit:
	mptcp_set_alpha(mptcp_meta_sk(sk), alpha);
}

Evaluation of LIA on ns3.

 Two subflow is running on disjoint paths.
 Flow3 is a reno flow.
 Sending rate synamic,mp denotes the total throughput of multipath session:

 Rate calculated at receiver side. flow1 and flow4 is the two subfow of lia session. flow4 sharing path with single Reno flow3.
 And flow3 can gain better throughput. Due to the existence of multipath session, the throughput of single path session and multipath session is improved.

 If you are interested, some other coupled congestion control algorithms for multipath transmission are also introducted and evaluated in [6,7,8]。
[1] Coupled Congestion Control for Multipath Transport Protocols
[2] AIMD吞吐量公式的推导
[3] mptcp_coupled.c https://github.com/multipath-tcp/mptcp/blob/mptcp_v0.95/net/mptcp/mptcp_coupled.c
[4] Shared Bottleneck-Based Congestion Control and Packet Scheduling for Multipath TC
[5] Packet Scheduling in Multipath TCP: Fundamentals, Lessons, and Opportunities
[6] Evaluation multipath weswood congestion control on ns3
[7] Evaluate multipath BBR congestion control on ns3
[8] Evaluate multipath balia congestion control on ns3
[9] Evaluate multipath olia congestion control on ns3