作為rate-based的TCP BBR

語言: CN / TW / HK

絕對多數cc都是cwnd-based,rate-based cc一直只是理論。

BBR屬rate-based,看樣子cwnd便無用了,但現實中,cwnd仍作為secondary control parameter起作用:

A secondary parameter, cwnd_gain, bounds inflight to a small multiple of the BDP to handle common network and receiver pathologies (see the later section on Delayed and Stretched ACKs).

若重構BBR,必須忘掉cwnd,雖Delayed & Stretched ACKs場景,亦可忽略cwnd,完全依測量值delivery rate計算pacing rate:

但BBR始終存在cwnd約束,源自範雅各布森。沒有任何證據和理由表明必須用cwnd進行擁塞控制。為什麼不能徹底放棄cwnd呢?

以資料包守恆展開。

進入TCP_CA_Recovery狀態,BBR開始資料包守恆,限制cwnd可做到。這實屬繼承了Reno/CUBIC的策略,BBR聲稱對丟包不敏感,但還是敏感了。總之,我以為BBR在TCP_CA_Recovery狀態資料包守恆徒增複雜,沒有必要,且不應如此處理。

相反一面,若順著cwnd約束的意義說,也有道理:

  • 非擁塞丟包,10 rounds內很快就能restore cwnd,不傷大雅。
  • 有新流侵入,堅持10 rounds後會採集到新分配的bandwidth。

但仔細推敲就發現不對:

  • 若有新流侵入導致擁塞,堅持10 rounds太久,丟包會帶來更高重傳率。
  • 10 rounds之後,新採bandwidth可能是cwnd限制導致而非實際頻寬採集。
  • 資料包守恆終究要restore,但新流侵入場景並不適合restore。

另一面,從資料包守恆本身來講,也不對:

  • 資料包守恆僅約束自己,對新流侵入場景,便無意義。
  • 資料包守恆基於inflight,基於lost計數,它屬預測計數。

基於預測計數做策略,不可行:

  • 預測lost計數較實際偏多,inflight會偏小,retrans會偏多,重傳率偏高。
  • 預測lost計數較實際偏少,inflight會偏大,retrans會過慢,恢復期過久。

高低都不行,資料包守恆無法收斂到最優解,向兩個糟糕發散。除非預測準確,而這不可能。

但資料包守恆工作得很不錯,我認為它只是守住了一個下界,避免事情變糟。嘗試放棄cwnd後效果不佳並不意味著這不可行,我們可能尚未找到正確的方法。

以下隨便看看。

若果真徹底放棄cwnd,不妨嘗試影響AQM:

  • 若無丟包,則完全按照delivery rate計算max-filtered bandwidth。
  • 若丟包,則使用乘法減小max-filtered bandwidth後的pacing rate。

乘法減小pacing rate可加大queue中資料包之間的gap並減少資料包總量,影響顯著:

  • 加大資料包gap,AQM丟本流資料包的概率將減小。
  • 減少資料包數量,可促進queue排空。

若非擁塞噪聲丟包,max-filtered bandwidth尚未滑走,丟包恢復後可繼續使用,若新流侵入或出現突發擁塞,max-filtered bandwidth總會滑走,期間乘法減小的pacing rate確保兩點:

  • 資料包gap增加,故當前流丟包不會加重。
  • 資料包總量減少,故當前流不會製造擁塞。

待擁塞解除,從乘法減小後的rate處重新probe,頗有AIMD的意思(真的AIMD需要用pacing rate和minRTT換算成BDP再用currRTT反算pacing rate),對待全域性公平性也有幫助。

應對持續擁塞時AQM隨機丟包,散開單流的資料包十分重要,這將降低AQM考察時間gap時命中丟包的概率。總之,rate-based才能避免擁塞已經發生時丟包加劇,使用cwnd限制並不能緩解。

必須強調,純粹的rate-based並非對大家都有益,pacing對網路友好但全憑CPU精準調製,便對主機無益,burst與pacing相對,便是主機網路優化的常用手段,CPU將一個長報文一次性送往網絡卡切割成資料包(如TSO),此舉有效提高了主機吞吐但卻必須將切割而成的多個數據包一併burst發出,便與pacing相悖了。最多容忍多少資料包burst,便又是另一種trade-off了。

難道最理想情況不是要基於bit做pacing嗎?至少也要是byte,但網路協議的PDU單位是資料包,到處都需要trade-off。

BBR保留cwnd control parameter的必要性,一開始我就存疑,但屢次與人交流間我竟無言以對,我想這是我的無知,但再重啟問題又覺得不對,於是如此反覆。已經存在了30年的cwnd-based cc是範雅各布森(Van Jacobson)的傑作,它被解釋了30年,已經成了正規化,無論如何能找到一個合理的理由辯證它存在的必要性都是容易的,拋棄它卻顯得不合常規。寫點自己的想法。

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