提高 IDC 網路頻寬利用率

語言: CN / TW / HK

提高頻寬利用率和擁塞控制有很多部分是重疊的。在確保擁塞不發生的前提下提高頻寬利用率是擁塞控制的目標之一。

於是,設計一個 “高頻寬利用率的擁塞控制演算法” 就是一件高尚的事。BBR 就聲稱為了提高頻寬利用率而生。現實中真的需要這樣嗎?

對於 IDC 網路這種知根知底相對確定的場景。反而可以換一個方向思考:

  • 與其提高單一演算法的頻寬利用率,不如設計一個退避演算法,檢測到背景流即退避。將優先順序低但又持續的業務流量對映到該演算法。

非常類似 ledbat 和 tcp lp(Low Priority) 演算法,不爭搶,只撿漏。

如此,兩類流量互補,便可以實現擁塞控制的兩個基本全域性目標:

  • 減少全域性擁塞丟包。
  • 減少全域性頻寬浪費。

二者都提高了頻寬利用率。歸根結底就是將業務流排程到演算法的問題。當丟包足夠低,頻寬利用率足夠高,仍然不滿足流量需求,只能擴容。

Aeolus 旨在解決 PCC 面臨的下列問題:

  • 初始化傳輸時沒有 pacing rate 可供參考。
  • 初始化傳輸時需要一個額外 RTT 獲取 credit。

Aeolus 巧妙利用了 ECN 交換機 “丟 Non-ECT 包而放行 ECT 包” 的特性:

  • 第一個 RTT 的包攜帶 Non-ECT ,線速傳送,此後的包攜帶 ECT,以實際情況傳送。
  • 若將發生擁塞,交換機會丟掉 Non-ECT 包,對已經建連的 ECT 流無影響,丟包將在下一個 RTT 重傳。
  • 若未發生擁塞,Non-ECT 包與 ECT 包均通過,對於大多數只需要 1 個 RTT 就完成的事務,收益甚大。

對於第一個 RTT 的包,這也是一種退避互補的演算法:你來了就把頻寬讓給你,你不來我就用。

Aeolus 之所以巧妙,來自於其研發團隊對一個事實的深入調研:

  • 隨著 IDC 頻寬的持續增加,RTT 不變的情況下,每個 RTT 傳輸的資料量持續增加,越來越多的事務將在越來越少的 RTT 內完成。

雖然 Aeolus 針對 PCC,但該思想可用於任何傳輸協議,甚至 TCP。對 PCC,線速傳輸第 1st RTT 的收益在於:

  • 賭贏了即結束,完全受益。
  • 賭輸了,丟包挪到下一個 RTT 重傳且不影響 scheduled 包,與不使用 Aeolus 相比無區別。

這個策略非常高尚。

通過下列命令可對任意資料包設定 ECT,CE,以學 Aeolus 的樣子:

iptables -t mangle -A POSTROUTING ... -j TOS --set-tos 0x00/0x03
iptables -t mangle -A POSTROUTING ... -j TOS --set-tos 0x01/0x03
iptables -t mangle -A POSTROUTING ... -j TOS --set-tos 0x02/0x03
iptables -t mangle -A POSTROUTING ... -j TOS --set-tos 0x03/0x03

當然,也可以修改 DCTCP 演算法。改法不一而足。

Aeolus 的思路很巧妙,但卻並不一定非要在第一個 RTT 內 clear ECT,啟用 ECT 後,在 “任何覺得丟包優於 set CE“ 的時候,均可以 clear ECT。可以統計丟包率,丟包率大於一定閾值時,讓交換機丟包而不是自己控制更能緩解擁塞。

我本想寫一個 Netfilter 模組去 match nf_conntrack 的 account 欄位,將一個 TCP 連線的前 n 個包的 ECT 標誌 clear 掉,想到上述這段話後,就改成 stap -g 了,抓住 sock 之後,更精細判斷丟包率以及別的指標,權衡要不要 clear ECT。

在 IDC 網路,ECN 機制可以非常簡單地輔助區分服務,達到流量分類的目的,在佇列達到一定閾值時,丟 Non-ECT 包而放行 ECT 包,緩解擁塞。問題就轉換成為哪些包 set ECT 了。

IDC 網路擁塞控制要換個思路,不能一味追求端到端演算法的精妙,而要充分利用可以利用的一切基礎設施提供的資訊,比如用額外的流量補充頻寬的浪費,又比如 ECN。週日起得早,買蟹前,寫點思考。

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