論文閱讀筆記——擁塞控制算法PCC

PCC論文閱讀筆記

本文是關於NSDI '15論文《PCC: Re-architecting Congestion Control for Consistent High Performance》的閱讀筆記。

TCP爲什麼這麼垃圾

In the roughly 25 years since its deployment, TCP’s congestion control architecture has been notorious for degraded performance. TCP performs poorly on lossy links, penalizes high-RTT flows, underutilizes high bandwidth-delay product (BDP) connections, cannot handle rapidly changing networks, can collapse under data center incast [24] and incurs very high latency with bufferbloat [28] in the network.

TCP真的很垃圾。它無法處理高丟包率鏈路、無法適用於高RTT的流、無法有效利用高帶寬鏈路、無法處理高度動態變化的網絡、在數據中心會出現incast問題、而且也導致Bufferbloat等等。

傳統TCP是怎麼幹的

傳統TCP通常依賴於hardwired mapping（這個是什麼鬼？見下文）來控制發送速率。但是網絡狀況實際上是非常複雜的，想要依靠hardwired mapping實現很好的性能是很不實際的。例如，一個簡單的丟包，可能是多個流擁塞造成的，也有可能是隨機丟包，也有可能運氣不好剛好趕上burst造成滿隊列丟包。

Note：hardwired mapping是指提前定義好什麼事件觸發什麼控制動作。如丟包事件觸發了AIMD中的MD。

依賴於hardwired mapping會產生什麼後果呢？

一個錯誤的假設會導致災難性的後果！
舉個例子：一個隨機丟包，如果判斷成擁塞而腰斬發送速率，會極大地降低發送速率。類似地還有很多。

PCC爲什麼牛逼

PCC不採用hardwired mapping，所以不用對網絡進行假設，不用假設丟包到底是什麼造成的。

PCC是怎麼幹的

類似於機器學習，PCC設置一個目標函數，然後不斷地嘗試各種發送速率，最終使得目標函數達到最優。

例如，一開始，當流的發送速率爲r時，它分別以速率(1+ε)r和速率(1-ε)r發送，並觀測計算對應的目標函數，並將速率調整爲取得較優目標函數的值，並以這個方向繼續增大或減小（有點像凸優化中的梯度法），直到該目標函數開始減小。

PCC如何應對噪聲？

採用隨機控制試驗（RCT），這使得PCC能夠更魯棒地對抗噪聲。
例如，以隨機的順序進行對2個速率（速率(1+ε)r和速率(1-ε)r）進行4個測試（每個速率2次）。如果在這4個測試中，某個速率的2組測試的目標函數都比較良好，那麼選擇該速率。若一個好，一個不好，那麼維持現有速率不變。
儘管RCT使得PCC的收斂時間變長了，但這是值得的。RCT幫助PCC做出更優的決策，降低了PCC的速率波動。

PCC如何取得公平性

乍一看，PCC是自私的，因爲它不會像AIMD那樣因爲丟包而主動降低自己的速率讓別的流通過，它似乎無法取得全局的公平性。然而，通過設置一個合適的目標函數，可以使得多個PCC流都可以公平地共享同一條鏈路。
（這裏有一個問題弄不明白：在這種架構下，各種流如何根據優先級等進行加權平均？是否可以通過設置一個合適的目標函數？還是得中間設備支持？）
例如，通過設置目標函數爲
$u_i (x_i) = T_i \cdot Sigmoid_\alpha (L_i - 0.05) - x_i \cdot L_i$
可以實現多PCC流公平性。其中
$Sigmoid_\alpha (y) = \frac {1} {1+\mathrm e ^ {\alpha y}}$
會在y超過0時急速遞減至0。該公式將吞吐量乘以一個因子，再減去丟包得到目標函數。
Note：該目標函數並不是TCP友好的，它會搶佔TCP資源。

PCC非常靈活

通過設置不同的目標函數，發送端可以選擇對時延、丟包率、吞吐量等目標進行優化。注意，這僅僅需要對一行代碼進行修改，這使得PCC非常靈活。

如何部署PCC

要部署PCC只需在發送端對控制算法進行改動。
Note：無需改動路由器，沒有引入新協議，也無需對接收者進行改動。

Note：作者提供了PCC的用戶態PCC實現。

FAQ

• 1. PCC是否能夠與TCP和平共處？
     設置適當的目標函數可以使得他們和平共處。
• 2. 如果大家都故意設置一個利己的目標函數，是否會對網絡生態造成影響？
     大家都知道瀏覽器會打開多個TCP來提高速度，這種行爲其實是相似的，這並不會造成非常嚴重的生態影響。
• 3. 在這種架構下，各種流如何根據優先級等進行加權平均？是否可以通過設置一個合適的目標函數？還是得中間設備支持？
     still don’t know.

總結

PCC通過設置一個目標函數並不斷探測發送速率變化帶來的影響來控制發送端的速率，這樣做不用像傳統TCP一樣對網絡進行假設，不依賴hardwired mapping。但PCC有一個致命的缺點，就是收斂速率太慢。
PCC挖了很多坑。
一個大坑是：如何設置一個有效的目標函數？ 是否存在一個目標函數，它是TCP友好的，而且也能收斂到一個Nash equilibrium點。

最後

PCC出了改進版：PCC Vivace（NSDI '18）。後續讀完PCC Vivace再寫一篇閱讀筆記。