數(shù)據(jù)中心網(wǎng)絡(luò)快速反饋傳輸控制協(xié)議

蘇凡軍，牛詠梅，邵 清

(上海理工大學(xué)光電信息與計算機工程學(xué)院，上海200093)

1 概述

隨著云計算的發(fā)展，數(shù)據(jù)中心已成為實現(xiàn)云計算、云存儲的重要基礎(chǔ)設(shè)施。由于數(shù)據(jù)中心可以為大型信息系統(tǒng)提供海量數(shù)據(jù)處理和存儲服務(wù)，現(xiàn)今建立起了許多大型服務(wù)數(shù)據(jù)網(wǎng)絡(luò)，如 Amazon，Google和Yahoo等大公司都擁有了自己的數(shù)據(jù)中心，且隨著數(shù)據(jù)中心網(wǎng)絡(luò)的快速發(fā)展，其服務(wù)器的數(shù)量也呈指數(shù)級增長。但是數(shù)據(jù)中心網(wǎng)絡(luò)在實現(xiàn)數(shù)據(jù)中心的通信時，數(shù)據(jù)流一般具有高帶寬和低延遲的特點，容易引起許多問題的出現(xiàn)，如擁塞通知問題、能量消耗問題以及TCP Incast問題等。針對這些問題，許多研究者們進行了研究，如卡耐基梅隆大學(xué)的PDL Project和加州大學(xué)伯克利分校的RAD Lab的2個實驗項目，國內(nèi)清華大學(xué)的任豐原等人對TCP Incast問題的實驗研究和分析等。

為了避免TCP Incast問題造成的性能惡化，國內(nèi)外已經(jīng)展開了這方面的研究工作［1-3］。例如數(shù)據(jù)中心網(wǎng)絡(luò) TCP 協(xié)議(DCTCP)［1，4］利用了 ECN 的顯式擁塞通知功能，交換機在擁塞時做擁塞標(biāo)記，接收端將擁塞信息反饋給發(fā)送端，發(fā)送端估計擁塞程度從而調(diào)整擁塞窗口，但該算法存在反饋慢、擁塞估計不準確等問題。此外，還有ICTCP(Incast Congestion Control for TCP)［5］。ICTCP通過計算接收端的流量來估計鏈路可用帶寬的變化，然后通過調(diào)節(jié)接收窗口進行速率控制。相比于傳統(tǒng)的TCP協(xié)議，ICTCP能夠有效地避免擁塞，緩解TCP Incast問題，但其應(yīng)用場景很有限，只適用于很簡單并且固定的TCP Incast場景。Alizadeh M等人提出了在數(shù)據(jù)中心網(wǎng)絡(luò)鏈路層進行擁塞控制的QCN(Quantized Congestion Notification)算法［6］，QCN 可以有效地控制鏈路速率，但是在TCP Incast場景下性能很差。

針對以上算法的缺點，本文提出一種可快速反饋的數(shù)據(jù)中心網(wǎng)絡(luò)TCP協(xié)議。該協(xié)議的設(shè)計思想是交換機直接判斷擁塞情況發(fā)送擁塞反饋給發(fā)送端;發(fā)送端根據(jù)反饋信息快速準確地調(diào)整擁塞窗口。最后采用NS2［7］的模擬實驗對算法性能進行驗證。

2 TCP Incast問題與解決方案

2．1 數(shù)據(jù)中心網(wǎng)絡(luò)TCP Incast問題

如圖1所示的“多對一”的工作模式在現(xiàn)在的數(shù)據(jù)中心中已經(jīng)變得越來越普遍。其中，A1，A2，…，An表示數(shù)據(jù)中心的n個服務(wù)器。

圖1 TCP Incast模型示意圖

主機C請求的數(shù)據(jù)信息稱為SRU(Server Request Unit)，分別存儲在各個服務(wù)器上。比如，SRU1存放在A1服務(wù)器上，為響應(yīng)主機請求，各個服務(wù)器將各自的數(shù)據(jù)發(fā)送到服務(wù)器B，組成完整的SRU，再反饋給主機C。這個通信過程中，A為發(fā)送端，C為接收端。典型例子如Google利用MapReduce技術(shù)處理搜索請求［8-10］。

當(dāng)這種“多對一”并發(fā)工作模式的多個發(fā)送者同時給服務(wù)器B發(fā)送數(shù)據(jù)塊時，容易在服務(wù)器B處形成瓶頸，造成網(wǎng)絡(luò)擁塞，引起瓶頸鏈路吞吐量急劇下降，產(chǎn)生大量丟包。另外，在并發(fā)傳輸過程中，當(dāng)某個服務(wù)器發(fā)生了傳送超時而其他服務(wù)器已經(jīng)完成了傳輸，則客戶端在接收到剩余SRU之前必須等待至少RTOmins。等待期間客戶端的鏈路很有可能處于完全空閑狀態(tài)，亦容易導(dǎo)致吞吐量顯著下降且總的請求延遲急劇增加，產(chǎn)生吞吐量崩潰現(xiàn)象，這個現(xiàn)象就是常說的 TCP Incast問題［11-12］。

2．2 DCTCP協(xié)議原理分析

TCP Incast問題被提出后，國內(nèi)外的研究者從不同角度提出了解決該問題的方案。DCTCP［1］是近年來提出的一個改進TCP協(xié)議的算法。該算法需要發(fā)送端、接收端、中間交換機三者的協(xié)作。如圖1所示，交換機B檢測隊列長度，當(dāng)隊列長度大于某個閾值K時，認為網(wǎng)絡(luò)處于擁塞狀態(tài)，在數(shù)據(jù)包中做顯式擁塞通知(Explicit Congestion Notification，ECN)的CE標(biāo)記;接收端C收到帶有ECN標(biāo)記的包后，在每個反向ACK包中做ECN-echo標(biāo)記;發(fā)送端收到ACK后，利用式(1)估計擁塞程度，其中，α為發(fā)送端測量被標(biāo)記的包的部分，α在每一個RTT中被更新。α的值代表了緩沖區(qū)占用大于閾值K的可能性，即α接近于0表示可能性很小(緩沖區(qū)占用小)。F表示被標(biāo)記的ACK在所有的ACK中的比例。發(fā)送端再按式(2)調(diào)整擁塞窗口。

DCTCP協(xié)議比較簡單，在一定程度上明顯改善了TCP Incast問題。但是通過分析，其存在如下缺點:

(1)反饋慢。整個反饋過程需要交換機做標(biāo)記，數(shù)據(jù)到了接收端C后，C在反向ACK中再次做標(biāo)記發(fā)送到發(fā)送端An，發(fā)送端再根據(jù)式(1)估計擁塞程度，并按式(2)調(diào)整擁塞窗口。這種算法環(huán)節(jié)多，尤其是接收端主機位于普通網(wǎng)絡(luò)中，延遲較大。

(2)擁塞估計不準確。一個原因是由于反饋信息滯后;另外一個原因是擁塞信息太簡單，只是根據(jù)一個隊列閾值發(fā)送單值擁塞信息。

3 FFDTCP協(xié)議

針對DCTCP存在的問題，本文提出了FFDTCP協(xié)議。如圖1所示，該算法在交換機B根據(jù)當(dāng)前隊列長度判斷網(wǎng)絡(luò)擁塞程度后，直接將擁塞信息利用反向的ACK包發(fā)送給發(fā)送端A，發(fā)送端不需要估計算法直接根據(jù)擁塞反饋信息調(diào)整擁塞窗口，因此節(jié)省了交換機B到接收端C這段的時延。而且為了準確反饋擁塞信息，使用了3個比特位標(biāo)識擁塞程度，提供了更準確的擁塞反饋。

3．1 中間交換機的快速擁塞反饋

中間交換機可以根據(jù)隊列長度直接判斷擁塞情況。本文假設(shè)交換機使用 RED(Random Early Detection)算法［4，8］。該算法在當(dāng)前交換機、路由器中廣泛實現(xiàn)，是基本隊列算法。RED算法認為緩沖區(qū)隊列長度超過一定的閾值是擁塞即將出現(xiàn)的征兆，故RED算法通過檢測緩沖區(qū)隊列長度來發(fā)現(xiàn)擁塞的征兆，及時采取措施來防止擁塞，這就避免了擁塞對業(yè)務(wù)性能的不利影響，同時也避免了振蕩。在RED算法中，對每個隊列設(shè)置2個門限 minth和maxth，avq為平均隊列長度。FFDTCP新添加一個隊列閾值midth，設(shè)為minth和maxth的中間值。不同的隊列長度對應(yīng)不同的擁塞程度，交換機在反向ACK包上做標(biāo)記。這些標(biāo)記使用了網(wǎng)絡(luò)層包頭保留的8 bit的區(qū)分服務(wù)字段中的3個比特位，初始值為000，標(biāo)記的含義如表1所示。

表1 擁塞標(biāo)記的含義

3．2 發(fā)送端擁塞窗口的調(diào)整

假設(shè)收到的擁塞程度標(biāo)記值用θ表示，當(dāng)發(fā)送端收到交換機發(fā)送來的反饋信息后，根據(jù)標(biāo)記值的不同，按照不同的方式調(diào)整擁塞窗口:

(1)當(dāng)θ=000時:如表1所示，θ=000表示網(wǎng)絡(luò)不擁塞，因此TCP的擁塞窗口按照標(biāo)準TCP的算法調(diào)整。每收到一個ACK，按式(3)增加擁塞窗口。

(2)當(dāng)θ=001時:如表1所示，θ=001表示網(wǎng)絡(luò)雖然不擁塞但是即將面臨擁塞，因此保持擁塞窗口大小不變，窗口變化如式(4)所示。

(3)當(dāng)θ=011時:如表1所示，θ=011表示網(wǎng)絡(luò)處于嚴重擁塞狀態(tài)，發(fā)送端將按照標(biāo)準TCP的方式即式(5)調(diào)整擁塞窗口。

(4)當(dāng)θ=010時:如表1所示，θ=010表示網(wǎng)絡(luò)處于擁塞階段，但是還沒有嚴重到(3)的程度，因此:

由于這時網(wǎng)絡(luò)擁塞程度介于(2)和(3)之間，因此 0．5≤k≤1，本文取一個中間值0．75。

3．3 發(fā)送端擁塞反饋通知

發(fā)送端收到中間交換機的擁塞通知后，為了防止中間交換機不停地發(fā)送反饋信息，可以發(fā)送一個擁塞反饋通知消息，標(biāo)記值為111。交換機收到該通知后，停止發(fā)送擁塞通知。當(dāng)擁塞程度發(fā)生變化的時候(比如從擁塞變?yōu)閲乐負砣?，再重新發(fā)送新的擁塞通知。

3．4 協(xié)議的理論分析

通過以上分析可知，F(xiàn)FDTCP協(xié)議相對簡單，在保證低時延的情況下同時具有高吞吐量，具體特點如下:

(1)反饋迅速、準確。中間交換機通過用3個比特位判斷擁塞信息可以快速地給發(fā)送端反饋。其延遲分析如下:在圖1中，DCTCP時延用 λ表示，λ1為A到B的鏈路時延，λ2為交換機B處的排隊時延，λ3為B到接收端C處的鏈路時延，λ4、λ5分別為反饋信息C到B和B到A的鏈路時延，由分析可知λ=λ1+λ2+λ3+λ4+λ5;用Ω表示FFDTCP的時延，則知道Ω=λ1+λ5;對λ和Ω進行比較，顯然Ω＜＜λ，所以，F(xiàn)FDTCP能夠使反饋更迅速和準確。

(2)簡單。相比于DCTCP，F(xiàn)FDTCP算法只需要交換機判斷擁塞情況，發(fā)送端不需要估計計算;另外借助擁塞確認，使交換機能夠準確地收到發(fā)送端發(fā)來的確認擁塞信息，并且發(fā)送端窗口已經(jīng)做了相應(yīng)的調(diào)整。

(3)不額外占用網(wǎng)絡(luò)帶寬。交換機B給發(fā)送端A的反饋信息借助ACK包，從而節(jié)省了網(wǎng)絡(luò)帶寬。

4 模擬實驗與結(jié)果分析

本文采用軟件NS2進行模擬，模擬拓撲與圖1相同(這是一個典型的數(shù)據(jù)中心網(wǎng)絡(luò))，網(wǎng)絡(luò)環(huán)境參數(shù)鏈路帶寬設(shè)置為1 Gb/s，服務(wù)器請求單元為256 KB，交換機緩沖區(qū)大小分別為64 KB和128 KB，發(fā)送端分別運行普通 TCP，DCTCP，F(xiàn)FDTCP，每次模擬運行時間為100 s。

4．1 吞吐量分析

圖2和圖3為發(fā)送端分別運行普通 TCP，DCTCP和FFDTCP時的吞吐量大小比較。

圖2 緩沖區(qū)為64 KB時3種協(xié)議的吞吐量比較

圖3 緩沖區(qū)為128 KB時3種協(xié)議的吞吐量比較

圖2為緩沖區(qū)大小為64 KB時3種協(xié)議下的吞吐量比較。通過圖2可以看出，當(dāng)Server個數(shù)增大到36之前，F(xiàn)FDTCP一直保持著比較高的吞吐量，吞吐量在Server個數(shù)為36時有所波動，Server個數(shù)大于36時吞吐量開始急劇下降;DCTCP在Server個數(shù)約為36時就出現(xiàn)吞吐量急劇下降的情況;TCP在Server個數(shù)為8時吞吐量就開始明顯降低了。同時可以看出當(dāng)Server個數(shù)為40時，F(xiàn)FDTCP的吞吐量也開始急劇下降。這是由于當(dāng)Server的個數(shù)增加時，即“多對一”模型中發(fā)送端數(shù)目偏大的情況下，緩沖區(qū)很快會被完全占據(jù)，造成隨后的數(shù)據(jù)丟包以及數(shù)據(jù)重傳，從而降低了吞吐量。但FFDTCP吞吐量下降的幅度也比DCTCP和TCP的小，最后FFDTCP的吞吐量維持在300 Mb/s～400 Mb/s之間，DCTCP維持在250 Mb/s，TCP 維持在100 Mb/s～200 Mb/s。因此當(dāng)交換機緩沖大小為64 KB時，與傳統(tǒng)TCP和DCTCP相比較，F(xiàn)FDTCP在吞吐量方面很好地解決了TCP Incast問題。

圖3則是在交換機緩沖區(qū)大小為128 KB時進行的仿真結(jié)果。從圖3可以看出，F(xiàn)FDTCP一直保持在900 Mb/s左右的吞吐量;DCTCP在Server超過36時吞吐量開始急劇下降;TCP在Server為16時吞吐量開始大幅度下降。可以看出在相同環(huán)境下，F(xiàn)FDTCP比DCTCP和TCP能保證更高的吞吐量。

從圖2和圖3的模擬結(jié)果中可以看出，瓶頸鏈路交換機緩沖區(qū)大小對解決TCPIncast問題有一定影響。在同一交換機緩沖區(qū)下，相對于 TCP和DCTCP，F(xiàn)FDTCP能夠更好地解決TCPIncast問題。例如，在128KB的緩沖區(qū)下，當(dāng)Server個數(shù)大于36時，F(xiàn)FDTCP仍能夠保持高的吞吐量。其主要原因是FFDTCP通過中間交換機利用2個顯式通知位通告4種擁塞級別，發(fā)送端可以快速準確地調(diào)整擁塞窗口，使擁塞窗口的變化不至于太激烈，加快恢復(fù)的速度;TCP在Server為16時吞吐量開始大幅度下降，主要原因是丟包導(dǎo)致TCP擁塞控制，發(fā)送窗口減半，降低發(fā)送速率，并且TCP擁塞控制后恢復(fù)較慢;DCTCP在Server個數(shù)為36之前能保持比較高的吞吐量，128 KB大的緩沖區(qū)起到比較關(guān)鍵的作用。在Server大于36時吞吐量開始大幅度下降，因為1比特位擁塞信息過于簡單，使發(fā)送端不能及時準確地調(diào)整擁塞窗口。而當(dāng)Server個數(shù)小于8時，3種協(xié)議吞吐量方面并無很大差異主要原因是當(dāng)Server少時，總的流量小，交換機的緩沖區(qū)不容易溢出，而且緩沖區(qū)隊列長度一般小于 minth(所以 DCTPC，F(xiàn)FDTCP檢測不到擁塞)，所以，3個協(xié)議的吞吐量相差不多。

4．2 時延分析

圖4則為發(fā)送端分別運行普通TCP協(xié)議、DCTCP協(xié)議和FFDTCP在緩沖區(qū)為128 KB時的時延分析比較。

圖4 3種協(xié)議的時延比較

由圖4可以看出，當(dāng)Server個數(shù)大于25時，DCTCP的時延開始增加，TCP的時延開始急劇增加。這是由于DCTCP采用顯式擁塞通知功能ECN，在判斷擁塞即將發(fā)生的時候，接收端通過標(biāo)記反饋給發(fā)送端擁塞信息，通知即將發(fā)生的擁塞，而普通擁塞控制算法TCP是根據(jù)丟包來判斷擁塞發(fā)生的。當(dāng)服務(wù)器數(shù)目超過40時，F(xiàn)FDTCP還沒有受到TCP Incast問題影響。而TCP和 DCTCP已經(jīng)出現(xiàn)了不同程度的時延。這是由于DCTCP擁塞信息太簡單，只是根據(jù)一個隊列閾值發(fā)送單值擁塞信息，而且擁塞反饋慢，發(fā)送端不能及時調(diào)整擁塞窗口，從而容易造成交換機平均隊列長度增加甚至緩沖溢出。而FFDTCP剛好在這方面有所改善，根據(jù)當(dāng)前交換機緩沖區(qū)檢測到的當(dāng)前隊列情況，可以發(fā)送多值擁塞信息，快速的通知發(fā)送端動態(tài)地調(diào)整擁塞窗口，讓交換機隊列平均長度處于一個較低的值，從而減小延時。

5 結(jié)束語

本文主要研究云計算數(shù)據(jù)中心網(wǎng)絡(luò)中的TCP Incast問題。首先對相關(guān)背景進行介紹，包括國內(nèi)外研究成果以及研究現(xiàn)狀進行全面的綜述，然后針對數(shù)據(jù)中心網(wǎng)絡(luò)中的吞吐量急劇下降和時延問題，在研究DCTCP的基礎(chǔ)上提出一種新的協(xié)議FFDTCP，并通過NS2仿真實驗對該問題的幾種解決方案進行比較分析，發(fā)現(xiàn)FFDTCP能夠很好地解決TCP Incast問題，并能提高數(shù)據(jù)中心網(wǎng)絡(luò)中傳輸協(xié)議的性能。下一步工作將增加評測的指標(biāo)和環(huán)境的復(fù)雜度，并考慮增加背景流量，構(gòu)建更符合實際網(wǎng)絡(luò)的評測環(huán)境。

［1］ Alizadeh M，Greenberg A，Maltz D A，et al．Data Center TCP(DCTCP)［J］．ACM SIGCOMM Computer Communication Review，2010，40(4):63-74．

［2］ Phanishayee A，Krevat E，Vasudevan V，et al．Measurement and Analysis of TCP Throughput Collapse in Cluster-based Storage Systems［C］//Proceedings of the 6th USENIX Conferenceon Fileand Storage Technologies，F(xiàn)ebruary 26-29，2008，San Jose USA．Berkeley，USA:USENIX Association，2008:1-14．

［3］ Rewaskar S，Kaur J，Smith F D．A Performance Study of Loss Detection/Recovery，in Real-world TCP Implementations［C］//Proceedings ofIEEE International Conference on Network Protocols．Washington D．C．，USA:IEEE Press，2007:256-265．

［4］ Alizadeh M，Javanmard A，Prabhakar B．Analysis of DCTCP:Stability，Convergence，and Fairness［C］//Proceedings of ACM SIGMETRICS Joint International Conference on Measurement and Modeling of Computer Systems．New York，USA:ACM Press，2001:73-84．

［5］ Wu Haitao，F(xiàn)eng Zhenqian，Guo Chuanxiong，et al．ICTCP:Incast Congestion Control for TCP in Data Center Networks［J］．IEEE/ACM Transactionson Networking，2013，21(2):345-358．

［6］ Alizadeh M，Atikoglu B，Kabbani A，et al．Data Center Transport Mechanisms:Congestion Control Theory and IEEE Standardization［C］//Proceedings of the 46th Annual Allerton Conference on Communication，Control，and Computing，October 1-5，2008，Allerton，USA．Washington D．C．，USA:IEEE Press，2008:1270-1277．

［7］ McCanne S，F(xiàn)loyd S．Network Simulator——NS-2［EB/OL］．［2014-03-15］．http://www．isi．edu/nsnam/ns/．

［8］ Ghemawat S，Gobioff H，Leung Shun-Tak．The Google File System［C］//Proceedings of ACM Symposium on Operating Systems Principles．New York，USA:ACM Press，2003:29-43．

［9］ de Candia G，Hastorun D，Jampani M，et al．Dynamo:AmazonsHighly Available Key-value Store［C］//Proceedings of the 21st ACM Symposium on Operating Systems Principles，October 14-17，2007，Skamania Lodge，USA．New York，USA:ACM Press，2007:205-220．

［10］ 李 震，杜中軍．云計算環(huán)境下的改進型Map-Reduce模型［J］．計算機工程，2012，38(11):27-29，37．

［11］ Vasudevan V，Phanishayee A，Shah H，et al．Safe and Effective Fine-grained TCP Retransmissions for Datacenter Communication［C］//Proceedings of SIGCOMM’09，August 17-21，2009，Barcelona，Spain．New York，USA:ACM Press，2009:303-314．

［12］ Podlesny M，Williamson C．An Application Level Solution for the TCP-incast Problem in Data Center Networks［C］//Proceedings of the 19th International Workshop on Quality of Service，June 16-18，2011，San Jose，USA．Washington D．C．，USA:IEEE Press，2011:1-23．