摘要
CUBIC是當前TCP標準的擴展硕并。它與現(xiàn)有的TCP標準僅在發(fā)送方的擁塞控制算法上有所不同秧荆。特別地乙濒,它采用了三次函數(shù)代替了現(xiàn)有TCP標準中的線性窗口增加函數(shù)颁股,提高了在高速長距離網(wǎng)絡(luò)環(huán)境下的可擴展性和穩(wěn)定性。CUBIC及其前身的算法已經(jīng)被Linux作為默認算法使用了很多年诉儒。本文檔提供了CUBIC的規(guī)范忱反,以支持第三方實現(xiàn)温算,并通過對CUBIC性能的實驗來征求社區(qū)反饋注竿。
此 Memo 的狀態(tài)
本文件不是互聯(lián)網(wǎng)標準跟蹤規(guī)范魂贬;它是為了提供信息而出版的随橘。
本文檔是Internet工程任務(wù)組(IETF)的產(chǎn)品机蔗。它代表了IETF社區(qū)的共識甘萧。它已經(jīng)收到了公眾的審查扬卷,并已批準出版的互聯(lián)網(wǎng)工程指導(dǎo)小組(IESG)怪得。并非所有IESG批準的文件都適用于任何級別的互聯(lián)網(wǎng)標準徒恋;見RFC 7841第2節(jié)入挣。
有關(guān)本文件的當前狀態(tài)硝拧、任何勘誤表以及如何提供反饋的信息障陶,請訪問https://www.rfc-editor.org/info/rfc8312.
1. 介紹
TCP在快速長距離網(wǎng)絡(luò)中的低利用率問題在[K03]和[RFC3649]中有很好的描述抱究。這個問題產(chǎn)生于在具有大帶寬延遲積(BDP)的網(wǎng)絡(luò)中媳维,擁塞事件之后擁塞窗口的緩慢增加遏暴,在 [HKLRX06] 指出朋凉,即使在數(shù)百個數(shù)據(jù)包的擁塞窗口大小范圍內(nèi)杂彭,也經(jīng)常觀察到這個問題亲怠。這個問題同樣適用于所有 Reno 風格的TCP標準及其變體,包括TCP-Reno[RFC5681]主胧、TCP-NewReno[RFC6582][RFC6675]踪栋、SCTP[RFC4960]和TFRC[RFC5348]夷都,它們使用相同的線性增加函數(shù)進行窗口增長囤官,我們在下文中將它們統(tǒng)稱為“標準TCP”(Standard TCP)治拿。
CUBIC最初是在 [HRX08] 中提出的,它是對標準TCP擁塞控制算法的一種改進见坑。本文檔描述了CUBIC的最新規(guī)范荞驴。具體來說熊楼,CUBIC使用了一個CUBIC函數(shù)來代替標準TCP的線性窗口增加函數(shù)鲫骗,以提高在快速和長距離網(wǎng)絡(luò)下的可擴展性和穩(wěn)定性执泰。
Binary-Increase擁塞控制(BIC-TCP)[XHR04] 是CUBIC的前身渡蜻,在2005年被Linux選為默認的TCP擁塞控制算法茸苇,已經(jīng)被整個互聯(lián)網(wǎng)社區(qū)使用了好幾年学密。CUBIC使用了與BIC-TCP類似的窗口增加功能腻暮,在保持BIC-TCP的優(yōu)勢(如穩(wěn)定性、窗口可伸縮性和RTT公平性)的同時叫惊,它在帶寬使用方面比BIC-TCP更具攻擊性和公平性霍狰。CUBIC已經(jīng)取代BIC-TCP成為Linux中默認的TCP擁塞控制算法饰及,并被Linux全局部署燎含。通過在各種互聯(lián)網(wǎng)場景中的廣泛測試屏箍,我們相信CUBIC在全球互聯(lián)網(wǎng)上的測試和部署是安全的赴魁。
在接下來的章節(jié)中颖御,我們首先簡要說明了CUBIC的設(shè)計原則潘拱,然后提供了CUBIC的確切規(guī)格,最后根據(jù)[RFC5033]中規(guī)定的指南討論了CUBIC的安全特性瘪弓。
2. 約定
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的關(guān)鍵詞“必須”月褥、“不得”、“必須”舀透、“應(yīng)”愕够、“不應(yīng)”惑芭、“應(yīng)”遂跟、“不應(yīng)”幻锁、“建議”哄尔、“不建議”岭接、“可”和“可選”在所有大寫字母出現(xiàn)時(且僅在所有大寫字母出現(xiàn)時)應(yīng)按照BCP 14[RFC2119][RFC8174]的規(guī)定進行解釋亿傅,如下所示葵擎。
3. CUBIC 設(shè)計原理
CUBIC遵循以下設(shè)計原則:
原則1:為了更好的網(wǎng)絡(luò)利用率和穩(wěn)定性酬滤,CUBIC使用了一個三次函數(shù)的凹凸曲線來增加擁塞窗口的大小盯串,而不是僅僅使用一個凸函數(shù)。
原則2:為了對TCP友好,CUBIC被設(shè)計成在RTT短河泳、帶寬小拆挥、標準TCP性能好的網(wǎng)絡(luò)中表現(xiàn)得像標準TCP某抓。
原則3:對于RTT公平性,CUBIC被設(shè)計成在具有不同RTT的流之間實現(xiàn)線性帶寬共享崎坊。
原則4:CUBIC適當設(shè)置乘性窗口遞減因子流强,以平衡可伸縮性和收斂速度。
3.1 原則1
為了更好的網(wǎng)絡(luò)利用率和穩(wěn)定性蚕捉,CUBIC使用了一個三次函數(shù)的凹凸曲線來增加擁塞窗口的大小迫淹,而不是僅僅使用一個凸函數(shù)敛熬。
為了更好的網(wǎng)絡(luò)利用率和穩(wěn)定性应民,CUBIC [HRX08] 使用了一個三次函數(shù)來增加窗口繁仁,該函數(shù)根據(jù)距離上一次擁塞事件所經(jīng)過的時間來計算窗口增加的大小归园。大多數(shù)替代標準TCP的擁塞控制算法都使用凸函數(shù)來增加擁塞窗口庸诱,而CUBIC算法同時使用凸函數(shù)和凹函數(shù)來增加窗口朱灿。在通過冗余ACK或顯式擁塞通知(ECN Echo ACKs)[RFC3168] 檢測到擁塞事件母剥,使得窗口減小之后环疼,CUBIC將檢測到擁塞時的窗口大小記錄為 炫隶,并對擁塞窗口進行乘性減少伪阶。在進入擁塞避免階段后栅贴,利用三次函數(shù)的凹形曲線(左邊)增加擁塞窗口檐薯。三次函數(shù)的穩(wěn)定點設(shè)置為 坛缕,窗口大小在到達 之前會遵循三次函數(shù)曲線持續(xù)增長赚楚。在窗口大小達到 之后宠页,三次函數(shù)進入到凸形曲線區(qū)域(右邊)勇皇,窗口大小開始沿著凸形區(qū)域增大敛摘。這種窗口調(diào)整方式(先凹后凸)提高了算法的穩(wěn)定性兄淫,同時保持了較高的網(wǎng)絡(luò)利用率[CEHRX07]捕虽。這是因為窗口大小幾乎保持不變泄私,圍繞著 形成一個穩(wěn)態(tài)區(qū)域捅暴,此時網(wǎng)絡(luò)利用率被認為是最高的蓬痒。在穩(wěn)態(tài)下梧奢,CUBIC的大多數(shù)窗口大小樣本都接近于 亲轨,從而提高了網(wǎng)絡(luò)的利用率和穩(wěn)定性瓶埋。需要注意的是养筒,那些僅使用凸函數(shù)來增加擁塞窗口大小的擁塞控制算法的在接近 時窗口會劇烈增加晕粪,從而在網(wǎng)絡(luò)飽和點附近引入大量的包突發(fā)巫湘,可能導(dǎo)致頻繁的全局丟失同步( global loss synchronizations )。
- => 記錄了早期檢測到擁塞時的窗口大小阅嘶,表征客戶端窗口如果超過這個值太多可能會導(dǎo)致大量丟包讯柔,應(yīng)該盡量的接近并穩(wěn)定在這個值(在穩(wěn)態(tài)階段)魂迄;
- 全局同步:每個發(fā)送方與其他發(fā)送方同時降低和增加傳輸速率的這種模式被稱為“全局同步”捣炬。=> TCP global synchronization
3.2 原則2
為了對TCP友好婿屹,CUBIC被設(shè)計成在RTT短、帶寬小美莫、標準TCP性能好的網(wǎng)絡(luò)中表現(xiàn)得像標準TCP。
CUBIC 通過建立 “TCP友好區(qū)域” 襟铭,使其在較小的 BDP 場景下寒砖,將每個流的公平性提升到標準TCP的水平。注意漠嵌,標準TCP在短RTT和小帶寬(或小BDP)網(wǎng)絡(luò)下表現(xiàn)良好儒鹿,但在具有長RTT和大帶寬(或大BDP)的網(wǎng)絡(luò)中约炎,存在可擴展性問題章钾。標準TCP的另一種擁塞控制算法設(shè)計為在每個流的基礎(chǔ)上對標準TCP友好贱傀,必須在小型BDP網(wǎng)絡(luò)中比在大型BDP網(wǎng)絡(luò)中更有效地增加擁塞窗口魁衙。CUBIC 的侵略性主要取決于窗口縮減前的最大窗口大小 剖淀,小BDP網(wǎng)絡(luò)的 小于大BDP網(wǎng)絡(luò)纵隔。因此,CUBIC在小型BDP網(wǎng)絡(luò)中增加擁塞窗口的力度小于大型BDP網(wǎng)絡(luò)炮姨。因此捌刮,當 CUBIC 算法的三次函數(shù)增加擁塞窗口的力度小于標準TCP時,CUBIC 只遵循標準TCP的窗口大小舒岸,以確保 CUBIC 算法在小型BDP網(wǎng)絡(luò)中至少達到與標準TCP相同的吞吐量绅作。我們將 CUBIC 類似于標準TCP的區(qū)域稱為“TCP友好區(qū)域”。
3.3 原則3
對于RTT公平性蛾派,CUBIC被設(shè)計成在具有不同RTT的流之間實現(xiàn)線性帶寬共享。
具有不同RTT的兩個 CUBIC 流( CUBIC flow ) 的吞吐量比率( ratio )與其RTT比率的倒數(shù)成正比洪乍,其中對于每一個流的吞吐量近似于其擁塞窗口的大小除以其RTT眯杏。具體地說,CUBIC在TCP友好區(qū)之外保持獨立于RTT的窗口增長率壳澳,因此具有不同RTT的流在穩(wěn)定狀態(tài)下在TCP友好區(qū)之外操作時具有相似的擁塞窗口大小役拴。這種線性吞吐率的概念類似于高統(tǒng)計復(fù)用環(huán)境下的標準TCP,在這種環(huán)境下钾埂,數(shù)據(jù)包丟失與單個流量無關(guān)河闰。然而,在低統(tǒng)計復(fù)用環(huán)境下褥紫,具有不同RTT的標準TCP流的吞吐量比與其RTT比的倒數(shù)成二次比例[XHR04]姜性。CUBIC始終確保線性吞吐量比與統(tǒng)計復(fù)用的級別無關(guān)。這是對標準TCP的改進髓考。雖然對不同RTT流的特定吞吐量比率沒有共識部念,但我們認為在有線互聯(lián)網(wǎng)下,使用線性吞吐量比率似乎比使用相等吞吐量(即氨菇,不同RTT流的相同吞吐量)或更高階吞吐量比率(例如:低統(tǒng)計復(fù)用環(huán)境下標準TCP的二次吞吐率)更加合理儡炼。
3.4 原則4
CUBIC適當設(shè)置乘性窗口遞減因子,以平衡可伸縮性和收斂速度查蓉。
為了在可擴展性和收斂速度之間取得平衡乌询,CUBIC將乘性窗口遞減因子設(shè)置為0.7,而標準TCP使用0.5豌研。雖然這提高了CUBIC的可伸縮性妹田,但這種決策的一個副作用是收斂較慢唬党,特別是在低統(tǒng)計復(fù)用環(huán)境下。這種設(shè)計選擇遵循了《高速TCP》(HSTCP)[RFC3649]一書的作者和其他研究人員(例如[GV02])所做的觀察:當前的互聯(lián)網(wǎng)變得更加異步鬼佣,丟失同步頻率更低驶拱,統(tǒng)計復(fù)用率更高。在這種環(huán)境下晶衷,即使嚴格的乘增乘減(MIMD)也可以收斂蓝纲。具有相同RTT的 CUBIC流 總是獨立于統(tǒng)計復(fù)用收斂到相同的吞吐量,從而實現(xiàn)算法內(nèi)公平性晌纫。我們還發(fā)現(xiàn)税迷,在統(tǒng)計復(fù)用充分的環(huán)境下,CUBIC流 的收斂速度是合理的缸匪。
4. CUBIC 擁塞控制
本文檔中所有窗口大小的單位為最大段大形毯(MSS, Maximum Segment Size )的段类溢,所有時間的單位為秒凌蔬。cwnd 表示流的擁塞窗口大小, ssthresh 表示慢啟動閾值闯冷。
4.1 窗口增加函數(shù)
CUBIC通過僅在接收到ACK時增加擁塞窗口來維持標準TCP的確認(ACK)時鐘砂心。它不會對TCP的快速恢復(fù)和重傳進行任何更改,例如TCP NewReno [RFC6582] [RFC6675]蛇耀。在擁塞避免期間辩诞,如果重復(fù)ack檢測到數(shù)據(jù)包丟失或ack使用ECN Echo flags[RFC3168]檢測到網(wǎng)絡(luò)擁塞,CUBIC將更改標準TCP的窗口增加功能纺涤。假設(shè)在上一次擁塞事件中窗口縮小之前的窗口大小為 译暂。
CUBIC使用以下函數(shù)進行窗口的增加:
Eq. 1
其中 C 是一個常數(shù),用于確定高BDP網(wǎng)絡(luò)中窗口增加的侵略性撩炊,t 是從當前擁塞避免開始所經(jīng)過的時間外永, K 是上述函數(shù)將當前窗口大小增加到 所需的時間,如果沒有進一步的擁塞事件拧咳,則使用以下公式計算:
Eq. 2
其中 是CUBIC的乘性遞減因子伯顶,即,當檢測到擁塞事件時骆膝,CUBIC將其 cwnd 減少到 祭衩。我們將在第4.5節(jié)討論如何設(shè)置 ,在第5節(jié)討論如何設(shè)置 C 阅签。
當在擁塞避免期間接收到ACK時掐暮,CUBIC使用 Eq. 1
計算下一RTT期間的窗口增加率 作為擁塞窗口的候選目標值,其中RTT是由標準TCP計算的加權(quán)平均RTT政钟。
根據(jù)當前擁塞窗口大小 cwnd 的值劫乱,CUBIC以三種不同的模式運行:
- TCP友好區(qū)域 织中,確保CUBIC至少達到與標準TCP相同的吞吐量;
- 凹區(qū)域 衷戈,如果 CUBIC 不在TCP友好區(qū)域狭吼,且 cwnd 小于 ;
- 凸區(qū)域 殖妇,如果 CUBIC 不在TCP友好區(qū)域刁笙,且 cwnd 大于 。
下面谦趣,我們將描述CUBIC在每個區(qū)域采取的確切行動疲吸。
4.2 TCP友好區(qū)域
標準TCP在某些類型的網(wǎng)絡(luò)中表現(xiàn)良好,例如前鹅,在短RTT和小帶寬(或小BDP)網(wǎng)絡(luò)下摘悴。在這些網(wǎng)絡(luò)中,我們使用TCP友好區(qū)域來確保CUBIC至少達到與標準TCP相同的吞吐量舰绘。
根據(jù)[FHP00]中的分析蹂喻,設(shè)計了TCP友好區(qū)。分析研究了加法因子為 (每RTT增加一個窗口)捂寿、乘法因子為 (表示為)的加法增乘減(AIMD)算法的性能. 具體地說口四, 的平均擁塞窗口大小可以使用 Eq .3
(其中 )來計算窗口大小,以此來實現(xiàn)與使用AIMD(1秦陋,0.5)的標準TCP相同的平均窗口大小蔓彩。
Eq .3
基于上述分析,CUBIC使用Eq. 4
來估計窗口大小 ( 驳概, 其中 赤嚼, )的 與 以及 ,它實現(xiàn)了與標準TCP相同的平均窗口大小顺又。當在擁塞避免階段收到 ACK 時更卒,( cwnd 可以大于或小于 ),CUBIC 檢查 是否小于 待榔。 如果小于逞壁,則 CUBIC 當前位于TCP友好區(qū)域,在每次收到ACK時锐锣, cwnd 應(yīng)該設(shè)置為 腌闯。
Eq .4
4.3 凹區(qū)域
當在擁塞避免階段接收到ACK時,如果CUBIC不在TCP友好區(qū)域并且 cwnd 小于 雕憔,那么 CUBIC 處于凹區(qū)域姿骏。CUBIC算法處于次區(qū)域時,每收到一個ACK斤彼,cwnd 必須增加 分瘦,其中 使用 Eq. 1
計算蘸泻。
4.4 凸區(qū)域
當在擁塞避免階段接收到ACK時,如果CUBIC不在TCP友好區(qū)域并且 cwnd 大于或等于 嘲玫, 那么 CUBIC 處于凸區(qū)域悦施。凸區(qū)域表示自上一次擁塞事件以來,網(wǎng)絡(luò)條件可能受到了干擾去团,這可能意味著在一些流離開之后抡诞,可用帶寬會增加。由于因特網(wǎng)是高度異步的土陪,所以在不引起可用帶寬的重大變化的情況下昼汗,一定量的擾動總是可能的。在這個區(qū)域鬼雀,CUBIC非常小心顷窒,非常緩慢地增加它的窗口大小。凸函數(shù)曲線確保窗口在開始時增長非常緩慢源哩,并逐漸增加其增長率鞋吉。我們也把這個區(qū)域稱為“最大探測階段”,因為CUBIC正在尋找一個新的 璧疗。CUBIC算法處于次區(qū)域時坯辩,每收到一個ACK馁龟,cwnd 必須增加 崩侠,其中 使用 Eq. 1
計算。
4. 5 乘性減少
當收到三次冗余ACK坷檩、檢測到丟包或收到顯示擁塞控制包時却音,檢測到網(wǎng)絡(luò)擁塞,CUBIC 通過如下步驟更新其 矢炼、 cwnd 和 ssthresh :
其中 應(yīng)設(shè)置為0.7
; // save window size before reduction
; // new slow-start threshold
; // threshold is at least 2 MSS
; // window reduction
W_max = cwnd; // save window size before reduction
ssthresh = cwnd * beta_cubic; // new slow-start threshold
ssthresh = max(ssthresh, 2); // threshold is at least 2 MSS
cwnd = cwnd * beta_cubic; // window reduction
將 設(shè)置為一個大于 0.5 的值的副作用為收斂速度較慢系瓢。我們認為,雖然設(shè)置自適應(yīng)的 可以使得算法更快的收斂句灌,但這將使得 CUBIC 的分析更加困難夷陋。這種自適應(yīng)調(diào)整 是將會在 CUBIC 的下一個版本納入考慮。
4.6 Fast Convergence
為了提高 CUBIC 算法的收斂速度胰锌,我們在 CUBIC 算法中加入了一個啟發(fā)式算法骗绕。當一個新的流加入網(wǎng)絡(luò)時,如果現(xiàn)有的流已經(jīng)使用了網(wǎng)絡(luò)的所有帶寬资昧,那么網(wǎng)絡(luò)中的現(xiàn)有流需要放棄一些帶寬來允許新的流有一些增長的空間酬土。為了加速現(xiàn)有流的帶寬釋放,應(yīng)該實現(xiàn)以下稱為“快速收斂”的機制格带。
通過快速收斂撤缴,當發(fā)生擁塞事件時刹枉,在擁塞窗口的窗口縮小之前,每個流會記住自己在更新 之前最后一個 的值屈呕,我們將其標記為 微宝。
if (W_max < W_last_max){ // should we make room for others
W_last_max = W_max; // remember the last W_max
W_max = W_max*(1.0+beta_cubic)/2.0; // further reduce W_max
} else {
W_last_max = W_max // remember the last W_max
}
在一個擁塞事件發(fā)生時,如果的當前 值小于 虎眨,則表示由于可用帶寬的變化芥吟,該流的飽和點正在減小。然后我們允許這個流通過進一步減少 來釋放更多的帶寬专甩。此操作有效地延長了此流增加其擁塞窗口的時間钟鸵,因為減少 會迫使流更早地達到飽和點。這使得新的流有更多的時間趕上它的擁塞窗口大小涤躲。
4.7 Timeout
在超時的情況下棺耍,CUBIC遵循標準TCP來減少 cwnd [RFC5681],與標準TCP[RFC5681]有一點不同的是种樱,CUBIC 使用 來設(shè)置 ssthresh 蒙袍。
在超時之后的第一次擁塞避免期間,CUBIC使用 Eq. 1
增加其擁塞窗口大小嫩挤,其中 t 是自當前擁塞避免開始以來經(jīng)過的時間害幅, K 被設(shè)置為0,并且 被設(shè)置為當前擁塞避免開始時的擁塞窗口大小岂昭。
4.8 Slow Start
當 cwnd 不大于 ssthresh 時以现,CUBIC必須采用慢啟動算法。在慢啟動算法中约啊,CUBIC可以在一般網(wǎng)絡(luò)中選擇標準TCP慢啟動算法RFC5681邑遏,也可以在快速和長距離網(wǎng)絡(luò)中選擇有限慢啟動算法RFC3742或混合慢啟動算法HR08。
在CUBIC運行混合慢啟動[HR08]的情況下恰矩,它可以退出第一個慢啟動而不引起任何分組丟失记盒,因此是未定義的。在這種特殊情況下外傅,CUBIC切換到擁塞避免并使用 Eq. 1
增大其擁塞窗口大小纪吮,其中 t 是自當前擁塞避免開始以來經(jīng)過的時間,K 被設(shè)置為0萎胰,并且 設(shè)置為當前擁塞避免開始時的擁塞窗口大小碾盟。