TCP 漕河涇演算法(tcp_caohejing)

語言: CN / TW / HK

題目沒意義,要說意義,大致類似於 Vegas,Reno,Tahoe,Westwood,地名。

週三傍晚發一則朋友圈:

總之,名字就是個名字,跟 tcp_vegas,tcp_reno,tcp_tahoe 學的。

模擬高速公路開車,見機行事。總體設計很簡單,傳輸系統在 up 和 down 兩個 state 間轉換:

  • 如果 up 狀態測得實際 delivery rate 增益小於 a%,轉為 down,gain < 1。
  • 如果 down 狀態測得實際 delivery rate 損失大於 b%,轉為 up,gain > 1。

例如,125% 增益下,delivery rate 增量小於 5% 就以 75% 降速(也可連續 2 次,3 次小於 5% 再降速增加魯棒性),一旦降速,delivery rate 肯定降低,降低率大於一定閾值,再改為 125% 增益加速。簡單講就是漫踱步。

Caohejing 演算法把 BBR 的固定狀態機改成視測量增益而動。 同樣擠佔力度,頻寬越大,加速比越小,因此大流總會降速,小流正好向上,直到變成大流,演算法在非同步狀態下輪作屬大概率事件。此即 “微收斂”, 預期公平性非常棒,事實也確實很棒。

也可使用 AIMD,加速用加法,減速用乘法,取消固定收斂時刻,在 up 態,pacing 加法遞增,down 態乘法遞減,同樣觀測 delivery rate 增量,也屬高尚。

先放一個表達大意的程式碼: GitHub - marywangran/tcp-caohejing: TCP 漕河涇演算法

基本就是 Vegas 的變體,在丟包前開始收斂。但還是有大不同。

Vegas 根據 RTT 訊號收斂,而 Caohejing 根據實測頻寬收斂,哪個更靠譜?

Vegas 比 Caohejing 更復雜,但不能說 Vegas 一定比 Caohejing 先進。各種測量,計算的背後是各種不切實際的假設,把理想假設去掉後,就只剩 delivery rate 了。

事情總向著簡單,如手動擋和自動擋汽車,講速率的時候,誰還提什麼操控。

談談丟包和重傳。

對 Caohejing 演算法,擁塞丟包可以自動被發現,因為採集頻寬肯定低了,速率也就降下來了,但這裡問題來了,是保持簡單方式統一處理,還是單獨用資料包守恆處理丟包?若後者,顯然不美,又回老路,但選擇前者,又會被詬病重傳率高。

或許高重傳率就是高頻寬利用率必須付出的代價。高重傳率最終會落實到碳排放,但由於傳輸效率低導致資訊延時到達,消耗的成本將造成同等量級碳排放,一切皆守恆。

端到端協議,獲取鏈路資訊需要代價,換句話說,頻寬探測就需要多發資料,採集反饋,而此行為的風險就是丟包。

so what?

本來我忍不住在 tcp_caohejing_cong_control 函式里加上 if (rs->losses > 0) 判斷的,然後按照資料包守恆原則處理丟包,但放棄了。

我特意在程式碼里加了 conservation 引數,可通過下面命令關閉:

echo 0 >/sys/module/tcp_caohejing/parameters/conservation

關閉後意味著讓演算法根據 delivery rate 自適應收斂,這是高尚的。

浙江溫州皮鞋溼,下雨進水不會胖。