曾高雄 胡水海 張駿雪 陳 凱

(香港科技大學計算機科學與工程系 香港 999077)

近10年來，網絡應用(如搜索、在線零售和云計算等)飛速發(fā)展，對底層基礎設施在計算、存儲和網絡等方面提出了嚴苛的要求.在此驅動下，微軟、谷歌、亞馬遜、臉書、阿里巴巴等大型互聯(lián)網企業(yè)在全球范圍內快速地建立起了高性能數(shù)據中心(data center, DC).這些數(shù)據中心通常采用商用器件，將服務器和交換機通過精心設計的網絡互聯(lián)，從而以更經濟更便捷的方式達到高速計算和海量存儲等需求.在支撐服務的各項技術中，數(shù)據中心網絡(data center network, DCN)是一個潛在且重要的性能瓶頸[1-3]，因而引起了包括學術界和工業(yè)界的廣泛關注.

在這樣的背景下，本文調研了數(shù)據中心網絡的一個核心方面——傳輸層協(xié)議. 本文首先概述了數(shù)據中心網絡環(huán)境下傳輸層協(xié)議設計的機遇和挑戰(zhàn). 在這驅使下，一系列的傳輸協(xié)議被設計提出.隨后將早期(2010—2015年)數(shù)據中心網絡傳輸設計方面的工作進行分類，并對各自的優(yōu)缺點作了深入探討.最后分析了2015年以來數(shù)據中心網絡傳輸設計的研究趨勢.

1 數(shù)據中心網絡傳輸層協(xié)議概述

傳輸層協(xié)議旨在為應用提供高吞吐、低延遲的網絡數(shù)據傳輸服務.雖然傳輸協(xié)議在因特網上已經有很長的歷史了，它卻直到2010年才在數(shù)據中心網絡環(huán)境下被系統(tǒng)性地探索.數(shù)據中心網絡有著和因特網不一樣的特點(如單一控制域和同構網絡架構).這給數(shù)據中心網絡上的傳輸協(xié)議設計同時帶來了機遇和挑戰(zhàn).本節(jié)將首先對因特網下的傳輸層協(xié)議作簡單介紹；之后，分析數(shù)據中心網絡的特點，并指出其對傳輸協(xié)議設計帶來的機遇和挑戰(zhàn).

1.1 因特網下的傳輸層協(xié)議簡介

傳輸層協(xié)議在因特網下已經發(fā)展了幾十年.傳輸層協(xié)議包括：無連接的盡力傳輸協(xié)議，以用戶數(shù)據報協(xié)議(user datagram protocol, UDP[4])為代表；面向連接的可靠傳輸協(xié)議，以傳輸控制協(xié)議(transport control protocol, TCP[5-6])為代表.在大多數(shù)網絡場景(包括因特網和數(shù)據中心網絡)中，應用層使用的傳輸協(xié)議以面向連接的可靠傳輸協(xié)議為主.TCP傳輸層協(xié)議提供的服務包括可靠性、流量控制、擁塞避免、多路復用等.其中，擁塞控制方面的研究最為廣泛.

TCP最經典的擁塞控制算法是由Jacobson[7]在1988年的SIGCOMM會議上提出的TCP Tahoe.該算法包括慢啟動(slow start)和擁塞避免(conges-tion avoidance)兩部分.新建立的連接首先進入慢啟動階段，每個來回通信時間(round-trip time, RTT)擁塞窗口(congestion window, CWND)漲1倍，直到通過計時器超時(timeout)發(fā)現(xiàn)丟包或者窗口達到慢啟動閾值(slow start threshold, ssthresh)進入擁塞避免階段.擁塞避免階段每個RTT擁塞窗口增加一個最大傳輸單元(maximum transmission unit, MTU)，發(fā)現(xiàn)丟包則窗口降為初始值1并重新進入慢啟動階段.

TCP Tahoe算法為了避免網絡丟包后因為等待超時重傳而帶來的時間開銷，額外引入了快速重傳(fast retransmission)機制，發(fā)送方收到多個相同序列號的確認包(acknowledgement, ACK)后，即認為下一個序列號對應的數(shù)據包已經丟失，并開始丟包重傳.在此基礎上，TCP Reno[8]增加了快速恢復(fast recovery)機制，在快速重傳之初窗口降為當前值的一半，同時保持擁塞避免狀態(tài)，避免了低效的初始化窗口和慢啟動過程.更進一步地，TCP New Reno[9]維護了快速恢復的狀態(tài)，記錄快速恢復狀態(tài)之初已發(fā)送的數(shù)據包，直到這些數(shù)據都已被確認才退出這一狀態(tài)，只在快速恢復初期進行1次窗口砍半，避免了因為連續(xù)丟包導致的連續(xù)砍窗口的問題.最后，TCP SACK[10]加入了選擇確認(selective ACK, SACK)與重傳機制，避免了累計確認(cumulative ACK)與重傳機制帶來的低效的回退N步(go-back-N)問題.

1.2 數(shù)據中心網絡的特點、機遇與挑戰(zhàn)

相對于因特網這類復雜多變且不完全可控的異構網絡，數(shù)據中心網絡是一個單一自治域(admini-strative domain)下的同構網絡環(huán)境.單一自治域意味著端主機(endhost)及其使用的協(xié)議、網絡設備及配置，甚至應用對網絡服務的需求(如延遲敏感還是帶寬敏感等)等都相對可控可預測.同構性體現(xiàn)在固定有規(guī)律的拓撲，如Fat-tree[1],VL2[11]等；相同的網絡設備及配置，如顯式擁塞通告(explicit congestion notification, ECN[12]),相對一致的緩存大小和鏈路帶寬；有限的路由條數(shù)以及可預測的RTT等.

數(shù)據中心網絡的這些特點給傳輸協(xié)議設計帶來了許多機遇，列舉如下：

1) 數(shù)據中心網絡下可以協(xié)調端主機協(xié)議和網絡設備設置，存在更多性能優(yōu)化空間.傳統(tǒng)因特網因為網絡不可控，只能使用丟包信息作為擁塞反饋信號，不可避免地帶來了高延遲和高丟包率等問題.即使網絡設備使用了一些復雜的網絡優(yōu)化機制，端主機上的協(xié)議也很可能沒能充分配合使用.數(shù)據中心網絡則可以協(xié)調兩者，如網絡側采用主動隊列管理(active queue management, AQM[13])在擁塞早期標記ECN信號,接收端收到信號通過ACK反饋給發(fā)送端，發(fā)送端得以及時調整發(fā)送窗口或速率實現(xiàn)高效擁塞控制等.

2) 數(shù)據中心網絡下的傳輸協(xié)議不受公平性的約束.因特網不是單一自治域，存在多種不同協(xié)議之間的競爭，因而公平性是一個重要指標，給網絡性能方面的優(yōu)化帶來了約束.數(shù)據中心網絡作為單一自治域，一方面可以協(xié)調內部不同應用使用不同的網絡優(yōu)先級隊列，例如，區(qū)別對待延遲敏感和帶寬敏感的應用，可以優(yōu)化兩者各自不同的目標；另一方面可以統(tǒng)一全局采用相同協(xié)議和網絡配置，避免不同協(xié)議間的競爭.

3) 同構的數(shù)據中心網絡更有利于協(xié)議和網絡設備的參數(shù)設置.例如，相對穩(wěn)定的RTT可以幫助設置最小重傳計時器(retransmission timeout, RTO)；相對穩(wěn)定的網絡鏈路帶寬和RTT意味著可預測的網絡帶寬時延乘積(bandwidth delay product, BDP)，可以幫助設置初始擁塞窗口大小和ECN標記的閾值等.

與此同時，數(shù)據中心網絡面對著更加復雜嚴苛的應用要求，給傳輸協(xié)議設計帶來了巨大的挑戰(zhàn)，列舉如下：

1) 應用要求嚴苛.一個典型的應用設計模式(網頁搜索、廣告篩選等的基礎)是分割聚合(partitionaggregate[2]).上層應用需求被分割成多個小的任務給多個底層工作機器(worker),底層機器完成任務后將結果返回給應用匯聚層得到最終結果.為了滿足服務級協(xié)議(service-level agreement, SLA)，每一輪迭代(包括計算和網絡傳輸)都需要在10 ms量級的期限內完成.99.9%的尾部時延仍然會對用戶帶來巨大的影響(要么返回不準確的結果，要么造成長等待時間).

2) 應用需求多樣.不同的應用通常會有不同的網絡傳輸需求.有些應用要求短時間內的低時延，比如面向用戶請求的短流量響應.有些應用要求長時間的穩(wěn)定吞吐量，比如數(shù)據中心內部定期的海量數(shù)據更新.有些應用有限定完成期限，在期限內完成的數(shù)據才有效，快于期限完成的數(shù)據并不一定會帶來更大的應用價值.

2 早期研究

基于第1節(jié)對數(shù)據中心網絡的觀察，工業(yè)界和學術界開始了對數(shù)據中心網絡環(huán)境下傳輸協(xié)議設計的研究.本節(jié)將早期(2010—2015年)數(shù)據中心網絡傳輸設計方面的工作分成3類——基于端主機的擁塞控制、網絡仲裁機制和交換機優(yōu)先級調度，并分別對這3類工作的優(yōu)缺點作深入討論.表1概括了本節(jié)介紹的3類工作及其相應的優(yōu)缺點.

Table 1 Comparison Between Early (2010—2015) Work on DCN Transport Protocol表1 數(shù)據中心網絡傳輸層協(xié)議早期(2010—2015年)工作的比較

2.1 基于端主機的擁塞控制

數(shù)據中心網絡最經典的傳輸層擁塞控制算法是由斯坦福大學和微軟的研究人員在2010年的SIGCOMM會議上提出的數(shù)據中心傳輸協(xié)議(datacenter transmission control protocol, DCTCP)[2].DCTCP是一種基于端主機的擁塞控制算法，主要包括2部分：交換機端的ECN標記和主機端的速率控制.DCTCP在這2部分與基于ECN的TCP協(xié)議都有明顯不同.一方面，DCTCP使用了基于交換機瞬時隊列長度的單一閾值標記算法.基于瞬時隊列的標記可以對突發(fā)流帶來的網絡擁塞作出快速響應，使得算法有更好的突發(fā)容忍性.此外，單一閾值標記配置使用更簡單，這也是基于DCN內較穩(wěn)定的基礎RTT的條件.另一方面，DCTCP將單個位的ECN序列轉化為多個位的擁塞程度并依此調整窗口，而不像TCP那樣簡單粗暴地窗口砍半.這樣既避免了輕微擁塞下過度響應導致的帶寬浪費，又防止了嚴重擁塞下響應不足導致的高延遲和高丟包率.

DCTCP具體算法為：

1) 交換機基于瞬時隊列長度以單一閾值對經過的數(shù)據包標記ECN.

2) 接收端將收到的數(shù)據包中的ECN信息通過ACK中的ECN-Echo反饋回發(fā)送方.

3) 發(fā)送方統(tǒng)計收到ACK中ECN-Echo比例的指數(shù)加權滑動平均值α.當沒有ECN-Echo時，每個ACK窗口增加1WCWND；當遇到ECN-Echo時，每個RTT窗口乘性砍α2.

在這之后，一系列的基于ECN的擁塞控制算法被設計出來.D2TCP[15]以降低期限錯失率(deadline miss rate)為目標，在DCTCP的基礎上引入了流的完成期限D，并以此計算期限緊急程度e=TD，其中T為預期完成時間；當數(shù)據發(fā)送方收到ECN-Echo時，每個RTT窗口乘性砍αe2，使得期限更緊急的流可以更快地完成.類似地，L2DCT[16]則以降低流的完成時間(flow completion time, FCT)為目標，在DCTCP的基礎上引入了與發(fā)送數(shù)據量反相關的流的權值函數(shù)f；當數(shù)據發(fā)送方收到ECN-Echo時，每個RTT窗口乘性砍αf2，使得更小的流可以更快地完成，從而逼近在流大小信息不可知下理論最優(yōu)的最少獲得服務優(yōu)先(least attained service, LAS)[23]調度算法.此外，有一些工作(如ECN[24])認為只需優(yōu)化調整交換機ECN機制，采用順時出隊列的方式標記，即可以在不改動端主機TCP協(xié)議的情況下達到和DCTCP相近的性能.

基于端主機的擁塞控制機制只需要改動端主機上的軟件協(xié)議棧，交換機上配置簡單的ECN標記，因而具有配置簡單和易于實現(xiàn)部署的優(yōu)點.不足的是，因為沒有很好地結合更多的交換機支持，基于端主機的擁塞控制機制在性能上通常與理論最優(yōu)存在較大差距.例如，DCTCP沒有區(qū)分大小流，使得大小流同時存在于單一隊列中，小流的完成時間會受到大流的排隊延遲影響而變得很長.與此同時，基于端主機的擁塞控制機制需要較長的時間周期去收斂到穩(wěn)定狀態(tài).

2.2 網絡仲裁機制

為了克服基于端主機的擁塞控制收斂時間長等缺陷，網絡仲裁機制得到了廣泛關注.網絡仲裁機制借助于網絡中交換設備等可以觀察到經過流量的需求，從而基于一定的算法計算發(fā)送窗口或速率或調整方向，通過數(shù)據包頭和接收端ACK反饋回發(fā)送端，從而實現(xiàn)擁塞控制和流量調度.

最早的代表性工作是由微軟的研究人員在2011年的SIGCOMM會議上提出的期限驅動傳輸控制協(xié)議(deadline-driven delivery control protocol, D3)[17].D3以降低期限錯失率為目標，假設上層應用可以將數(shù)據流大小和規(guī)定期限信息傳給傳輸層.基于這些信息，D3設計了網絡仲裁機制，讓交換機根據全局流信息分配帶寬，優(yōu)先分配數(shù)據流在規(guī)定期限內完成所需的最小帶寬，即r=sD，其中s為流的大小，D為流的完成期限；最后將剩余的帶寬平均分配給所有的流.

不足的是，D3需要交換機來記錄流狀態(tài)并分配帶寬，這樣復雜的功能遠遠超出了目前商用交換機的支持功能范圍.此外，D3采用了貪婪式的先到先服務的帶寬分配方案，先到達的流一旦被分配帶寬，將占用帶寬直至最終完成，而不允許中途釋放帶寬給新流，即不允許搶占.這導致了非最優(yōu)的流調度，如圖1(b)所示，由于一個接近完成期限的流(fA)可能會為了等待一個先到達的完成期限較遠的流(fB)而被阻滯，進而錯過了規(guī)定的完成期限.

Fig. 1 Illustration to show the suboptimal performance of D3 without preemption圖1 實例說明D3在沒有搶占機制下的非最優(yōu)調度性能

針對D3的缺點，伊利諾伊大學香檳分校的研究人員在2012年的SIGCOMM會議上提出了搶占式分布快速控制協(xié)議(preemptive distributed quick control protocol, PDQ)[18].與D3類似，PDQ假設上層應用可以將數(shù)據流大小和規(guī)定期限等信息暴露給傳輸層.利用這些信息，PDQ同樣也設計了顯式速率控制的實現(xiàn)機制，逼近不同的調度算法.例如：1)最短任務優(yōu)先(shortest job first, SJF)[25]調度算法.數(shù)據量越小的流將會被優(yōu)先分配帶寬.2)最近期限優(yōu)先(earliest deadline first，EDF)[26].越接近完成期限的流將會被優(yōu)先分配帶寬.與D3不同的是，PDQ采用了搶占式的帶寬分配方案，可以根據流的緊急程度將已分配的帶寬重新分配，從而解決了D3非最優(yōu)調度的問題(圖1(c)中最優(yōu)調度與PDQ相同).

PDQ離理想的SJF和EDF仍有較大的差距.這是因為在PDQ系統(tǒng)里，暫?；蛘邌右粋€流都需要至少一個RTT來與路徑上所有的交換機協(xié)調.這一個RTT的額外開銷對于數(shù)據中心內大量小流來說是不可接受的負擔.此外.精確地計算出一個流的發(fā)送速率并不是一個簡單的事情，比如一個流的發(fā)送瓶頸可能不是在網絡里，而是在端主機的磁盤上.

與此同時，網絡仲裁機制中還包括一類利用服務器做集中式擁塞控制調度的設計.代表性工作是由麻省理工學院的研究人員在2014年的SIGCOMM會議上提出的FastPass[19].這類工作在發(fā)送數(shù)據前，發(fā)送端會向集中控制器發(fā)送請求，集中控制器結合請求信息和網絡狀況作出相應的調度指令，包括發(fā)送數(shù)據的時間、速率和路徑等.這種集中式調度優(yōu)點明顯，因為可以獲取網絡全局信息，理論上可以達到最優(yōu)的調度，但是也存在明顯缺點，系統(tǒng)實現(xiàn)上需要額外一個RTT開銷去獲取調度決策，因而對數(shù)據中心下小流的完成時間有較大的負面影響.

2.3 交換機優(yōu)先級調度

為了克服網絡仲裁機制不可實現(xiàn)等缺陷，斯坦福大學的研究人員在2013年的SIGCOMM會議上提出了基于交換機優(yōu)先級調度的pFabric[20].pFabric既不要求交換機配置大量內存以維持所有流的狀態(tài)信息，也不要求交換機實現(xiàn)復雜的調度算法以計算反饋信息.pFabric的核心思想是將流調度從速率控制中分離開來.pFabric的設計包含2部分：1)端上的速率控制協(xié)議.新流以線速發(fā)出，去除任何快速丟包重傳機制，直到連續(xù)多次超時才進入探索模式，定期發(fā)送最小數(shù)據包并在接收到確認時重新進入慢啟動.2)交換機上的優(yōu)先級調度和優(yōu)先級丟包.交換機上優(yōu)先調度最高優(yōu)先級的數(shù)據包；當緩沖已滿時，優(yōu)先丟棄低優(yōu)先級的數(shù)據包.

與網絡仲裁機制相比，pFabric設計更簡單，同時保證了接近理論最優(yōu)的性能.但是，pFabric仍然無法在已有的商用交換機上實現(xiàn).一方面，商用交換機芯片支持的優(yōu)先級隊列數(shù)量非常有限(大約8個)；另一方面，商用交換機芯片并未廣泛支持優(yōu)先級丟包機制，一旦一個數(shù)據包進入了交換機的緩沖區(qū)，它就不會被新到來的包“擠出去”.后續(xù)工作EPN嘗試使用2個優(yōu)先級隊列逼近pFabric的性能，然而需要對交換機做更多復雜的改動，因而同樣無法在商用交換機上實現(xiàn).

pFabric等工作都假設我們可以從應用獲得流的信息，比如流的大小.事實上，雖然數(shù)據中心是一個單獨管理域，應用的流信息仍然很難獲得.主要原因有2個：1)很多應用是一邊計算一邊傳輸?shù)模援攽瞄_始傳一個流時，它自己也不知道這個流總共要傳多少字節(jié).2)對于許多可以獲得流大小的應用，管理員仍然需要去修改其網絡通信模塊獲得流大小，并將這個信息通過合適的接口傳遞給協(xié)議棧.考慮到數(shù)據中心有大量的應用，逐一修改這些應用獲得流信息對于管理員來說無疑是巨大的負擔.

基于上述觀察，無信息感知的流調度工作應運而生.香港科技大學的研究人員在2015年的NSDI會議上提出了實際的無信息感知的流調度機制 (practical information-agnostic flow scheduling, PIAS)[21].PIAS采用多級反饋隊列作為其調度策略.在多級反饋隊列里面，所有流一開始都屬于最高優(yōu)先級，當一個流已經發(fā)送的字節(jié)數(shù)超過一個閾值時，這個流就被降入下一個優(yōu)先級.根據多級反饋隊列策略，小流會在較高優(yōu)先級內完成，而大流會在較低優(yōu)先級內完成.多級反饋隊列可以在長尾分布下有效地近似理想的最短剩余時間優(yōu)先，降低流的整體平均完成時間以及小流的完成時間.PIAS利用端主機來記錄每個流已經發(fā)送的字節(jié)數(shù)并標記數(shù)據包的優(yōu)先級，而在交換機里只需要配置普通的優(yōu)先級隊列.因此，PIAS可以在普通的商用交換機和標準的TCPIP協(xié)議棧上實現(xiàn)，容易在生產環(huán)境里部署.

在PIAS系統(tǒng)里，一個關鍵的部分就是多級反饋隊列的閾值.閾值決定了如何將不同大小的流隔離在不同優(yōu)先級里.如果閾值設置得不好，大小流可能某個時刻全部混雜在一個優(yōu)先級里面，嚴重拖長小流的完成時間.簡單的理論分析發(fā)現(xiàn)，理想的閾值跟每條鏈路的流大小分布和平均利用率都有關系.在真實的數(shù)據中心環(huán)境里，流的大小分布和平均利用率是在時間和空間2個維度上同時變化的.在這種條件下，閾值和流量的錯配幾乎是無法避免的.對此，PIAS搜集數(shù)據中心全局的流量信息來統(tǒng)一計算閾值，并利用交換機的顯式擁塞通知機制來減輕錯配的影響.在2018年的SIGCOMM會議上，香港科技大學的研究人員進一步提出了AuTO[27]，其中一個機制就是通過深度強化學習來自動優(yōu)化多級反饋隊列的閾值.

PIAS把所有流都簡單視為不能預先知道大小且沒有截止完成時間限制的流.事實上，在數(shù)據中心里面，多種類型的流是共存的.第1類流是有規(guī)定期限的流.對于這種流，流的大小往往也可以預先知道或者估計出來.第2類流是沒有規(guī)定期限的限制，也無法預先知道大小的流.對于這種流，PIAS的優(yōu)化效果是最好的.第3類流是沒有規(guī)定期限的限制，但是可以預先知道大小的流.對于這種流，使用少量優(yōu)先級的pFabric近似方案優(yōu)化效果是最好的.為了解決上述“混合流”(mix-flows)的調度問題，香港科技大學的研究人員在2016年的SIGCOMM會議上提出了Karuna[22].嚴格來說，Karuna并不是一個純粹的無信息感知的方案，它只是不知道第2類流的信息.Karuna把有規(guī)定期限的流(第1類)固定在最高優(yōu)先級，以降低期限錯失率.但是為了降低第1類流對于另外2類流的影響，Karuna使用了一種叫作MCP[28]的傳輸層協(xié)議，讓第1類流以較低的吞吐量“恰好”在規(guī)定期限內完成.對于沒有規(guī)定期限的限制，也無法預先知道大小的流(第2類)，Karuna采用了多級反饋隊列來調度，讓一個流在傳輸過程中優(yōu)先級不斷降低.對于沒有規(guī)定期限的限制，但是可以預先知道大小的流(第3類)，Karuna根據流的大小，賦予它們一個固定的優(yōu)先級，一個流越大，得到的優(yōu)先級就越低.通過對3類流的區(qū)分處理，Karuna可以同時降低流的期限錯失率和平均完成時間.

2.4 其 他

2.1～2.3節(jié)介紹的工作要么側重基于端主機的擁塞控制，要么側重基于交換機的仲裁機制，要么側重網絡的優(yōu)先級調度，密歇根州立大學的研究人員在2014年的SIGCOMM會議上提出了PASE[29]，認為這3個機制應該結合起來.PASE同時使用了仲裁、優(yōu)先級隊列和基于ECN的速率控制協(xié)議.與D3和PDQ那樣利用網絡仲裁每個流的速率不同，PASE把仲裁機制實現(xiàn)在端主機或者交換機的CPU上，計算出每個流在網絡里的優(yōu)先級和粗粒度的參考速率，再利用基于端主機的速率控制對速率做細粒度控制.因此，PASE不需要對交換機芯片進行修改，而且不用擔心流的發(fā)送速率計算不夠準確的問題.PASE依靠商用交換機上有限的優(yōu)先級隊列來調度流，并且利用基于ECN的速率控制協(xié)議來充分利用鏈路帶寬.因此，跟D3， PDQ，pFabric相比，PASE不僅更容易部署，而且在許多場景下甚至可以取得更好的性能.

3 趨勢與展望

隨著數(shù)據中心網絡的升級換代(如帶寬從1 Gbps增加到10 Gbps再到40 Gbps100 Gbps，基礎往返延遲從幾百微秒降低到幾微秒)，傳統(tǒng)的TCP傳輸層協(xié)議及其變型逐漸難以達到預期的網絡傳輸性能.一方面，TCP協(xié)議采用了反應式的擁塞控制算法，無法勝任流量突發(fā)性更強(大多數(shù)流在幾個RTT內就完成了)的高速網絡傳輸；另一方面，TCPIP協(xié)議?；谙到y(tǒng)內核軟件，造成了高CPU消耗和高網絡協(xié)議棧延遲.針對這2個問題，2015年以來的科研工作分別嘗試采用了接收端驅動的主動擁塞控制和RDMA網絡傳輸?shù)姆绞郊右越鉀Q.本節(jié)將分別討論分析這2類工作.表2和表3分別對這2類工作做了比較分析.

3.1 接收端驅動的主動擁塞控制

數(shù)據中心網絡下接收端驅動的主動擁塞控制(proactive congestion control, PCC)的雛形是由加州大學伯克利分校的研究人員在2015年的CoNEXT會議上提出的pHost[30].pHost的設計初衷是以一種可實現(xiàn)的方式達到與pFabric(性能上被認為是當時最優(yōu)的設計)相近的性能.一種可實現(xiàn)的做法是使用集中式控制器，帶來的問題是調度時間開銷很大，通常導致小流的完成時間遠遠差于pFabric.另辟奇徑地，pHost將流調度的任務放到了數(shù)據接收端：數(shù)據發(fā)送方發(fā)送數(shù)據前請求發(fā)送(request to send, RTS)，可以包含相關調度信息(如流大小等)；數(shù)據接收方根據收到的所有請求按照一定的調度算法分配發(fā)送許可(token或credit或grant或pull)；數(shù)據發(fā)送方按照接收到的發(fā)送許可發(fā)送相應數(shù)量的數(shù)據.這樣既保證了商用設備可實現(xiàn)，又達到了可擴展的流調度，實驗驗證可以達到pFabric相近的性能.

Table 2 Comparison Between Existing Work on Proactive Congestion Control表2 主動擁塞控制的現(xiàn)有工作的比較

Table 3 Comparison Between Existing Work on RDMA Congestion Control表3 RDMA擁塞控制的現(xiàn)有工作的比較

接收端驅動的主動擁塞控制因為其接近零排隊時延和快速收斂等優(yōu)點被學術界和工業(yè)界廣泛關注.然而，現(xiàn)有的主動擁塞控制設計仍然存在一些問題.例如，pHost只能解決網絡擁塞發(fā)生在網絡邊緣，即發(fā)送端網絡入口鏈路及接收端網絡出口鏈路處的情形.它假設數(shù)據中心網絡采用全雙向(full bisection)帶寬和交換機逐包分撒(packet spray[38])鏈路負載衡以達到網絡內部無擁塞.對于網絡入口處的擁塞，在發(fā)送端上可以解決；對于網絡出口處的擁塞，則由接收端調度完美解決.然而，實際數(shù)據中心網絡中這一假設并不一定成立，例如，在發(fā)生鏈路故障導致網絡不對稱時，網絡內部仍然會發(fā)生擁塞，pHost在這時候將無法發(fā)揮作用.

為了彌補pHost的不足，韓國先進科學技術研究院和谷歌的研究人員在2017年的SIGCOMM會議上提出了ExpressPass[31]，是一種能夠解決網絡任意節(jié)點擁塞的主動擁塞控制算法.ExpressPass的數(shù)據發(fā)送方發(fā)送數(shù)據前請求發(fā)送；數(shù)據接收端發(fā)送credit在網絡中通過獨立的隊列及限速反向模擬數(shù)據發(fā)送過程，在credit輕微排隊時即丟包；數(shù)據發(fā)送方按照接收到的發(fā)送許可發(fā)送相應數(shù)量的數(shù)據.ExpressPass利用了credit的反向模擬獲取網絡狀態(tài)，限制了隊列深度，避免了真實數(shù)據包的丟失，同時credit的控制回路可以做得更加激進，從而實現(xiàn)快速收斂.

與此同時，歐洲的研究人員也在2017年的SIGCOMM會議上提出了另一種主動擁塞控制算法NDP[32].NDP在pHost的基礎上使用基于端主機的逐包多路負載均衡機制替代網絡交換機本地的逐包分撒機制，可以避免因為鏈路故障等原因導致的網絡內部的擁塞(但仍然無法解決網絡拓撲不對稱或核心帶寬不足等導致的網絡內部擁塞問題)；同時加入砍去有效載荷(cutting payload, CP)[39]的機制,可以避免在incast等極度擁塞狀況下的長尾部時延.NDP雖然性能上比pHost優(yōu)越，但是卻因為引入CP而失去了商用設備可實現(xiàn)的優(yōu)點.

斯坦福大學和麻省理工學院的研究人員在2018年SIGCOMM會議上提出了Homa[33]，對pHost作了進一步的改進.Homa的創(chuàng)新之處有2點：1)它發(fā)現(xiàn)了當pHost發(fā)送端與多個接收端通信并同時收到發(fā)送許可時，部分發(fā)送許可及相應的帶寬會浪費的問題.對此，Homa引入了過度承諾(overcommit-ment)的機制,發(fā)送超過網絡容量的發(fā)送許可來保證網絡帶寬不被浪費.2)它發(fā)現(xiàn)了pHost在新流到達時不能及時搶占，需要等待一個RTT才能調整調度策略的問題.對此，Homa使用了網絡多優(yōu)先級隊列的機制，從而達到第1個RTT快速搶占，這同時也解決了過度承諾超發(fā)導致的擁塞丟包問題.

現(xiàn)有的基于接收端的主動擁塞控制存在的另一問題是往返時延不同的流共存時發(fā)送許可觸發(fā)的數(shù)據報文不協(xié)調.原來以計算好的時間間隔發(fā)送的發(fā)送許可，觸發(fā)的數(shù)據報文可能因為時延不同而同時到達同一條鏈路，產生意外的擁塞.另外，如何將這類設計應用到RDMA和廣域網的場景下也是一個有挑戰(zhàn)的課題，上述因時延不同導致的問題在這些場景下會更加突出.

3.2 RDMA網絡擁塞控制

為了解決3.1節(jié)的高速低延遲數(shù)據中心網絡發(fā)展的問題，特別是TCPIP內核軟件協(xié)議棧帶來的性能瓶頸，遠程直接內存訪問(remote direct memory access, RDMA)[40]開始被引入到DCN中.RDMA可以將數(shù)據直接從一臺計算機的內存?zhèn)鬏數(shù)搅硪慌_計算機，無需雙方操作系統(tǒng)的介入，因而具有極高的性能.

雖然RDMA技術已經廣泛應用于高性能計算(high performance computing, HPC)領域，在DCN中大規(guī)模部署仍然存在一些挑戰(zhàn).一個核心的問題是如何將網絡傳輸機制集成到RDMA硬件設備(包括網卡和交換機)中，目前存在3類解決方案：1)IB(InfiniBand)[41].IB使用專用網卡和交換機等硬件實現(xiàn)無損網絡(即網絡不丟包)，與傳統(tǒng)以太網絡不兼容.目前廣泛應用于HPC領域，難以部署于廣泛基于IP和以太網技術的DCN.2)iWARP[42].網卡硬件實現(xiàn)了完整的TCP傳輸協(xié)議，支持傳統(tǒng)以太網絡.受限于復雜的網卡實現(xiàn)，基本性能(延遲、吞吐量)被普遍認為弱于RoCE.3)RoCE[43].網卡硬件實現(xiàn)了簡單的傳輸協(xié)議，支持傳統(tǒng)以太網絡，普遍被認為在有損網絡下性能不佳，通常配合基于優(yōu)先級的流量控制(priority flow control, PFC)使用.然而，使用PFC存在線頭阻塞和死鎖等問題.

數(shù)據中心網絡RDMA擁塞控制最早的代表性工作是由微軟、邁絡思和加州大學圣塔芭芭拉分校的研究人員在2015年的SIGCOMM會議上提出的DCQCN[34].這也是目前工業(yè)界采用最廣的RDMA擁塞控制算法，已經被集成到邁絡思ConnectX系列網卡上.DCQCN為了支持以太網采用了RoCEv2技術，配合使用了PFC流量控制技術以保證無損網絡.為了避免頻繁觸發(fā)PFC帶來線頭阻塞和死鎖等問題，DCQCN采用了其核心擁塞控制算法，包括3部分：1)擁塞點(congestion point, CP)，即交換機，采用基于RED[44]和瞬時隊列長度的ECN標記算法.2)通告點(notification point, NP)，即數(shù)據接收端，根據收到數(shù)據包含的ECN信息返回擁塞通告包(congestion notification packet, CNP).受當時硬件限制，CNP生成間隔(默認為N=50s)只能達到微秒級別，因而很難做到逐包反饋.3)反應點(reaction point, RP)，即數(shù)據發(fā)送端，與DCTCP類似，維護了ECN比例的指數(shù)加權滑動平均值α.每收到CNP則乘性砍α2；每隔K=55s內若沒有收到CNP則增加發(fā)送速率.DCQCN擁塞控制算法與DCTCP非常相似，但受硬件條件約束，有2點明顯的不同：一是直接控制發(fā)送速率而非擁塞窗口；二是基于計時器調整速率而非逐包調整.這些硬件限制導致的差異給DCQCN的設計與參數(shù)配置帶來了極大的挑戰(zhàn)，該工作在理論上給出了指導原則與證明，但是在實際部署中仍然存在許多問題.

與此同時，谷歌、加州大學伯克利分校和微軟的研究人員也在2015年的SIGCOMM會議上提出了一套擁塞控制方案TIMELY[35]，并圍繞RDMA環(huán)境作了詳細分析與評估.TIMELY是第1個在數(shù)據中心內部采用RTT作為擁塞反饋信號的傳輸控制協(xié)議.TIMELY發(fā)現(xiàn)當前網卡技術支持精確的RTT測量，并且RTT可以有效反映網絡擁塞隊列深度.基于這一觀察，TIMELY通過RTT與Tlow和Thigh兩個參數(shù)比較，將核心算法劃分為3部分：1)當RTT小于Tlow時，增加發(fā)送速率；2)當RTT大于Thigh時，減小發(fā)送速率；3)當RTT介于兩者間時，根據RTT的梯度變化動態(tài)調整速率.當RTT梯度為正時，說明延遲及擁塞仍在增加，應該減小發(fā)送速率；當RTT梯度為負時，說明延遲及擁塞在減小，應該增加發(fā)送速率.TIMELY主體部分采用基于RTT梯度的速率調整算法在性能上廣受爭議，普遍被人認為在動態(tài)網絡下沒有唯一的收斂點，即有可能在一個很高延遲的范圍內收斂[45].

DCQCN依賴于PFC保證網絡無損，因而存在PFC帶來的各種問題，包括線頭阻塞和死鎖等.對此，許多工作[46-47]嘗試去逐個解決這些問題.2018年在SIGCOMM會議上由加州大學伯克利分校等的研究人員提出的IRN[36]則反其道而行之，認為網絡無損或PFC對于以太網上支持RDMA不是根本上不可或缺的.IRN結合了iWarp和RoCE各自的優(yōu)勢，一方面類似于iWarp,將網絡可靠性建立在端傳輸協(xié)議而非無損網絡上；另一方面類似于RoCE,在網卡上實現(xiàn)盡可能簡化的協(xié)議機制.IRN設計上有2個主要部分：1)高效的丟包恢復，使用選擇重傳取代低效的回退N步(go-back-N)機制，同時采用雙超時重傳定時器減小尾部丟包等問題的影響.2)簡單的流速控制，將發(fā)送數(shù)據量限制在一個BDP內，在不浪費帶寬的前提下盡可能地避免擁塞.IRN在仿真器上做了大量實驗證明其在沒有PFC的支持下能夠達到甚至超過使用PFC的DCQCN和TIMELY的性能.然而，IRN目前并未集成到商用網卡中.數(shù)據中心RDMA網絡應該向無損網絡還是有損網絡方向發(fā)展仍然是一個熱門話題.

更進一步地，哈佛大學和阿里巴巴的研究人員在2019年的SIGCOMM會議上提出了全新的RDMA擁塞控制方案HPCC[37].HPCC發(fā)現(xiàn)RDMA擁塞控制方案存在許多參數(shù)，這些參數(shù)的調整涉及到網絡吞吐量、延遲和穩(wěn)定性(是否頻繁觸發(fā)PFC等)等性能指標相互之間的利益權衡.文獻[37]認為這種非此即彼的利益權衡是由以前的硬件約束(如基于計時器的速率調整等)導致的，現(xiàn)有硬件技術的發(fā)展可以打破這種尷尬局面，具體表現(xiàn)在2個方面：一方面，現(xiàn)有網卡有更強大的計算能力和資源，可以支持更精確快速的逐包確認和響應；另一方面，網絡交換機有了更開放可自定義的數(shù)據平面(data plane)，比如，可以支持網絡內部自動測量(in-network telemetry, INT)，交換機在每個經過的數(shù)據包包頭加入當前時間、隊列長度、歷史發(fā)送數(shù)據量等信息，幫助端主機作出更精確的擁塞控制響應.

HPCC擁塞控制主要由2部分組成：1)交換機采用了INT反饋機制，在每個經過的數(shù)據包的包頭加入當前時間、隊列長度、歷史發(fā)送數(shù)據量等信息；2)端主機擁塞控制同時限制發(fā)送速率R和窗口CWND，速率調整算法包含加性和乘性調整2部分.加性部分每個RTT增加固定的發(fā)送速率aiRate，這樣類似于TCP可以保證小流不被餓死，即保證了流競爭的公平性.乘性部分首先基于INT反饋信息計算出網絡逐跳的鏈路利用率Ui，再根據逐跳最大的瓶頸利用率maxi(Ui)與設定的目標利用率Utarget的比值乘性地調整發(fā)送速率R.為了避免對單一擁塞事件的多次重復響應，HPCC還結合了逐包和逐RTT的速率調整機制.逐RTT的速率調整會在每個RTT開始時設定一個參考速率Rc,逐包的速率調整則根據INT反饋圍繞當前RTT下的Rc上下波動調整速率.這樣在保證快速響應的同時，可以避免觸發(fā)不必要的降速和帶寬浪費.

RDMA下的傳輸層設計仍然有很大的探索空間.如何設計RDMA傳輸層使得網絡可以擴展到廣域網中？如何設計RDMA網絡下的負載均衡機制？能否在RDMA網絡卡中使用基于接收端的主動擁塞控制取代傳統(tǒng)的被動擁塞控制？如何處理好傳統(tǒng)TCPIP流量和RDMA流量共存的場景？這些問題的探索和解決將會是未來的研究趨勢.

4 總 結

近10年來，在盛行的網絡應用(如搜索、在線零售和云計算等)的需求驅動下，數(shù)據中心在全球范圍內以前所未有的速度和規(guī)模發(fā)展建立起來.特別地，數(shù)據中心網絡引起了包括學術界和工業(yè)界的廣泛關注.在此背景下，本文圍繞數(shù)據中心網絡中的傳輸層協(xié)議設計作了詳細的總結和未來的展望.首先，本文回顧了傳輸層協(xié)議在因特網上的發(fā)展，探討了數(shù)據中心網絡和因特網不一樣的特點，以及這些特點給傳輸層協(xié)議設計帶來的機遇和挑戰(zhàn).隨后，本文探討了早期(2010—2015年)數(shù)據中心網絡傳輸設計方面的工作，主要包括3類——基于端主機的擁塞控制、網絡仲裁機制和交換機優(yōu)先級調度.這3類工作在可實現(xiàn)性和性能等方面各有優(yōu)缺點，在各自方向上都有了相當成熟和完善的研究.最后，本文分析了2015年以來數(shù)據中心網絡傳輸設計的研究方向，主要包括2類——接收端驅動的主動擁塞控制和RDMA傳輸協(xié)議設計.這2類工作在理論和系統(tǒng)實現(xiàn)上至今仍存在著許多尚未解決的問題，將會成為數(shù)據中心網絡傳輸協(xié)議研究的未來趨勢.