數據中心網絡快速反饋傳輸控制協議

蘇凡軍，牛詠梅，邵 清

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

1 概述

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

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

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

2 TCP Incast問題與解決方案

2．1 數據中心網絡TCP Incast問題

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

圖1 TCP Incast模型示意圖

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

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

2．2 DCTCP協議原理分析

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

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

(1)反饋慢。整個反饋過程需要交換機做標記，數據到了接收端C后，C在反向ACK中再次做標記發送到發送端An，發送端再根據式(1)估計擁塞程度，并按式(2)調整擁塞窗口。這種算法環節多，尤其是接收端主機位于普通網絡中，延遲較大。

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

3 FFDTCP協議

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

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

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

表1 擁塞標記的含義

3．2 發送端擁塞窗口的調整

假設收到的擁塞程度標記值用θ表示，當發送端收到交換機發送來的反饋信息后，根據標記值的不同，按照不同的方式調整擁塞窗口:

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

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

(3)當θ=011時:如表1所示，θ=011表示網絡處于嚴重擁塞狀態，發送端將按照標準TCP的方式即式(5)調整擁塞窗口。

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

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

3．3 發送端擁塞反饋通知

發送端收到中間交換機的擁塞通知后，為了防止中間交換機不停地發送反饋信息，可以發送一個擁塞反饋通知消息，標記值為111。交換機收到該通知后，停止發送擁塞通知。當擁塞程度發生變化的時候(比如從擁塞變為嚴重擁塞)，再重新發送新的擁塞通知。

3．4 協議的理論分析

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

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

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

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

4 模擬實驗與結果分析

本文采用軟件NS2進行模擬，模擬拓撲與圖1相同(這是一個典型的數據中心網絡)，網絡環境參數鏈路帶寬設置為1 Gb/s，服務器請求單元為256 KB，交換機緩沖區大小分別為64 KB和128 KB，發送端分別運行普通 TCP，DCTCP，FFDTCP，每次模擬運行時間為100 s。

4．1 吞吐量分析

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

圖2 緩沖區為64 KB時3種協議的吞吐量比較

圖3 緩沖區為128 KB時3種協議的吞吐量比較

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

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

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

4．2 時延分析

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

圖4 3種協議的時延比較

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

5 結束語

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

［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，February 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，Feng 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，Floyd 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］ 李 震，杜中軍．云計算環境下的改進型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．