一周一论文（翻译）——[SIGMOD 2015] TIMELY RTT-based Congestion Control for the Datacenter
本文主要解決的問題是在，基于優(yōu)先級(jí)的擁塞控制PFC是一種粗粒度的機(jī)制，它主要是通過檢測(cè)優(yōu)先級(jí)隊(duì)列的長度是否超過閾值，然后再發(fā)送PFC擁塞信號(hào)幀來進(jìn)行流量控制。這種做法會(huì)帶來不公平性以及行頭阻塞等問題。作者表明，單的數(shù)據(jù)包延遲（以主機(jī)的往返時(shí)間來衡量）是一種有效的擁塞信號(hào)。因此作者通過對(duì)延遲梯度或排隊(duì)隨時(shí)間變化的微分做出反應(yīng)，以在提供高帶寬的同時(shí)保持較低的數(shù)據(jù)包延遲。
Abstract
?????? 數(shù)據(jù)中心傳輸旨在提供低延遲的消息傳遞和高吞吐量。我們表明，簡單的數(shù)據(jù)包延遲（以主機(jī)的往返時(shí)間來衡量）是一種有效的擁塞信號(hào)，無需交換機(jī)反饋。首先，我們證明了NIC硬件的進(jìn)步使得RTT的測(cè)量精度達(dá)到了微秒級(jí)，并且這些RTT足以估算交換機(jī)的排隊(duì)時(shí)間。然后，我們描述TIMELY如何使用RTT梯度來調(diào)整傳輸速率，以在提供高帶寬的同時(shí)保持較低的數(shù)據(jù)包延遲。我們?cè)诰哂蠴S-by-pass功能的NIC上運(yùn)行的主機(jī)軟件中實(shí)施我們的設(shè)計(jì)。我們展示了在Clos網(wǎng)絡(luò)拓?fù)渖鲜褂枚噙_(dá)數(shù)百臺(tái)機(jī)器進(jìn)行的實(shí)驗(yàn)，它提供了出色的性能：在具有PFC的光纖網(wǎng)絡(luò)上為OS-by-pass消息啟用TIMELY可將99％的尾部延遲降低9倍，同時(shí)保持接近線速的吞吐量。我們的系統(tǒng)還優(yōu)于在優(yōu)化內(nèi)核中運(yùn)行的DCTCP，將尾部延遲減少了13倍。據(jù)我們所知，TIMELY是第一個(gè)用于數(shù)據(jù)中心的基于延遲的擁塞控制協(xié)議，盡管它的RTT信號(hào)（由于NIC卸載）比以前的基于延遲的方案少了一個(gè)數(shù)量級(jí)，但是TIMELY仍能實(shí)現(xiàn)其結(jié)果。
1. Introduction
?????? 數(shù)據(jù)中心網(wǎng)絡(luò)運(yùn)行緊密耦合的計(jì)算任務(wù)，這些任務(wù)必須響應(yīng)用戶，例如，成千上萬臺(tái)后端計(jì)算機(jī)可能會(huì)交換信息來滿足用戶請(qǐng)求，并且所有傳輸必須足夠快地完成，以使完整的響應(yīng)得到滿足 100毫秒[24]。 為了滿足這些要求，即使這些方面的性能不一致，數(shù)據(jù)中心傳輸也必須同時(shí)提供高帶寬（？Gbps）和低延遲（？msec）的利用率。 始終具有較低的延遲很重要，因?yàn)榧词故且恍〔糠值暮笃诓僮饕矔?huì)引起連鎖反應(yīng)，從而降低應(yīng)用程序性能[21]。 結(jié)果，數(shù)據(jù)中心傳輸必須嚴(yán)格限制延遲和數(shù)據(jù)包丟失。
?????? 由于傳統(tǒng)的基于損耗的傳輸無法滿足這些嚴(yán)格的要求，因此新的數(shù)據(jù)中心傳輸[10、18、30、35、37、47]利用網(wǎng)絡(luò)支持來發(fā)信號(hào)通知擁塞的發(fā)生（例如，DCTCP [35] 及其后續(xù)產(chǎn)品使用ECN），引入流抽象以最大程度地減少完成延遲，將調(diào)度放到中央控制器等。 然而，在本文的工作中，我們會(huì)退后一步來尋找更簡單，可立即部署的設(shè)計(jì)。
?????? 我們搜索的關(guān)鍵是擁塞信號(hào)。 理想信號(hào)將具有多個(gè)屬性。 快速通知發(fā)送者有關(guān)擁塞程度的信息將是及時(shí)的。 這足以在具有多個(gè)流量類別的復(fù)雜環(huán)境中工作。 并且，這將易于部署。
?????? 令人驚訝的是，我們發(fā)現(xiàn)經(jīng)過適當(dāng)調(diào)整的眾所周知的信號(hào)可以滿足我們的所有目標(biāo)：RTT測(cè)量形式的延遲。 RTT是每次確認(rèn)后都會(huì)細(xì)化的擁塞度量。 它為低優(yōu)先級(jí)傳輸提供了通貨膨脹的衡量標(biāo)準(zhǔn)，從而有效地支持了多種流量類別，而這些優(yōu)先級(jí)傳輸卻落后于高優(yōu)先級(jí)的傳輸。 此外，它不需要網(wǎng)絡(luò)交換機(jī)的支持。
?????? 至少從TCP Vegas開始，就已經(jīng)在廣域Internet中探索了延遲[16]，并且一些現(xiàn)代TCP變體使用延遲估計(jì)[44，46]。 但是這種延遲的使用并非沒有問題。 基于延遲的方案往往與更具攻擊性的基于損失的方案競(jìng)爭較弱，并且由于主機(jī)和網(wǎng)絡(luò)問題（例如，延遲的ACK和不同的路徑），延遲估計(jì)可能非常不準(zhǔn)確。 由于這些原因，在混合方案中通常將延遲與其他指標(biāo)（例如損耗）一起使用。
?????? 此外，由于數(shù)據(jù)中心RTT難以以微秒的粒度進(jìn)行測(cè)量，因此延遲尚未在數(shù)據(jù)中心用作擁塞信號(hào)。 主機(jī)延遲（例如對(duì)確認(rèn)的中斷處理）很容易使這種精度水平不堪重負(fù)。 DCTCP避開了基于延遲的方案，該方案說：“對(duì)排隊(duì)延遲中如此小的增加進(jìn)行準(zhǔn)確的測(cè)量是一項(xiàng)艱巨的任務(wù)。” [35]
?????? 我們的見解是，NIC的最新發(fā)展確實(shí)允許以足夠的精度來測(cè)量數(shù)據(jù)中心RTT，而使用延遲作為擁塞信號(hào)的廣域陷阱并不適用。 最近的NIC為數(shù)據(jù)包事件的高質(zhì)量時(shí)間戳提供了硬件支持[1、3、5、8、9]，以及由硬件生成的ACK，這些ACK消除了不可預(yù)測(cè)的主機(jī)響應(yīng)延遲。 同時(shí)，可以控制數(shù)據(jù)中心主機(jī)軟件以避免與其他傳輸競(jìng)爭，并且多條路徑具有相似的，較小的傳播延遲。
?????? 在本文中，我們證明了基于延遲的擁塞控制在數(shù)據(jù)中心中提供了出色的性能。 我們的主要貢獻(xiàn)包括：
2. THEVALUE OFRTT AS A CONGESTION SIGNAL IN DATACENTERS
?????? 現(xiàn)有的數(shù)據(jù)中心傳輸使用來自網(wǎng)絡(luò)交換機(jī)的信號(hào)來檢測(cè)擁塞的發(fā)生，并以低水平的延遲和丟失來運(yùn)行[15,35,37]。 我們認(rèn)為，無需任何交換機(jī)支持，從RTT測(cè)量得出的網(wǎng)絡(luò)排隊(duì)延遲是一種出色的擁塞信號(hào)。
?????? RTT directly reflects latency. RTT之所以有價(jià)值，是因?yàn)?strong>它們直接衡量我們關(guān)心的數(shù)量：網(wǎng)絡(luò)排隊(duì)導(dǎo)致的端到端延遲。從隊(duì)列占用率得出的信號(hào)（例如ECN）無法直接告知該指標(biāo)。數(shù)據(jù)包上的ECN標(biāo)記僅表示與數(shù)據(jù)包相對(duì)應(yīng)的隊(duì)列度量值超過閾值。數(shù)據(jù)中心中QoS的大量使用意味著不可能將此閾值轉(zhuǎn)換為單個(gè)相應(yīng)的延遲。具有不同優(yōu)先級(jí)的多個(gè)隊(duì)列共享同一輸出鏈路，但是ECN標(biāo)記僅提供有關(guān)占用率超過閾值的隊(duì)列的信息。低優(yōu)先級(jí)的流量可能會(huì)經(jīng)歷較大的排隊(duì)延遲，而不必建立大型隊(duì)列。在這種情況下，排隊(duì)延遲反映了網(wǎng)絡(luò)中的擁塞狀態(tài)，而低優(yōu)先級(jí)流量的隊(duì)列占用率卻沒有反映該問題。此外，ECN標(biāo)記描述了單個(gè)開關(guān)的行為。在利用率很高的網(wǎng)絡(luò)中，擁塞發(fā)生在多個(gè)交換機(jī)上，ECN信號(hào)在它們之間無法區(qū)分。 RTT會(huì)累積有關(guān)端到端路徑的信息。它包括NIC，NIC也可能會(huì)變得很擁擠，但大多數(shù)方案都將其忽略。最后，RTT甚至可以用于通常用于支持FCoE的無損網(wǎng)絡(luò)結(jié)構(gòu)[2]。在這些結(jié)構(gòu)中，由于用于確保零數(shù)據(jù)包丟失的優(yōu)先級(jí)流控制機(jī)制，單純的隊(duì)列占用比例可能無法反映擁塞。
?????? RTT can be measured accurately in practice. 一個(gè)關(guān)鍵的實(shí)踐障礙是，是否可以在數(shù)據(jù)中心中準(zhǔn)確測(cè)量RTT，而在這些數(shù)據(jù)中心中，RTT容易比廣域延遲小1000倍。 過去，很多因素都無法進(jìn)行精確的測(cè)量：內(nèi)核調(diào)度導(dǎo)致的可變性； NIC性能技術(shù)，包括卸載（GSO / TSO，GRO / LRO）； 以及諸如TCP延遲確認(rèn)之類的協(xié)議處理。 在數(shù)據(jù)中心中，這些因素中的每一個(gè)都足夠大，足以壓倒傳播和排隊(duì)延遲，這個(gè)問題就很嚴(yán)重。
?????? 幸運(yùn)的是，最近的NIC為解決這些問題提供了硬件支持[1、3、5、8、9]，并且可以準(zhǔn)確記錄數(shù)據(jù)包發(fā)送和接收的時(shí)間，而不受軟件引起的延遲的影響。 必須謹(jǐn)慎使用這些方法，以免對(duì)NIC造成過多負(fù)擔(dān)。 我們將在本文后面部分描述NIC支持的用法。 這些NIC還為某些協(xié)議提供了基于硬件的確認(rèn)。
?????? 這些功能的組合使我們能夠進(jìn)行精確的RTT測(cè)量，以準(zhǔn)確跟蹤端到端網(wǎng)絡(luò)隊(duì)列。 以下實(shí)驗(yàn)顯示了這種行為：我們通過10 Gbps鏈路將兩臺(tái)主機(jī)連接到同一網(wǎng)絡(luò)，并在靜態(tài)網(wǎng)絡(luò)上發(fā)送16 KB乒乓消息，而不會(huì)發(fā)生任何交叉通信。 由于不存在沖突，因此我們期望RTT測(cè)量值低且穩(wěn)定。 圖1比較了使用NIC硬件時(shí)間戳測(cè)量的RTT的CDF和通過OS TCP堆棧測(cè)量的RTT。 使用NIC時(shí)間戳的RTT的CDF幾乎是一條直線，表明差異很小。 相比之下，內(nèi)核TCP測(cè)得的RTT更大且變化更大。
?????? RTT is a rapid, multi-bit signal. Network。網(wǎng)絡(luò)排隊(duì)延遲可以通過從RTT中減去已知的傳播和串行化延遲來計(jì)算。令人驚訝地，我們發(fā)現(xiàn)，與諸如ECN標(biāo)記之類的顯式網(wǎng)絡(luò)交換機(jī)信號(hào)相比，該方法提供了有關(guān)網(wǎng)絡(luò)交換機(jī)狀態(tài)的更豐富，更快速的信息。作為一個(gè)二進(jìn)制量，ECN標(biāo)記傳達(dá)單個(gè)信息，而RTT測(cè)量傳達(dá)多個(gè)信息，并捕獲跨多個(gè)交換機(jī)匯總的端到端排隊(duì)延遲的全部范圍，而不是在任何情況下都超過簡單固定閾值的排隊(duì)N個(gè)開關(guān)之一。由于每個(gè)數(shù)據(jù)包可能都帶有一個(gè)ECN標(biāo)記，因此標(biāo)記的序列可以縮小此間隙并傳達(dá)有關(guān)擁塞級(jí)別的多位信息，就像在DCTCP中一樣（實(shí)際上是使用ECN的方式）在數(shù)據(jù)中心）。但是，由于宿主源是突發(fā)性的，因此諸如64 KB分段卸載之類的現(xiàn)代實(shí)踐會(huì)破壞及時(shí)制作的標(biāo)記的獨(dú)立性。線速大爆發(fā)往往會(huì)使大多數(shù)數(shù)據(jù)包高于或低于標(biāo)記閾值。
?????? 假設(shè)它是準(zhǔn)確的，那么一次高RTT測(cè)量會(huì)立即發(fā)出擁塞程度的信號(hào)。 這種RTT測(cè)量甚至適用于沿單個(gè)網(wǎng)絡(luò)路徑發(fā)送的流的數(shù)據(jù)包突發(fā)：突發(fā)中最后一個(gè)數(shù)據(jù)包的RTT會(huì)跟蹤整個(gè)數(shù)據(jù)包的最大RTT，因?yàn)閷?duì)較早的數(shù)據(jù)包的延遲會(huì)推后的數(shù)據(jù)包。 為了顯示RTT如何很好地跟蹤網(wǎng)絡(luò)排隊(duì)延遲，我們建立了一個(gè)內(nèi)播實(shí)驗(yàn)，在10個(gè)客戶端計(jì)算機(jī)上同時(shí)傳輸100個(gè)數(shù)據(jù)流，同時(shí)將其傳輸?shù)絾蝹€(gè)服務(wù)器。 為了合并NIC卸載，我們發(fā)送64 KB消息，并且在客戶端每條消息僅收集一次RTT測(cè)量。 瓶頸鏈接是到服務(wù)器的10 Gbps鏈接。 我們每微秒采樣一次交換隊(duì)列。
?????? 圖2顯示了在終端系統(tǒng)上測(cè)得的RTT的CDF與直接在交換機(jī)上測(cè)得的隊(duì)列占用率的比較，并顯示了為10 Gbps鏈路計(jì)算的時(shí)間單位。 這兩個(gè)CDF匹配得非常好。
?????? 相反，ECN信號(hào)與RTT并沒有很好地關(guān)聯(lián)，因此與排隊(duì)量沒有很好的關(guān)聯(lián)。 我們建立了一個(gè)類似的播報(bào)實(shí)驗(yàn)，除了現(xiàn)在的TCP發(fā)送者執(zhí)行向單個(gè)接收者的長傳輸。 瓶頸是到接收器的10 Gbps鏈路，具有80 KB的交換機(jī)ECN標(biāo)記閾值。 我們使用SND_UNA [41]的進(jìn)階來標(biāo)記RTT回合的結(jié)束，從而檢測(cè)發(fā)送方在每個(gè)往返時(shí)間內(nèi)用ECN標(biāo)記接收的數(shù)據(jù)包的比例。 我們還對(duì)每一輪的最小RTT樣本進(jìn)行了測(cè)量，因?yàn)橄惹暗墓ぷ饕呀?jīng)發(fā)現(xiàn)它是一個(gè)可靠的描述符，不受延遲ACK和發(fā)送/接收卸載方案的影響。 圖3中的散布圖和箱形圖1 [4]都只顯示了ECN標(biāo)記分?jǐn)?shù)與RTT之間的弱相關(guān)性。
Limitations of RTTs. 盡管我們發(fā)現(xiàn)RTT信號(hào)很有價(jià)值，但有效的設(shè)計(jì)必須謹(jǐn)慎使用。 RTT測(cè)量會(huì)沿網(wǎng)絡(luò)路徑在兩個(gè)方向上排隊(duì)。 這可能會(huì)使ACK所經(jīng)歷的反向路徑擁塞與數(shù)據(jù)包所經(jīng)歷的正向路徑擁塞相混淆。 一種簡單的解決方法是發(fā)送具有更高優(yōu)先級(jí)的ACK，這樣它們就不會(huì)引起明顯的排隊(duì)延遲。 在通常主要向一個(gè)方向發(fā)送數(shù)據(jù)的流的常見情況下，此方法適用。 我們不需要更復(fù)雜的方法。
?????? 我們進(jìn)行了一項(xiàng)實(shí)驗(yàn)，以驗(yàn)證ACK優(yōu)先級(jí)排序的有效性：我們啟動(dòng)了兩個(gè)Incast（主要和次要），以使主要Incast的ACK與次要Incast的數(shù)據(jù)段共享相同的擁塞隊(duì)列，如圖4所示。 圖5顯示了以下三種情況下來自主播的RTT的CDF：1）ACK路徑中沒有擁塞（無次播）。 2）ACK路徑中存在擁塞； 3）在存在反向擁塞的情況下，將來自主播的ACK優(yōu)先分配給優(yōu)先級(jí)較高的QoS隊(duì)列。 我們發(fā)現(xiàn)反向擁塞在主要鑄件的RTT測(cè)量中產(chǎn)生噪聲，并延長了尾部潛伏期。 主鑄件的吞吐量也受到影響（因此，較低百分位數(shù)中的較小RTT）。 通過ACK優(yōu)先級(jí)排序，在主播中測(cè)得的RTT與在沒有反向路徑擁塞的情況下測(cè)得的RTT是相似的。
?????? 在未來的研究工作中，通過在一個(gè)數(shù)據(jù)包中嵌入一個(gè)時(shí)間戳（例如，TCP時(shí)間戳）來計(jì)算兩個(gè)數(shù)據(jù)包之間的單向延遲的變化將是很簡單的。 排隊(duì)延遲的變化就是到達(dá)時(shí)間的變化減去每個(gè)數(shù)據(jù)包的發(fā)送時(shí)間。 此方法僅需要以相同速率運(yùn)行的時(shí)鐘，這比同步時(shí)鐘的要求要嚴(yán)格得多。
?????? RTT的另一個(gè)經(jīng)典缺點(diǎn)是變化的網(wǎng)絡(luò)路徑具有完全不同的延遲。 由于所有路徑都具有較小的傳播延遲，因此在數(shù)據(jù)中心中的問題較少。
3. TIMELY FRAMEWORK
?????? TIMELY為速率控制提供了一個(gè)框架，該框架與用于可靠性的傳輸協(xié)議無關(guān)。 圖6顯示了它的三個(gè)組成部分：1）RTT測(cè)量以監(jiān)視網(wǎng)絡(luò)的擁塞情況； 2）將RTT信號(hào)轉(zhuǎn)換為目標(biāo)發(fā)送速率的計(jì)算引擎； 3）控制引擎，在各段之間插入延遲以達(dá)到目標(biāo)速率。 我們?cè)诰哂蠳IC硬件支持的主機(jī)軟件中實(shí)現(xiàn)TIMELY，并為每個(gè)flow運(yùn)行一個(gè)獨(dú)立的實(shí)例。
3.1 RTT Measurement Engine
?????? 我們假設(shè)傳統(tǒng)的傳輸方式是接收方明確地確認(rèn)新數(shù)據(jù)，以便我們可以提取RTT。 我們根據(jù)圖7定義RTT，圖7顯示了一條消息的時(shí)間軸：由多個(gè)數(shù)據(jù)包組成的段作為單個(gè)突發(fā)發(fā)送，然后由接收器作為一個(gè)單元進(jìn)行確認(rèn)。 在接收到數(shù)據(jù)段的ACK時(shí)會(huì)生成一個(gè)完成事件，該事件包括ACK接收時(shí)間。 從發(fā)送第一個(gè)數(shù)據(jù)包（發(fā)送）到接收到ACK（完成）的時(shí)間定義為完成時(shí)間。 與TCP不同，一組數(shù)據(jù)包有一個(gè)RTT，而不是每1-2個(gè)數(shù)據(jù)包有一個(gè)RTT。 有幾個(gè)延遲組件：1）傳輸段中所有數(shù)據(jù)包的序列化延遲，通常最大為64 KB； 2）段及其ACK在數(shù)據(jù)中心之間傳播的往返線路延遲； 3）在接收方產(chǎn)生ACK的周轉(zhuǎn)時(shí)間； 和4）雙向交換機(jī)的排隊(duì)延遲。
?????? 我們將RTT定義為僅是傳播和排隊(duì)延遲組件。 第一部分是網(wǎng)段大小和網(wǎng)線速率的確定性函數(shù)。 我們從總經(jīng)過時(shí)間中進(jìn)行計(jì)算并減去，以便輸入到TIMELY費(fèi)率計(jì)算引擎的RTT不受網(wǎng)段大小的影響。 在我們使用基于NIC的ACK的設(shè)置中，第三個(gè)分量足夠接近零，我們可以忽略它。 在其余組件中，第二個(gè)組件是傳播延遲，包括交換機(jī)上基于數(shù)據(jù)包的存儲(chǔ)和轉(zhuǎn)發(fā)行為。 它是最小RTT，對(duì)于給定的流量是固定的。 只有最后一個(gè)部分（排隊(duì)延遲）會(huì)導(dǎo)致RTT發(fā)生變化，這是我們檢測(cè)擁塞的重點(diǎn)。 總而言之，在主機(jī)A上運(yùn)行的TIMELY（如圖7所示）將RTT計(jì)算為：
?????? 例如，在10 Gbps網(wǎng)絡(luò)中，64 KB的串行化需要51 μs，傳播范圍可能是10-100 μs，而1500 B的排隊(duì)需要1.2 μs。 我們依靠兩種形式的NIC支持來精確測(cè)量分段RTT，如下所述。
ACK Timestamps。 我們要求NIC提供完成時(shí)間戳記tcompletion。 如第2節(jié)所示，操作系統(tǒng)時(shí)間戳受調(diào)度和中斷等變化的影響，這些變化很容易掩蓋擁塞信號(hào)。 tsend是在將網(wǎng)段發(fā)布到NIC之前由主機(jī)軟件讀取的NIC硬件時(shí)間。
Prompt ACK generation。 我們需要基于NIC的ACK生成，以便我們可以忽略接收器的周轉(zhuǎn)時(shí)間。 一種替代方法是使用時(shí)間戳來測(cè)量由于主機(jī)處理延遲而導(dǎo)致的ACK周轉(zhuǎn)延遲。 我們避免了此選項(xiàng)，因?yàn)樗鼘⑿枰獢U(kuò)展傳輸線格式以明確包括此差異。
?????? 幸運(yùn)的是，某些現(xiàn)代的NIC [1、3、5、8、9]提供一個(gè)或兩個(gè)功能，并且通過帶有時(shí)間戳段識(shí)別的消息傳遞實(shí)現(xiàn)自然滿足了我們的要求。 §5中描述了RDMA上下文中TIMELY的特定實(shí)現(xiàn)。 我們相信我們的設(shè)計(jì)更普遍地適用于TCP，需要謹(jǐn)慎處理NIC的批處理行為，將ACK與新數(shù)據(jù)的接收正確關(guān)聯(lián)，并補(bǔ)償ACK的周轉(zhuǎn)時(shí)間。
3.2 Rate Computation Engine
?????? 該組件實(shí)現(xiàn)了我們的基于RTT的擁塞控制算法，如§4所述。 速率計(jì)算引擎的接口很簡單。 每次完成事件后，RTT測(cè)量引擎都會(huì)以秒為單位向速率計(jì)算引擎提供RTT。 雖然這是唯一需要的輸入，但是其他定時(shí)信息也可能有用，例如，NIC中的延遲。不需要數(shù)據(jù)包級(jí)別的操作；在正常操作中，由于NIC卸載，我們預(yù)計(jì)單個(gè)完成事件的大小最大為64 KB。 速率計(jì)算引擎在每個(gè)完成事件上運(yùn)行擁塞控制算法，并為流輸出更新的目標(biāo)速率。
3.3 Rate Control Engine
?????? 當(dāng)準(zhǔn)備好發(fā)送一條消息時(shí)，速率控制引擎將其分成多個(gè)段進(jìn)行傳輸，然后將每個(gè)段依次發(fā)送到調(diào)度程序。為了提高運(yùn)行時(shí)效率，我們實(shí)現(xiàn)了一個(gè)可處理所有流的調(diào)度程序。調(diào)度程序使用段大小，流率（由速率計(jì)算引擎提供）和上次傳輸時(shí)間來計(jì)算當(dāng)前段的發(fā)送時(shí)間，并帶有適當(dāng)?shù)钠鸩舆t。然后將該段放在調(diào)度程序中的優(yōu)先級(jí)隊(duì)列中。過去具有發(fā)送時(shí)間的段以循環(huán)方式進(jìn)行服務(wù)；具有未來發(fā)送時(shí)間的段被排隊(duì)。在經(jīng)過定步延遲之后，速率控制引擎將段傳遞到NIC，以作為數(shù)據(jù)包突發(fā)立即傳輸。首先將數(shù)據(jù)批處理為64 KB的段，然后調(diào)度程序計(jì)算定步延遲，以將其插入兩個(gè)此類批處理的段之間。請(qǐng)注意，最大批處理大小是64 KB，而不是必需的，例如，在任何給定時(shí)間僅具有小消息要交換的流的段大小將小于64 KB。稍后，我們還將提供小于64 KB的段大小的結(jié)果。
?????? TIMELY是基于速率的，而不是基于窗口的，因?yàn)榭紤]到NIC卸載的廣泛使用，它可以更好地控制流量突發(fā)。 帶寬延遲乘積在數(shù)據(jù)中心中只是少量的數(shù)據(jù)包突發(fā)，例如，在10 Gbps時(shí)為51 μs是一條64 KB消息。 在這種情況下，窗口不提供對(duì)數(shù)據(jù)包傳輸?shù)募?xì)粒度控制。 通過指定目標(biāo)速率，可以更直接地控制突發(fā)之間的間隔。 為了保障安全，我們將未完成數(shù)據(jù)的數(shù)量限制在靜態(tài)的最壞情況下。
4. TIMELY CONGESTION CONTROL
?????? 我們的擁塞控制算法在速率計(jì)算引擎中運(yùn)行。 在本節(jié)中，我們描述了我們的環(huán)境和關(guān)鍵性能指標(biāo)，然后介紹了基于梯度的方法和算法。
4.1 Metrics and Setting
?????? 數(shù)據(jù)中心網(wǎng)絡(luò)環(huán)境的特點(diǎn)是，通過高帶寬，低延遲路徑上緊密耦合的計(jì)算形式，產(chǎn)生大量突發(fā)消息工作負(fù)載。在許多方面，它與傳統(tǒng)的廣域網(wǎng)相反。帶寬充足，而最重要的是流程計(jì)算時(shí)間（例如，對(duì)于遠(yuǎn)程過程調(diào)用（RPC））。對(duì)于短RPC，最小完成時(shí)間由傳播和序列化延遲確定。因此，我們嘗試最小化任何排隊(duì)延遲以保持RTT低。尾部延遲很重要，因?yàn)楫?dāng)即使一小部分?jǐn)?shù)據(jù)包延遲時(shí)，應(yīng)用性能也會(huì)大幅度下降[21]。一致的低延遲意味著低排隊(duì)延遲和接近零的數(shù)據(jù)包丟失，因?yàn)榛謴?fù)操作可能會(huì)大大增加消息延遲。較長的RPC將具有較大的完成時(shí)間，因?yàn)樵诠蚕砭W(wǎng)絡(luò)上傳輸更多數(shù)據(jù)需要花費(fèi)時(shí)間。為了使增加的時(shí)間保持較小，我們必須保持較高的總吞吐量以使所有流量受益，并保持近似的公平性，從而使任何流量都不會(huì)受到懲罰。
?????? 我們?cè)u(píng)估的主要指標(biāo)是RTT（第99個(gè)百分位）和總吞吐量，因?yàn)樗鼈兇_定我們完成短期和長期RPC的速度（假設(shè)有些公平）。 當(dāng)吞吐量和數(shù)據(jù)包RTT之間存在沖突時(shí)，我們寧愿以犧牲少量帶寬為代價(jià)將RTT保持在較低水平。 這是因?yàn)閹捯婚_始就足夠，RTT的增加直接影響短傳輸?shù)耐瓿蓵r(shí)間。 實(shí)際上，我們?cè)噲D將吞吐量/等待時(shí)間曲線拖延到尾部等待時(shí)間變得不可接受的地步。 次要指標(biāo)是公平性和損失。 我們將二者作為檢查報(bào)告，而不是對(duì)其進(jìn)行詳細(xì)研究。 最后，相對(duì)于較高的平均值，我們更傾向于采用穩(wěn)定的設(shè)計(jì)，但為了可預(yù)測(cè)的性能而采用振蕩速率。
4.2 Delay Gradient Approach Delay-based
?????? 基于時(shí)延的擁塞控制算法，例如FAST TCP [46]和Compound TCP [44]，是受TCP Vegas的基礎(chǔ)工作啟發(fā)的[16]。這些將RTT高于基線的增加解釋為擁塞的指示：如果進(jìn)一步增加延遲以嘗試將瓶頸隊(duì)列的緩沖區(qū)占用保持在某個(gè)預(yù)定義閾值附近，則會(huì)降低發(fā)送速率。然而，凱利等[33]認(rèn)為，當(dāng)隊(duì)列時(shí)間短于控制環(huán)路延遲時(shí)，就不可能控制隊(duì)列大小。在數(shù)據(jù)中心中就是這種情況，在10 Gbps鏈路上，一條64 KB消息的控制環(huán)路延遲至少為51 μs，并且由于競(jìng)爭的流量可能會(huì)大大提高，而一個(gè)排隊(duì)延遲的數(shù)據(jù)包則持續(xù)1 μs。在這種情況下，最多的算法是控制隊(duì)列占用率的分布。即使可以控制隊(duì)列的大小，但為數(shù)據(jù)中心網(wǎng)絡(luò)選擇一個(gè)閾值（其中多個(gè)隊(duì)列可能成為瓶頸）也是眾所周知的難題。
?????? TIMELY的擁塞控制器通過對(duì)延遲梯度或排隊(duì)隨時(shí)間變化的微分做出反應(yīng)，從而實(shí)現(xiàn)了低延遲，而不是試圖保持排隊(duì)。 這是可能的，因?yàn)槲覀兛梢詼?zhǔn)確地測(cè)量表明排隊(duì)延遲發(fā)生變化的RTT的差異。 由于RTT增加而導(dǎo)致的正延遲梯度表示隊(duì)列增加，而負(fù)梯度表示隊(duì)列減少。 通過使用梯度，我們可以對(duì)隊(duì)列增長做出反應(yīng)，而無需等待隊(duì)列的形成–一種有助于我們實(shí)現(xiàn)低延遲的策略。
?????? 延遲梯度是瓶頸隊(duì)列中速率不匹配的代理。 我們受到RCP，XCP，PI和QCN [10、28、32、39]的啟發(fā)，發(fā)現(xiàn)速率不匹配的顯式反饋比僅基于隊(duì)列大小的顯式反饋具有更好的穩(wěn)定性和收斂性。 此后甚至可能導(dǎo)致隊(duì)列的控制精度降低。 關(guān)鍵區(qū)別在于，所有這些現(xiàn)有控制器均在網(wǎng)絡(luò)中的點(diǎn)隊(duì)列中運(yùn)行，而TIMELY通過使用端到端延遲梯度可實(shí)現(xiàn)類似的優(yōu)勢(shì)。
4.3 The Main Algorithm
?????? 算法1顯示了我們的擁塞控制算法的偽代碼。 及時(shí)為每個(gè)連接保持單一速率R（t），并使用RTT樣本在每個(gè)完成事件上更新它。 它采用梯度跟蹤，使用平滑的延遲梯度作為誤差信號(hào)來調(diào)整速率，以保持吞吐量接近可用帶寬。 另外，我們使用閾值來檢測(cè)和響應(yīng)利用率不足或數(shù)據(jù)包延遲過高的極端情況。 圖8顯示了梯度區(qū)域以及兩個(gè)閾值。 當(dāng)RTT在標(biāo)稱工作范圍內(nèi)時(shí)，梯度跟蹤算法會(huì)根據(jù)RTT樣本計(jì)算延遲梯度，并使用它來調(diào)整發(fā)送速率。
?????? Computing the delay gradient.我們依靠使用NIC時(shí)間戳（§3）進(jìn)行準(zhǔn)確的RTT測(cè)量。 為了計(jì)算延遲梯度，TIMELY計(jì)算兩個(gè)連續(xù)RTT樣本之間的差。 我們通過將差除以最小RTT來歸一化，以獲得無量綱的數(shù)量。 實(shí)際上，最小RTT的確切值并不重要，因?yàn)槲覀冎恍枰_定隊(duì)列是在增長還是在減少。 因此，我們使用一個(gè)固定值來表示跨數(shù)據(jù)中心網(wǎng)絡(luò)的導(dǎo)線傳播延遲，這是提前知道的。 最后，我們將結(jié)果通過EWMA過濾器。 該過濾器使我們能夠檢測(cè)隊(duì)列中上升和下降的總體趨勢(shì)，而忽略了不表示擁塞的較小隊(duì)列波動(dòng)
?????? Computing the sending rate. 接下來，及時(shí)使用標(biāo)準(zhǔn)化梯度來更新連接的目標(biāo)速率。 如果梯度為負(fù)或等于零，則網(wǎng)絡(luò)可以跟上傳入的總速率，因此存在更高速率的空間。 在這種情況下，TIMELY通過為連接執(zhí)行加法增量來探測(cè)更多帶寬：R = R +δ，其中δ是帶寬加法增量常數(shù)。 當(dāng)梯度為正時(shí)，總發(fā)送速率大于網(wǎng)絡(luò)容量。 因此，TIMELY會(huì)執(zhí)行乘以速率遞減的β，由梯度因子縮放：
???? 延遲梯度信號(hào)基于總的傳入和傳出速率，對(duì)于同一條擁塞路徑上的所有連接都是通用的。 眾所周知的AIMD屬性可確保我們的算法在所有連接中均達(dá)到公平[19]。 以較高速率發(fā)送的連接的速率下降幅度更大，而所有連接的速率保持不變。
?????? 盡管延遲梯度在正常操作中有效，但利用率嚴(yán)重不足或等待時(shí)間較長的情況需要更積極的響應(yīng)。 接下來，我們討論如何及時(shí)發(fā)現(xiàn)和應(yīng)對(duì)這些情況。
?????? Need for RTT low threshold Tlow. 對(duì)于我們的算法，理想的環(huán)境是對(duì)數(shù)據(jù)包進(jìn)行完美調(diào)整的環(huán)境。 但是，在實(shí)際設(shè)置中，TIMELY速率是根據(jù)可能高達(dá)64 KB的段粒度強(qiáng)制執(zhí)行的。 這些較大的段會(huì)導(dǎo)致數(shù)據(jù)包突發(fā)，從而導(dǎo)致網(wǎng)絡(luò)中的瞬態(tài)隊(duì)列，從而在偶爾發(fā)生沖突時(shí)導(dǎo)致RTT尖峰。 如果不加注意，核心算法會(huì)檢測(cè)到由于RTT突然尖峰而產(chǎn)生的正梯度，并不必要地推斷出擁塞和退避。 我們通過使用低閾值Tlow過濾RTT尖峰來避免這種情況。 對(duì)于大于閾值的RTT樣本，基于延遲梯度開始進(jìn)行調(diào)整。 Tlow是網(wǎng)絡(luò)中使用的段大小的（非線性）增加函數(shù)，因?yàn)檩^大的消息會(huì)導(dǎo)致更多的突發(fā)隊(duì)列占用。 我們?cè)谠u(píng)估中探討了這種影響，并展示了主機(jī)上的細(xì)粒度起搏如何減少突發(fā)性，因此需要較低的閾值。
?????? Need for RTT high threshold Thigh. 核心梯度算法可保持接近瓶頸鏈路吞吐量，同時(shí)建立的隊(duì)列很少。 但是，從理論上講，當(dāng)隊(duì)列保持較高的固定級(jí)別時(shí)，梯度可能會(huì)保持為零。 為了消除這種擔(dān)憂，Thigh作為可容忍的端到端網(wǎng)絡(luò)隊(duì)列延遲（即尾部延遲）的上限。 如果延遲增加，它提供了一種與速率值無關(guān)的降低速率的方法，這是可能的保護(hù)，因?yàn)槲覀冊(cè)诰哂幸阎卣鞯臄?shù)據(jù)中心環(huán)境中運(yùn)行。 如果測(cè)得的RTT大于Thigh，我們會(huì)反復(fù)降低速率：
?????? 請(qǐng)注意，我們使用即時(shí)而不是平滑的RTT。 盡管這看起來很不正常，但我們可以對(duì)單個(gè)過大的RTT進(jìn)行響應(yīng)，從而放慢速度，因?yàn)槲覀兛梢源_信它會(huì)發(fā)出擁塞信號(hào)，而我們的首要任務(wù)是保持低數(shù)據(jù)包延遲并避免丟失。 我們嘗試將平均RTT作為擁塞指標(biāo)進(jìn)行響應(yīng)，發(fā)現(xiàn)由于反饋回路中的額外延遲，它會(huì)損害數(shù)據(jù)包延遲。 等到平均值上升，并且擁塞控制降低速率時(shí)，網(wǎng)絡(luò)中的排隊(duì)延遲已經(jīng)增加。 我們的發(fā)現(xiàn)與[27]一致，后者通過控制理論分析表明，平均隊(duì)列長度是RED AQM的失敗。 我們?cè)凇?中展示了Thigh如何使我們沿著吞吐量-延遲折衷曲線向右移動(dòng)。
?????? Hyperactive increase (HAI) for faster convergence. 受TCP BIC，CUBIC [42]擁塞控制和QCN [10]中最大探測(cè)階段的啟發(fā)，我們提供了HAI選項(xiàng)以加快收斂速度，如下所示：如果經(jīng)過一段緩慢的時(shí)間后TIMELY未達(dá)到新的公平份額 增長，即連續(xù)幾個(gè)完成時(shí)間的負(fù)值，然后HAI切換到更快的加性增長，其中速率增加Nδ而不是δ。 當(dāng)由于網(wǎng)絡(luò)負(fù)載減少而導(dǎo)致新的公平份額急劇增加時(shí)，這很有用。
4.4 Gradient versus Queue Size
?????? 我們通過實(shí)驗(yàn)強(qiáng)調(diào)了梯度方法與基于隊(duì)列大小的方案有何不同。 如果我們?yōu)門low和Thigh設(shè)置相同的值，則TIMELY收斂控制將減少為基于隊(duì)列大小的方法（類似于TCP FAST算法； FAST則是Vegas的縮放改進(jìn)版本）。 將Ttarget表示為該單個(gè)RTT閾值的值，即Ttarget = Tlow = Thigh。 然后，該速率通過隊(duì)列上方Ttarget之上的隊(duì)列大小來縮放，從而增加和增加乘數(shù)減少的速率。
?????? 圖9比較了針對(duì)Incast流量模式的基于梯度和隊(duì)列大小的方法的RTT和吞吐量。 （有關(guān)實(shí)驗(yàn)的詳細(xì)信息，請(qǐng)參見§6。）我們將梯度的上限和下限分別設(shè)為50 μs和500 μs，而隊(duì)列大小的方法將Ttarget設(shè)為50 μs和500 μs。 我們看到隊(duì)列大小方法可以保持低延遲或高吞吐量，但是發(fā)現(xiàn)很難做到這兩種。 通過建立一個(gè)高達(dá)500 μs的高Ttarget的固定隊(duì)列，可以優(yōu)化吞吐量，但以排隊(duì)為代價(jià)的等待時(shí)間為代價(jià)。 另外，通過將站立隊(duì)列保持在50 μs的低Ttarget上，可以優(yōu)化延遲，但由于隊(duì)列有時(shí)為空，因此吞吐量很充足。 通過對(duì)上升和下降隊(duì)列進(jìn)行操作，梯度方法可以預(yù)測(cè)擁塞的發(fā)生。 這使它可以提供高隊(duì)列目標(biāo)的高吞吐量，同時(shí)使尾部等待時(shí)間接近低目標(biāo)。
?????? 此外，如圖10所示，當(dāng)隊(duì)列大小方法將RTT向上和向下推向目標(biāo)隊(duì)列大小時(shí)，其連接速率會(huì)更多地振蕩。 梯度法使公平份額周圍的匯率保持平穩(wěn)。 使用隊(duì)列大小方法和梯度方法，在AQM的控制理論術(shù)語中顯示了相似的結(jié)果[28]。
?????? 主要結(jié)論是，Tlow和Thigh閾值有效地將延遲帶入了目標(biāo)范圍內(nèi)，并且在許多AQM方案中起著類似于目標(biāo)隊(duì)列占用的作用。 使用延遲梯度可以提高穩(wěn)定性，并有助于將等待時(shí)間保持在目標(biāo)范圍內(nèi)。
5. IMPLEMENTATION
?????? 我們的實(shí)現(xiàn)基于具有OS旁路功能的10 Gbps NIC。 NIC支持具有基于硬件的ACK和時(shí)間戳的多數(shù)據(jù)包段。 我們?cè)赗DMA（遠(yuǎn)程直接內(nèi)存訪問）的上下文中實(shí)現(xiàn)了TIMELY，將其作為NIC功能和主機(jī)軟件的組合。 我們使用RDMA原語來調(diào)用NIC服務(wù)，并將完整的內(nèi)存到內(nèi)存的傳輸卸載到NIC。 特別是，我們主要使用RDMA寫入和讀取來從本地主機(jī)內(nèi)存中獲取一條消息，并將其作為突發(fā)數(shù)據(jù)包發(fā)送到網(wǎng)絡(luò)上。 在遠(yuǎn)程主機(jī)上，NIC確認(rèn)收到完整消息，并將其直接放置在遠(yuǎn)程內(nèi)存中以供遠(yuǎn)程應(yīng)用程序使用。 傳輸完成后，將通知本地主機(jī)此確認(rèn)。 我們?cè)谙旅婷枋鰧?shí)現(xiàn)的一些值得注意的地方。
?????? Transport Interface. TIMELY與傳輸協(xié)議的擁塞控制部分有關(guān)。 它與傳輸向應(yīng)用程序公開的可靠性或更高級(jí)別的接口無關(guān)。 這使得與其余傳輸?shù)慕涌谧兊煤唵?#xff1a;消息發(fā)送和接收。 在發(fā)件人處收到消息時(shí)，如果消息很大，則及時(shí)將其分成較小的段，并以目標(biāo)速率發(fā)送這些段。 一條消息只是字節(jié)的有序序列。 該段被傳遞到NIC，然后作為突發(fā)數(shù)據(jù)包通過網(wǎng)絡(luò)發(fā)送。 在遠(yuǎn)程主機(jī)上，NIC確認(rèn)收到完整段。 在接收方，當(dāng)接收到一個(gè)段時(shí)，它將被傳遞到傳輸?shù)钠溆嗖糠诌M(jìn)行處理。 這個(gè)簡單的模型支持從RPC到字節(jié)流（例如TCP）的傳輸
?????? Using NIC Completions for RTT Measurement. 實(shí)際上，使用NIC時(shí)間戳具有挑戰(zhàn)性。我們的NIC僅記錄多數(shù)據(jù)包操作完成的絕對(duì)時(shí)間戳，因此我們的用戶空間軟件需要記錄操作何時(shí)發(fā)布到NIC的時(shí)間戳。這需要一種將主機(jī)時(shí)鐘映射到NIC時(shí)鐘以及進(jìn)行校準(zhǔn)的方案。我們將工作發(fā)布到NIC時(shí)記錄主機(jī)（CPU）時(shí)間戳，并建立一種校準(zhǔn)機(jī)制以將NIC時(shí)間戳映射到主機(jī)時(shí)間戳。一個(gè)簡單的線性映射就足夠了。該機(jī)制之所以有效，是因?yàn)樵谟涗浿鳈C(jī)發(fā)送時(shí)間戳和將消息實(shí)際發(fā)送到NIC之間被中斷的可能性相當(dāng)?shù)汀D11比較了從NIC HW時(shí)間戳，校準(zhǔn)機(jī)制和純軟件時(shí)間戳獲得的RTT。請(qǐng)注意，TIMELY不會(huì)旋轉(zhuǎn)，因此中斷和喚醒都包含在軟件時(shí)間戳中。它清楚地表明，校準(zhǔn)機(jī)制與僅使用NIC時(shí)間戳一樣準(zhǔn)確。此外，SW時(shí)間戳具有較大的方差，隨主機(jī)負(fù)載的增加而增加。
?????? 我們認(rèn)為發(fā)生的任何NIC排隊(duì)都是RTT信號(hào)的一部分。 這很重要，因?yàn)镹IC排隊(duì)還表示擁塞，并且由與網(wǎng)絡(luò)排隊(duì)相同的基于速率的控制來處理-即使NIC為我們提供了實(shí)際的發(fā)送時(shí)間戳，我們還是希望能夠觀察NIC排隊(duì)。
?????? RDMA rate control. 對(duì)于RDMA寫操作，發(fā)送器上的TIMELY直接控制段起搏速度。 對(duì)于RDMA讀取，接收器發(fā)出讀取請(qǐng)求，作為響應(yīng)，遠(yuǎn)程主機(jī)執(zhí)行數(shù)據(jù)段的DMA。 在這種情況下，TIMELY無法直接調(diào)整數(shù)據(jù)段的速度，而是通過調(diào)整讀取請(qǐng)求的步調(diào)來達(dá)到相同的結(jié)果：在計(jì)算讀取請(qǐng)求之間的調(diào)整間隔時(shí)，速率計(jì)算引擎會(huì)考慮從讀取的數(shù)據(jù)段字節(jié) 遠(yuǎn)程主機(jī)。
?????? Application limited behavior. 應(yīng)用程序并不總是具有足夠的數(shù)據(jù)來傳輸以使其流量達(dá)到目標(biāo)速率。 發(fā)生這種情況時(shí)，我們不想無意間增加目標(biāo)速率，因?yàn)榫W(wǎng)絡(luò)似乎沒有擁塞。 為避免此問題，僅當(dāng)應(yīng)用程序發(fā)送的目標(biāo)速率超過目標(biāo)速率的80％時(shí)，才讓目標(biāo)速率增加，并且還將最大目標(biāo)速率限制為10 Gbps。 留出一定空間的目的是讓應(yīng)用程序確實(shí)有足夠的數(shù)據(jù)要發(fā)送時(shí)，在沒有不合理延遲的情況下提高其速率。
?????? Rate update frequency. TIMELY的費(fèi)率更新公式假設(shè)每個(gè)RTT間隔最多有一個(gè)完成事件。 10 Gbps鏈路上64 KB消息的傳輸延遲為51 μs； 最小RTT為20 μs，在任何給定的最小RTT間隔內(nèi)最多可以有一個(gè)完成事件。 但是，對(duì)于較小的段大小，在最小RTT間隔內(nèi)可能會(huì)有多個(gè)完成事件。 在這種情況下，我們希望基于最新信息來更新費(fèi)率。 我們通過更新每個(gè)完成事件的速率來做到這一點(diǎn)，并注意按每個(gè)最小RTT間隔的完成數(shù)量來縮放更新，以免影響新信息。
?????? 為了提高調(diào)度程序的效率，速率控制引擎會(huì)延遲執(zhí)行速率更新。 當(dāng)先前計(jì)算出的段發(fā)送時(shí)間過去時(shí)，調(diào)度程序?qū)z查當(dāng)前速率。 如果速率降低，我們將重新計(jì)算發(fā)送時(shí)間，并在適當(dāng)?shù)那闆r下重新排隊(duì)該段。 否則，調(diào)度程序繼續(xù)將網(wǎng)段發(fā)送到NIC。
?????? Additional pacing opportunities. 缺省情況下，NIC以鏈接線路速率將段作為數(shù)據(jù)包突發(fā)發(fā)送。我們探索了另一種可能性：使用NIC速率限制器以小于線路速率的速率發(fā)送突發(fā)數(shù)據(jù)包。基本原理是使用NIC大小的工作單元來補(bǔ)充調(diào)速引擎，該引擎將流的數(shù)據(jù)包隨時(shí)間傳播。使用硬件速率限制器[43]，將部分起搏責(zé)任轉(zhuǎn)移到NIC是可行的。但是，由于硬件的限制，每隔幾個(gè)RTT重新配置起搏率并不總是可行的。取而代之的是，我們使用一種混合方法：大型網(wǎng)段的軟件步調(diào)和鏈接速率以下的固定速率的硬件步調(diào)，例如10 Gbps鏈路上的5 Gbps。在這些高速率下，NIC步調(diào)的目的是在突發(fā)中插入間隙，以便多個(gè)突發(fā)在交換機(jī)上混合而不會(huì)引起延遲尖峰。在這種情況下，速率控制引擎通過將其視為較低的傳輸線速率來補(bǔ)償NIC起搏延遲。
6. Related Work
?????? 數(shù)據(jù)中心擁塞控制是一個(gè)深入研究的話題[15，18，35，37，38，47]。 及時(shí)關(guān)注相同的問題。
?????? RED [23]和CoDel [40]提早丟棄數(shù)據(jù)包，促使發(fā)送方降低傳輸速率，以避免與拖尾相關(guān)的龐大的排隊(duì)隊(duì)列。 但是，丟失仍然會(huì)增加遇到丟包的流的等待時(shí)間。 為了避免數(shù)據(jù)包丟失，許多方案都依靠ECN形式的交換機(jī)支持，其中將數(shù)據(jù)包標(biāo)記為指示擁塞[22]。 ECN標(biāo)記通常跨多個(gè)數(shù)據(jù)包組合[15、35、37]以提供細(xì)粒度的擁塞信息，但是我們?cè)凇?中的實(shí)驗(yàn)表明ECN具有固有的局限性。 還有其他一些依賴交換機(jī)支持來緩解擁塞的提議，例如QCN [29]（細(xì)粒度的隊(duì)列占用信息）和pFabric [38]（細(xì)粒度的優(yōu)先級(jí)劃分）。
?????? TIMELY屬于另一類算法，該算法使用延遲測(cè)量來檢測(cè)擁塞，而無需交換機(jī)支持。 我們從TCP Vegas，FAST和Compound [16、44、46]中汲取靈感。 這些建議是基于窗口的，并保持接近最小RTT的隊(duì)列。 相比之下，TIMELY是一種基于速率的算法，采用梯度方法，并且不依賴于測(cè)量最小RTT。 我們顯示，即使RTT信號(hào)很少，它也可以很好地支持NIC。
?????? 最近的方案DX [17]獨(dú)立地確定了使用延遲作為高吞吐量和低延遲數(shù)據(jù)中心通信的擁塞信號(hào)的好處。 DX使用用于NIC的DPDK驅(qū)動(dòng)程序?qū)崿F(xiàn)了精確的延遲測(cè)量，并且擁塞控制算法位于Linux TCP堆棧中。 DX算法與傳統(tǒng)的基于窗口的提議相似，其加性增加和乘性減少與平均排隊(duì)延遲成正比。
?????? CAIA延遲梯度[25]（CDG）提出了一種用于廣域網(wǎng)TCP擁塞控制的延遲梯度算法。 其主要目標(biāo)是找出與基于丟失的擁塞控制并存的情況。 因此，其算法的性質(zhì)與TIMELY中的算法不同。
?????? 鏈路層流控制用于Infiniband和數(shù)據(jù)中心橋接（DCB）網(wǎng)絡(luò)中的低延遲消息傳遞。但是，文獻(xiàn)[20，36]記錄了優(yōu)先流控制（PFC）的問題，包括行頭阻塞和暫停傳播或擁塞擴(kuò)散。最近的一些建議旨在使用ECN標(biāo)記來解決PFC的這些問題，以保持較低的隊(duì)列占用率。 TCP-Bolt [14]在內(nèi)核TCP堆棧中使用了經(jīng)過修改的DCTCP算法。 DCQCN [48]將ECN標(biāo)記與NIC中實(shí)現(xiàn)的QCN啟發(fā)的基于速率的擁塞控制算法結(jié)合使用。評(píng)估表明，它可以解決PFC的HoL阻塞和不公平問題，從而使RoCE可以大規(guī)模部署。 TIMELY使用RTT信號(hào)，在支持NIC時(shí)間戳的主機(jī)軟件中實(shí)現(xiàn)，并且適用于OS旁路和基于OS的傳輸。在擁塞控制和CPU利用率方面對(duì)TIMELY和DCQCN進(jìn)行比較是一個(gè)有趣的未來工作。
?????? 通過使用分布式方法[18,47]甚至是集中式方法[30]調(diào)度傳輸，也可以避免擁塞。 但是，這種方案尚待大規(guī)模驗(yàn)證，并且比基于簡單延遲的方法更為復(fù)雜。
?????? 最后，諸如Conga [13]和FlowBender [11]之類的負(fù)載敏感路由可以通過在網(wǎng)絡(luò)上分散流量來緩解擁塞熱點(diǎn)，從而提高吞吐量。 但是，仍然需要基于主機(jī)的擁塞控制，以將提供的負(fù)載與網(wǎng)絡(luò)容量相匹配。
7. CONCLUSION
傳統(tǒng)觀點(diǎn)認(rèn)為，延遲是數(shù)據(jù)中心中不可信任的擁塞信號(hào)。 我們?cè)赥IMELY方面的經(jīng)驗(yàn)表明，情況恰恰相反-如果適當(dāng)?shù)卣{(diào)整了延遲，則RTT與網(wǎng)絡(luò)中的隊(duì)列建立密切相關(guān)。 我們構(gòu)建了TIMELY，它利用現(xiàn)代NIC支持的時(shí)間戳和快速的ACK周轉(zhuǎn)功能，基于精確的RTT測(cè)量來執(zhí)行擁塞控制。 我們發(fā)現(xiàn)，即使在不經(jīng)常使用RTT信號(hào)和NIC卸載的情況下，TIMELY仍可以檢測(cè)并響應(yīng)數(shù)十微秒的排隊(duì)，以實(shí)現(xiàn)低數(shù)據(jù)包延遲和高吞吐量。 隨著數(shù)據(jù)中心速度的提高一個(gè)數(shù)量級(jí)，未來的工作應(yīng)該集中在有效的RTT持續(xù)用于擁塞控制上，同時(shí)重新考慮基于延遲的算法的本質(zhì)。
?
總結(jié)
以上是生活随笔為你收集整理的一周一论文（翻译）——[SIGMOD 2015] TIMELY RTT-based Congestion Control for the Datacenter的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 一周一论文（翻译）——[SIGMOD 2
- 下一篇： 深入浅出全面解析RDMA