TCP 擁塞控制之BBR 算法介紹

2016 年 10 月份的一個 youtube 鏈接: Making Linux TCP Fast，首次發(fā)布了 BBR 算法， TCP 擁塞控制開啟了新局面。

BBR 非常簡單，它背后是一個單流理想模型：

但現(xiàn)實(shí)情況并不遵循該模型，所以 BBR 的表現(xiàn)很難兌現(xiàn)承諾，特別在多流場景，公平性難保證，高重傳換吞吐頻繁發(fā)生。

下面是一個過程示意圖：

該表現(xiàn)的根本原因是 “BBR 必須用更多的 inflight 探測潛在帶寬”。而 “更多的 inflight” 和 Loss-based 算法的 AI 過程無異，但卻沒有相應(yīng)的 MD 反饋，這意味著 BBR 流的 inflight 很容易被拉到一個高水位。高水位的 inflight 很容易導(dǎo)致排隊(duì)甚至丟包，而這正是 BBR 目標(biāo)的反面。

多流共享瓶頸帶寬，背景流的侵入和退出以及它們的 AIMD 易對 BBR 造成干擾，BBR 記錄瞬時探測收益，并堅(jiān)持 10-rounds，這種遲鈍反應(yīng)使 BBR 很難維持理想模型的狀態(tài)機(jī)。

BBR 必須考慮更接近現(xiàn)實(shí)的場景，對 inflight 進(jìn)行約束，這就是 BBRv2 的背景。

下面的背景引用來自：Understanding of BBRv2

However, in multiple BBRv1 flows, each sender overestimates the available bandwidth because of the max_filter that is immediately applied as new sending rate; therefore, the total amount of data sent from BBR hosts exceeds the pipe’s capacity, resulting in the standing queue creation. If the buffer sizes are not large enough to store excess data, the packet loss occurs. Moreover, this packet loss persists throughout the entire bandwidth sharing of multiple BBRv1 flows because BBRv1 does not reduce the maximum boundary of the inflight data, no matter how much packet loss occurs. This maximum boundary of the above-mentioned inflight data is the inflight cap, calculated as 2 BDP, and it is used to maintain the maximum throughput and low latency.

BBRv2 的核心在于 “更精確地測量 Delivery rate，并根據(jù)丟包，ECN 信號約束 inflight”。為此，BBRv2 在 ProbeBW 狀態(tài)引入了一個子狀態(tài)機(jī)：

以下是約束細(xì)節(jié)，來自 BBRv2 draft：

下面是一個 BBRv2 的過程示意圖：

驅(qū)動 BBRv2 狀態(tài)機(jī)轉(zhuǎn)換的不再是固定的 phase，而完全基于 “丟包”，“ECN-Mark”，“公平性” 等變量 “隨時” 進(jìn)行 probe up 或 probe down：

實(shí)時跟蹤丟包率與 ECN Mark，實(shí)時調(diào)整 inflight_hi/lo，限制實(shí)際 inflight。

實(shí)時跟蹤丟包率與 ECN Mark，輔以公平性保證，驅(qū)動子狀態(tài)機(jī)狀態(tài)轉(zhuǎn)換。

在 cruise 狀態(tài)，保留 headroom 作為 “公地奉獻(xiàn)”。

BBRv2 專門為 Reno/CUBIC 保留一個 AIMD 周期的時間窗口，該窗口等于 0.5*Max_cwnd = BDP 個 RTT 的時間(具體計(jì)算參考 Jacobson管道)，兩次 probe up 的時間不小于該窗口，同時在明確沒有因 probe up 造成丟包的前提下，又可繼續(xù) probe up。

在上述窗口內(nèi)，BBRv2 執(zhí)行 cruise，對網(wǎng)絡(luò)不注入任何干擾，讓 Reno/CUBIC 安靜 AI，由于 BBR probe up 采用 MI，它只在時間窗口過后，一次性執(zhí)行 MI，在理論上，BBRv2 和 Reno/CUBIC 具有了同樣的 probe 周期，建立了友好共存的基礎(chǔ)。

如 BBRv2 draft 4.3.3.5.1 小節(jié)所述，BBRv2 希望在 DC 和 Internet 都能和 Reno/CUBIC 友好共存，巧合的是，兩類網(wǎng)絡(luò)的典型 BDP 是一致的：

DC 網(wǎng)絡(luò)：40 Gbps / 8 bits-per-Byte * 20 us / (1514 Bytes) ~= 66 packets

Internet：25Mbps / 8 bits-per-Byte * 30 ms / (1514 bytes) ~= 62 packets

probe up 之后大約 60 多個 RTT，BBRv2 便可友好地再次 probe up，這個時間在 Internet 大約 2 secs，在 DC 網(wǎng)絡(luò)大約 1.3 ms。該 Time Scale 不包含固定經(jīng)驗(yàn)值，它是 rounds 的函數(shù)，自適應(yīng)各類網(wǎng)絡(luò)。這是一個事實(shí)上可靠的 BBR/Reno 共存保證。

和 BBRv1 的固定 8-rounds 一輪相比，BBRv2 probe up 間隔時間久了很多。策略是個好策略，但在我看來，現(xiàn)實(shí)場景中，都是異步流，BDP 個 RTT 的 AIMD 周期屬高斯分布的右尾，取其期望均值是高尚的，大約 30～40 個 RTT 很合理。

最近看的一本書《系統(tǒng)之美》，提到 “有限理性” 一詞，也叫 “看不見的腳”，和 亞當(dāng)斯密 的 “看不見的手” 相對?！坝邢蘩硇浴?這個概念完全適用于多流共享帶寬的場景，“有限理性” 的后果就是 “公地悲劇”，各方都在自私地獲利，最終卻分擔(dān)惡果，這顯然對每一方都有利。TCP AIMD 可以完美應(yīng)對 “公地悲劇”，可 BBRv1 并不能。

在一個有限資源的系統(tǒng)中，BBRv2 越來越多地反饋外界背景事件，這是進(jìn)步，而 BBRv1 似乎很少具有全局觀，結(jié)合《系統(tǒng)之美》，BBRv2 正行走在突破 “公地悲劇” 的正確道路上。

單流吞吐雖下降，換取整體效果向善。

有了 TCP 友好性作為基礎(chǔ)，和 Reno/CUBIC 整齊劃一之后，BBRv2 便擁有了長期演進(jìn)的可能性，最終作為 CUBIC 的接力者成為默認(rèn)標(biāo)準(zhǔn)算法。相比之下，BBRv1 僅僅提供了一個新的思路，但它并沒有為實(shí)際部署以及與傳統(tǒng) TCP 流共存做好準(zhǔn)備。

但直到 Linux Kernel v6.1-rc2，也依然不見 BBRv2 合入(相比較而言，BBRv2 在 QUIC 上的進(jìn)度卻快很多)，它依然僅存在于 Google 自己的分支：https://github.com/google/bbr/blob/v2alpha/net/ipv4/tcp_bbr2.c

工作中涉及到 DC 內(nèi)部 TCP cc 演進(jìn)的問題討論，對于短突發(fā)，傾向于調(diào)大 init cwnd 為一個 BDP 左右，傾向于復(fù)用長連接，start from idle 的 cwnd 為 init cwnd。對于長流，傾向于 BBRv2，它確實(shí)比 DCTCP 更具有適應(yīng)性，且包含了 DCTCP 的 feature。記錄一篇，這篇可作為資料查詢，因?yàn)樾味系臇|西不太多(但依然有)。

編輯：黃飛

?