Linux TCP PRR 降窗的实现问题至今没人关注

鉴于 CUBIC 还将长时间居于拥塞控制主流地位，针对 AIMD 的 bugfix 和优化还将继续进行并且具有意义，但由于非典型场景人们不易遭遇，很多 bug 即使藏匿在显眼处也被人无视。

观测 AIMD，以 Reno 为例，若 cwnd = 10，遭遇丢包，则 ssthresh = cwnd / 2 = 5，cwnd = ssthresh，变为 5，以此类推，史上共有 3 类知名降窗法，分别为 RFC3517，Linux rate halving 以及 PRR，前两类无异于直接将 cwnd = ssthresh，而 PRR 则执行一个比例兑换的数据包守恒法，逐渐降到 ssthresh，具体参见 Proportional Rate Reduction for TCP，觉得 talk is cheap 的就去看 tcp_cwnd_reduction，不多说。

但 Linux 的实现有问题。

在绝大多数拥塞控制场景，cwnd = ssthresh = (1 - beta) * cwnd 被证明已经足够有效且公平，但在另外一些 “带宽突然降低很多(或者丢包率突然增加很多)” 的场景，该策略就显然有问题。

说该问题是无心错是因为 Linux 实现 3517 和 rate halving 时确实应该在 tcp_end_cwnd_reduction 中执行 cwnd = ssthresh，可是当采用 PRR 时，由于 PRR 已经完成发送速率和交付速率匹配了，即完成丢包重传时，如果 cwnd 比 ssthresh 还小，那 PRR 就是对的，正确的逻辑应该是：

void tcp_end_cwnd_reduction(...)
{
    if (tp->snd_cwnd < tp->snd_ssthresh)
        tp->snd_cwnd = tp->snd_cwnd;
    else
        tp->snd_cwnd = tp->snd_ssthresh;
}

极端但典型的场景，先不考虑 PRR，仅考虑标准 Reno，如果带宽突然降低了 1000 倍，或者丢包率增加了 sqrt(1000) = 31.6 倍(根据 response function 获得)，那么一条 flow 要经历 10 round 的丢包，因为 ${\log }_2\frac{1000}{1}\approx 10$，若使用 PRR，基本上可以一次收敛到目标，但要破坏 MD 原则，因为 PRR 相当于自动地，一次性将 cwnd 收敛到合适的值。

若不认同 PRR 的结果，非要将 cwnd 硬拉到更高的 ssthresh，那几乎还要丢包，然后重新再来几轮，直到 ssthresh 本身被拉低。

为了确认 Linux 实现的问题，写 pbftrace 脚本如下：

#!/usr/bin/bpftrace

#include <net/sock.h>
#include <net/tcp.h>
#include <linux/tcp.h>

//kprobe:tcp_init_cwnd_reduction // 很无奈，该 func 无法 hook
kprobe:tcp_enter_recovery
{
    $sk = (struct sock*)arg0;
    $tp = (struct tcp_sock*)$sk;
    $dport_num = $sk->__sk_common.skc_dport;
    $dport = (($dport_num & 0xFF00) >> 8) | (($dport_num & 0x00FF) << 8);

    if ($dport == 5001) {
        printf("-----------------------------\n");
        printf("cwnd: %d  ssthresh:%d\n", $tp->snd_cwnd, $tp->snd_ssthresh);
    }

}

kprobe:tcp_cwnd_reduction
{
    $sk = (struct sock*)arg0;
    $tp = (struct tcp_sock*)$sk;
    $dport_num = $sk->__sk_common.skc_dport;
    $dport = (($dport_num & 0xFF00) >> 8) | (($dport_num & 0x00FF) << 8);

    if ($dport == 5001) {
        printf("cwnd:%-6u ssthresh:%-6u ", $tp->snd_cwnd, $tp->snd_ssthresh);
        printf("undo:%-3u \n", $tp->undo_marker);
    }
}

运行脚本，本机 iperf 打流，平均吞吐 50Gbps，脚本无输出，说明没有丢包，然后猛一下子载入：

tc qdisc add dev lo root netem loss 5%

观察脚本输出：

cwnd: 25  ssthresh:25
18:53:55 cwnd:25     ssthresh:12     undo:1322883999 
18:53:55 cwnd:2      ssthresh:12     undo:1322883999 
18:53:55 cwnd:3      ssthresh:12     undo:1322883999 
18:53:55 cwnd:4      ssthresh:12     undo:1322883999 
18:53:55 cwnd:5      ssthresh:12     undo:1322883999 
18:53:55 cwnd:6      ssthresh:12     undo:1322883999 
18:53:55 cwnd:6      ssthresh:12     undo:1322883999 
18:53:55 cwnd:5      ssthresh:12     undo:1322883999 
# 以上为一个丝滑的 PRR 过程
-----------------------------
cwnd: 12  ssthresh:12
18:53:55 cwnd:12     ssthresh:6      undo:1326750570 
18:53:55 cwnd:2      ssthresh:6      undo:1326750570 
# 此时已经探测到 cwnd = 2，但由于 cwnd = ssthresh，又重新开始一轮
-----------------------------
cwnd: 6  ssthresh:6
18:53:55 cwnd:6      ssthresh:3      undo:1328126773 
18:53:55 cwnd:2      ssthresh:3      undo:1328126773 
-----------------------------
cwnd: 4  ssthresh:3
18:53:55 cwnd:4      ssthresh:2      undo:1328782239 
18:53:55 cwnd:2      ssthresh:2      undo:1328782239 
-----------------------------
cwnd: 4  ssthresh:2
18:53:55 cwnd:4      ssthresh:2      undo:1329306527 
# 至此才完成收敛！
-----------------------------
cwnd: 4  ssthresh:2
18:53:55 cwnd:4      ssthresh:2      undo:1329830709 
-----------------------------
cwnd: 4  ssthresh:2
18:53:55 cwnd:4      ssthresh:2      undo:1330092959 
18:53:55 cwnd:2      ssthresh:2      undo:1330092959 
-----------------------------
cwnd: 3  ssthresh:2
18:53:55 cwnd:3      ssthresh:2      undo:1330420586 
18:53:55 cwnd:2      ssthresh:2      undo:1330420586 
-----------------------------
cwnd: 4  ssthresh:2
18:53:55 cwnd:4      ssthresh:2      undo:1331207018 
18:53:55 cwnd:2      ssthresh:2      undo:1331207018 

这个问题其实非常典型，上午跑步时，我突然觉得 BBR v2/v3 相比 v1 对 ProbeUP phase 的更新似曾相识，这不就是 PRR 对 RFC3517 和 Linux rate halving 降窗的更新嘛，让发送速率逐渐与交付速率匹配，用一个动态的自适应过程替换 AIMD 算法 ssthresh = (1 - beta) * cwnd
这种固定的规则，正如让动态的 “Probe 到吃力” 替代固定的 1.25*BDP 一样。

很明显，AIMD 并非一定要 per-cycle oneshot，Additive Increase 说明空闲资源尚在，而 Multiplicative Decrease 则需要适配当前可用资源，PRR 之前没这技术，只能靠固定 MD 比例 beta 逼近，而 PRR 显然可以靠守恒兑换一次逼近。正如 PID 控制，PRR 之前的仅是 P 控制，PRR 相当于引入了 I 和 P，不管怎样，都是在 “如何逼近” 上做文章，两个维度，效率和精度。

吐槽一下 Linux 内核调试，虽然 tcp_cwnd_reduction 非常容易 hook，但别高兴太早，无论 bpftrace 还是 stap -g 均无法 hook tcp_end_cwnd_reduction，也无法 hook tcp_init_cwnd_reduction，不是没符号就是显式 inline，这便逼着工人们用微软风格的寄存器玩法或者社区风格的重新编译内核，将大把精力消耗在 debug 技巧本身，而不是验证一个简单的猜想。

不管怎样，这个问题修改很简单，就看谁来改了。我给出一个可能有 bug 的经理解，只改 tcp_end_cwnd_reduction：

static inline void tcp_end_cwnd_reduction(struct sock *sk)
{
        struct tcp_sock *tp = tcp_sk(sk);

        if (inet_csk(sk)->icsk_ca_ops->cong_control)
                return;

        /* Reset cwnd to ssthresh in CWR or Recovery (unless it's undone) */
        if (tp->snd_ssthresh < TCP_INFINITE_SSTHRESH &&
            (inet_csk(sk)->icsk_ca_state == TCP_CA_CWR || tp->undo_marker)) {
                if (tp->snd_ssthresh <= tp->snd_cwnd)
                        tp->snd_cwnd = tp->snd_ssthresh;
                tp->snd_cwnd_stamp = tcp_jiffies32;
        }
        tcp_ca_event(sk, CA_EVENT_COMPLETE_CWR);
}

浙江温州皮鞋湿，下雨进水不会胖。