數據中心網絡TCP Incast仿真分析

郭麗娜

（中國航天科工集團第二研究院706所，北京100854）

0 引 言

由于數據中心網絡需要可靠傳輸，所以在廣域網成功應用多年的TCP可靠傳輸協議目前也普遍應用于數據中心網絡中，但是本身針對于廣域網環境設計的TCP協議并不適合高帶寬、低延遲的數據中心網絡環境，比如在網絡中普遍使用的Linux 操作系統中，TCP 的重傳超時計時器RTO 默認值為200ms，該值遠遠大于數據中心網絡的平均RTT 值 （一般為10μs至100μs）［1］。

TCP Incast問題指［2］：在數據中心網絡中，當多個發送者同時向一個接收者發送數據塊時，隨著發送者個數的增多，接收者的瓶頸鏈路吞吐率會急劇下降，產生吞吐率崩潰現象。由于這種多對一的網絡模型在數據中心網絡中普遍存在，所以TCP Incast成為數據中心網絡傳輸性能的突出問題。

本文對TCP Incast問題進行了詳細的介紹，并通過NS2仿真實驗對該問題進行了深入的分析。

1 TCP Incast問題

1.1 問題背景

數據中心網絡的環境特點和通信模型是導致TCP In－cast問題的主要因素。

數據中心網絡鏈路為高帶寬、低延遲鏈路；同一個機架上的服務器由一個架頂交換機［3］（top of rack switch）鏈接，目前數據中心由于成本限制，采用的架頂交換機一般為商品交換機［4］，具有淺緩沖區的特點；同時數據中心網絡中大部分流量為短數據流［5］，如搜索引擎的查詢請求產生的數據流。

數據中心網絡具有典型的劃分聚合通信模型［4］（Partition／Aggregate）。如圖1 所示，當一個任務請求到來，由一個Aggregator將任務分配給下層的多個Aggregator，逐層下發后最終分配給實際執行任務的 Worker 節點。Worker執行完任務后將結果返回給上層Aggregator，Aggregator逐層向上匯聚，最后得到結果。數據中心網絡中像搜索引擎這樣對時效性要求嚴格的應用，在此過程中會限制延遲的時間，如果一個查詢請求延遲限制 （deadline）為250ms，每一層劃分都會縮小延遲限制值，超過deadline的任務就會被舍棄，影響最終結果的質量。

圖1 劃分聚合通信模型

劃分聚合通信模型普遍存在于數據中心網絡的應用程序中。例如搜索引擎：一個關鍵字的查詢請求分發給多個Worker進行計算，然后將多個結果同時返回，最終匯聚給終端用戶；MapReduce計算模型［6］：大量的key－value鍵值對中間結果從多個mapper同時發送匯聚給reducer；分布式存儲集群［2］：多個存儲節點向請求數據的節點同時發送應答。

1.2 問題描述

由以上背景可知，數據中心網絡中普遍存在多對一的通信模型，如圖2所示，當一個任務被分發給多個服務器處理后，多個服務器將執行結果同時發送給請求者接收端，同一批發送的執行結果稱為數據塊 （data block），其中每一個服務器發送一個服務請求單元 （SRU）。隨著同時發送的服務器數量的增多，接收端與交換機之間的鏈路吞吐率會急劇下降，這種多對一發送模式下接收者吞吐率崩潰的現象稱為TCP Incast問題。

圖2 TCP Incast多對一場景

1.3 問題原因

產生該問題的主要原因是：①數據突發性同時傳輸，交換機淺緩沖區容量有限，導致緩沖區溢出，造成后到數據包的丟失；②大量丟包導致TCP擁塞控制，發送窗口減半，降低發送速率；③TCP 對丟包進行超時重傳，根據RTO 默認值，超時一般會持續200ms，而數據中心網絡中RTT （10μs至100μs）遠遠小于RTO，導致鏈路有90%以上空閑［2］。

2 NS2仿真實驗設計

本文基于廣泛使用的開源網絡仿真平臺軟件NS2［7］（版本為NS2.35），在Linux系統 （Fedora 13）下開發仿真實驗程序并運行仿真實驗。

如圖3所示，采用多對一的網絡拓撲結構，實線表示鏈路，所有鏈路帶寬為1000 Mbps，鏈路延遲為25μs，交換機R0和接收者R1之間為瓶頸鏈路。虛線表示節點綁定的代理，每個發送節點綁定TCP 協議和FTP 應用，FTP發送SRU 大小256KB，接收者R1為每一個鏈接綁定接收代理TCPSink。仿真程序在所有發送者同一批SRU 都被接收到以后再發送下一批。

圖3 NS2仿真網絡拓撲

詳細實驗參數設置如表1所示。下一節將通過改變交換機緩沖區大小、SRU 大小和RTO 最小值來分析實驗結果。當某一個參數變化時，其它參數保持不變。

表1 NS2仿真參數

實驗結果主要考察瓶頸鏈路性能，即接收者R1的吞吐率隨著發送端Server數量不同的變化情況。

3 實驗及分析

3.1 TCP Incast現象

如圖4所示，當同時發送的Server數量較小時，吞吐率在900Mbps左右，當Server數量增加到8時，吞吐率崩潰到100 Mbps 以下，產生TCP Incast現象，之后隨著Server數量的增多，吞吐率一直徘徊在100 Mbps到200 Mbps之間。

實驗結果與文獻 ［8］的結果一致，而文獻 ［2］中的復現結果在Server數量為4時吞吐率降低到300 Mbps到400 Mbps之間，之后再降低到100 Mbps。

3.2 不同TCP改進協議的性能

圖4 TCP Incast現象

由于TCP擁塞控制算法和差錯控制算法是影響TCP協議傳輸性能的主要因素，因此，我們實驗比較了采用不同算法的幾種典型的TCP改進協議在云數據中心網絡環境下TCP Incast場景中的性能。主要實驗測量了快速恢復算法的NewReno、選擇性應答的Sack、二分搜索尋找目標窗口的Bic和通過上次擁塞事件消逝事件檢測網絡擁塞程度的HTCP。

如圖5所示，以上4種TCP改進協議都產生了相同的吞吐率曲線趨勢，沒有改進TCP Incast問題。細微的差別只是產生吞吐率崩潰的Server數量略有不同。

圖5 TCP改進協議比較

3.3 不同緩沖區大小條件的性能

由1.3節的問題原因分析可知，產生TCP Incast問題的關鍵在于交換機緩沖區過小導致的溢出和丟包。因此，我們通過調整緩沖區大小，實驗比較了不同緩沖區大小條件下的傳輸性能。圖6 顯示了實驗結果，當緩沖區由32 KB不斷增大到1024KB 時，吞吐率崩潰發生的Server數量隨之增大。

實驗結果表明，通過增大瓶頸交換機緩沖區大小可以解決TCP Incast問題。但是該方法有兩個缺點：一是大緩沖區的交換機價格很高，如Force10E1200價格約為5萬美元［2］，架頂交換機都增大緩沖區會提高數據中心建設成本，違背數據中心通過規模化經濟原理降低成本的初衷；二是即使增大了交換機的緩沖區也會帶來問題，如前面所述，數據中心網絡多為延遲敏感的短數據流，大緩沖區會增大后到的短數據流排隊等待的時間［4］。

圖6 不同緩沖區大小比較

3.4 不同服務請求單元條件的性能

如圖7所示，實驗結果顯示，增大服務請求單元SRU的大小有助于減輕TCP Incast問題。當SRU 增大至8192 KB時，帶寬利用率可以保持在80%以上。更大的SRU 使得發送端Server在等待超時事件發生的同時更有效利用鏈路空余帶寬，減小等待超時對帶寬利用率的損耗。

圖7 不同SRU 比較

但是，該方法也存在以下兩個缺點：

（1）大的SRU 在數據中心網絡的大部分應用中是不可行的。數據中心分布式計算的宗旨就是將一個任務分散到大量的計算節點，每個計算節點快速地計算完成一個小數據塊，最終匯聚返回結果。假設一個任務的總量為8 MB，若SRU 大至8 MB，則該任務只分配給一個計算節點，計算時間取決于單個節點處理8 MB 任務的時間；如果SRU為256KB，則該任務會分配給32 個計算節點，單個計算節點的計算時間明顯較小。

（2）在快速的分布式存儲系統中，更大的SRU 會增加請求端內核的內存壓力，可能造成請求的失敗［2］。

3.5 不同RTO 最小值條件的性能

如1.3節所述，造成TCP Incast問題的主要原因之一是TCP對丟包進行超時重傳，而默認的RTO 遠遠大于數據中心網絡的RTT值，重傳等待造成鏈路空閑。如圖8所示，減小RTO最小值有助于減輕Incast現象，提高吞吐率。

圖8 不同RTO 最小值比較

TCP協議存在延遲ACK 概念，即不立即發送ACK，而是等待一段延遲時間將ACK 與該方向發送的數據包一起發送。Linux 系統默認的延遲ACK 等待時間為40 ms［9］，當RTO 最小值減小至低于40ms時，將產生ACK 還未到達就超時重傳的冗余現象。所以我們通過關閉延遲ACK 觀察TCP Incast情況，如圖9所示，在RTO 最小值默認200 ms時，關閉延遲ACK 對吞吐率沒有影響；在RTO 最小值減小到40 ms和1 ms時，關閉延遲ACK 有助于提高吞吐率。

圖9 不同RTO 及關閉延遲ACK 比較

但是該方法存在實現可行性和安全性兩個缺點。首先，小的RTO 最小值需要操作系統很小的時鐘粒度支持，現有的Linux 操作系統時鐘粒度無法實現1ms 的RTO 最小值［2］。其次，過小的RTO 最小值可能導致大量不必要的重傳，即使時鐘粒度支持小RTO 的實現，對于其取值的權衡也需要進一步研究。

3.6 調整TCP擁塞窗口限值

通過對TCP Incast現象的深入分析，我們發現，造成吞吐率急劇下降的一個主要原因是各個服務器在傳輸時對發送速率缺乏約束，沒有根據網絡狀況進行適應性調整。因此，我們根據網絡狀況，通過動態調整擁塞窗口限值來控制各個服務器的發送速率，使其不超過其公平分享帶寬，以此避免擁塞發生，從而提高TCP Incast傳輸模式的傳輸性能。該算法主要原理如下：

首先，計算鏈路的容量

式中：BW——瓶頸帶寬，RTT——往返時延，Queue——鏈路上的隊列長度，其值主要由交換機的緩存大小決定。

然后，計算每個服務器流的公平分享容量

式中：N——同時傳輸的服務器流數目。然后，設置每個流擁塞窗口的限值為Cs。

在每次傳輸初始，系統計算好Cs，動態調整擁塞窗口限值，而不是采用固定的默認值。圖10顯示了在第2節介紹的實驗配置下，采用動態擁塞窗口限值算法與默認情況的實驗結果對比，從圖中可以看出，采用動態擁塞窗口限值算法顯著地提高了TCP Incast傳輸模式的性能。

圖10 動態擁塞窗口限值效果 （1G 鏈路）

圖11顯示了在10G 瓶頸鏈路帶寬環境下，采用動態擁塞窗口限值優化算法與默認窗口的實驗結果對比，在10G高速網絡環境下，在服務器數目較大時，該算法相對于1G鏈路帶寬環境優勢更明顯。

圖11 動態擁塞窗口限值效果 （10G 鏈路）

但是，調整擁塞窗口限值的方法具有依賴于計算和手動配置的局限性，難以適用于變化的環境。

4 結束語

本文通過NS2仿真實驗對數據中心網絡中的TCP Incast問題進行了研究。通過改變交換機緩沖區、服務請求單元SRU、RTO 最小值等影響因素進行實驗和比較分析，發現增大緩沖區、增大SRU、減小RTO 最小值以及在小RTO 情況下關閉延遲ACK 等方法可以減輕TCP Incast問題，但是這些方法在數據中心網絡中都存在缺點和局限性。由于TCP擁塞控制算法是影響TCP 協議性能的一個主要原因，而標準TCP協議擁塞控制算法是針對低帶寬低時延的網絡環境設計的，現有主流的各種TCP改進協議的擁塞控制算法主要是針對高帶寬高時延網絡進行改進的，在低帶寬低時延的云數據中心網絡環境中性能同標準TCP一樣性能不佳，因此，要從根本上解決云數據中心網絡中TCP Incast性能問題，需要研究針對云數據中心網絡特點的TCP擁塞 控制算法和 傳輸協議［3－4，10－12］。

［1］Chen Y，Griffith R，Liu J，et al.Understanding TCP Incast throughput collapse in datacenter networks ［C］／／In Proc 1stACM Workshop on Research on Enterprise Networking，2009.

［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 Conference on File and Storage Technologies，2008：1－14.

［3］Wu H，Feng Z，Guo C，et al.ICTCP：Incast congestion con－trol for TCP in data center networks［C］／／In ACM CoNEXT，2010.

［4］Alizadeh M，Greenberg A，Maltz D，et al.Data center TCP（DCTCP）［C］／／In Proc ACM SIGCOMM，2010.

［5］Kandula S，Sengupta S，Greenberg A，et al.The nature of datacenter traffic：Measurements and analysis ［C］／／In Proc of Internet Measurement Conference，2009.

［6］Dean J，Ghemawat S.MapReduce：Simplified data processing on large clusters［C］／／6th Symposium on Operating Systems Design and Implementation，2008：137－149.

［7］The network simulator－ns－2［EB／OL］.［2013－09－01］.http：／／www.isi.edu／nsnam／ns／.

［8］Zhang J，Ren FY，Lin C.Modelling and understanding TCP Incast in data center networks［C］／／Proceedings of the 30th IEEE International Conference on Computer Communications，2011.

［9］Vasudevan V，Phanishayee A，Shah H，et al.Safe and effective fine－grained TCP retransmissions for datacenter communication ［C］／／In Proceedings of the ACM SIGCOMM，2009：303－314.

［10］Adrian S－W Tam，Kang Xi，Yang Xu，et al.Preventing TCP Incast throughput collapse at the initiation，continuation，and termination ［C］／／In Proc IEEE 20th International Workshop on Quality of Service，2012.

［11］Jaehyun Hwang，Joon Yoo，Nakjung Choi.IA－TCP：A rate based Incast－avoidance algorithm for TCP in data center networks［C］／／In Proc IEEE International Conference on Communications，2012：1292－1296.

［12］Jun Zhang，Jiangtao Wen，Jingyuan Wang，et al.TCP－FITDC：An adaptive approach to TCP Incast avoidance for data center applications［C］／／In Proc ICNC，2013.