TCP Incast and Cloud application performance--Brad Hedlund's blog20110501
Incast問(wèn)題來(lái)自于分布式存儲(chǔ)和計(jì)算架構(gòu)，例如Hadoop、MapReduce、HDFS、Cassandra等等，還有一些應(yīng)用，例如web搜索，maps，社交網(wǎng)絡(luò)，數(shù)據(jù)倉(cāng)庫(kù)和分析等。使用分布式存儲(chǔ)架構(gòu)可以增加服務(wù)器集群的計(jì)算存儲(chǔ)和處理能力，隨著服務(wù)器集群規(guī)模的增大，對(duì)應(yīng)用性能的影響有利有弊。優(yōu)勢(shì)是增加應(yīng)用性能，越大的集群會(huì)提供更高的分布式處理能力，更多的工作會(huì)完成的更快。劣勢(shì)是增加了前端服務(wù)器發(fā)生incast擁塞的幾率，同時(shí)也會(huì)降低單個(gè)服務(wù)器的吞吐量。
實(shí)際應(yīng)用中，云數(shù)據(jù)中心仍在不斷的增加服務(wù)器集群的規(guī)模，因此我們要確定：Incast擁塞問(wèn)題對(duì)應(yīng)用性能的影響到底有多大？我們?cè)鯓硬拍軠?zhǔn)確的測(cè)量和降低incast問(wèn)題帶來(lái)的影響？
TCP的變種DCTCP優(yōu)化了擁塞監(jiān)測(cè)方案，能夠最小化收到incast影響的數(shù)據(jù)集，最小化丟包率和重傳時(shí)延。優(yōu)勢(shì)是降低了交換機(jī)緩沖區(qū)的利用率，減輕了交換機(jī)緩沖區(qū)的負(fù)擔(dān)。缺點(diǎn)是只有長(zhǎng)流DCTCP才能精確監(jiān)測(cè)到擁塞并作出反應(yīng)，短流效果不明顯。
更優(yōu)的方案就是：高性能的交換機(jī)+DCTCP等優(yōu)化方案。其中交換機(jī)可以處理micro burst的incast問(wèn)題，DCTCP可以對(duì)較長(zhǎng)的流處理incast問(wèn)題。
incast的增加的時(shí)延取決于TCP的RTO設(shè)置，廣域網(wǎng)環(huán)境中一般為200ms。數(shù)據(jù)中心環(huán)境要降低兩個(gè)三個(gè)數(shù)量級(jí)。
Incast的超時(shí)重傳的時(shí)延主要來(lái)自于兩種時(shí)延：Block Tail time out (BTTO) and Block Head Time out (BHTO) 。BTTO塊尾部超時(shí)指的是同時(shí)連接的服務(wù)器數(shù)量較少，但某個(gè)塊中的發(fā)送端發(fā)送的最后一個(gè)或幾個(gè)數(shù)據(jù)被丟棄了，此時(shí)就要等要RTO結(jié)束后重傳該數(shù)據(jù)包。這是TCP incast的固有屬性，當(dāng)所有數(shù)據(jù)塊都全部被接收到時(shí)，發(fā)送端（服務(wù)器端）才會(huì)初始化下一個(gè)數(shù)據(jù)塊。BHTO塊頭部超時(shí)指的是同時(shí)連接的服務(wù)器數(shù)量很多的情況。服務(wù)器端數(shù)量過(guò)多，發(fā)送窗口同時(shí)被占滿，交換機(jī)緩存空間不夠，造成大量塊數(shù)據(jù)的丟失，需要RTO結(jié)束后才能重傳。
解決方案：
基于優(yōu)先級(jí)的解決方案（PRIN）：在開始將降低每個(gè)服務(wù)器的擁塞窗口值，避免了BHTO。然后將每條流的最后三個(gè)包設(shè)置為高優(yōu)先級(jí)，避免了BTTO。在linux內(nèi)核上實(shí)現(xiàn)了，修改了TCP包頭。
隨機(jī)調(diào)整TCP方案（SA-TCP）：隨機(jī)調(diào)整擁塞窗口避免并行流的同步。就是TCP的AIMD，加法增加，乘法減少。加法增加的步長(zhǎng)是隨機(jī)的，乘法減少還是對(duì)半。優(yōu)勢(shì)：只用修改發(fā)送端的擁塞窗口，是傳輸層的TCP協(xié)議的變種解決方案。缺點(diǎn)：未考慮交換機(jī)緩沖區(qū)大小。
流感知擁塞控制：數(shù)據(jù)中心流量特征：10%數(shù)量的長(zhǎng)流占據(jù)80%的吞吐量，是吞吐量敏感的流，例如熱遷移，軟件更新，分布式數(shù)據(jù)處理應(yīng)用等等。短流是時(shí)延敏感的流，主要對(duì)應(yīng)查詢搜索，遠(yuǎn)程調(diào)用等等。在incast情況下，長(zhǎng)流受到的影響更大。那么，本方案就是要避免長(zhǎng)流受影響。每條長(zhǎng)流的IP頭部的DSCP字段都是一個(gè)特殊的值，在TOR交換機(jī)上，當(dāng)遇到擁塞時(shí)，會(huì)將所有的包都打上CE（擁塞）標(biāo)簽（就是ECN字段修改），在receiver端，當(dāng)匹配到DSCP值為特定值時(shí)，則將其CE標(biāo)簽去掉，這樣，發(fā)送長(zhǎng)流的服務(wù)器就不會(huì)降低擁塞窗口，吞吐量也不會(huì)降低。
優(yōu)勢(shì)：不用修改TCP協(xié)議棧，長(zhǎng)流的吞吐量不會(huì)降低，相比于SDN解決方案（集中式控制器不能很快的解決incast問(wèn)題），該方案能在交換機(jī)上解決incast問(wèn)題，克服了集中式控制的缺點(diǎn)。ECN機(jī)制避免了不必要的丟包，并且在丟包后等待源端重傳數(shù)據(jù)的過(guò)程中，該TCP連接也不會(huì)空閑。
缺點(diǎn)：一是需要一個(gè)專用的交換機(jī)來(lái)為目標(biāo)流打標(biāo)簽，可能會(huì)需要數(shù)據(jù)中心網(wǎng)絡(luò)中硬件平面上的修改；二是ECN包固有的缺陷，即ECN包（包括源Quench消息和ECN字段修改了的ACK包）在到達(dá)TCP發(fā)送端之前就有可能被網(wǎng)絡(luò)丟掉。
主動(dòng)感知控制（PAC）：核心思想為在接收端控制ACK的發(fā)送間隔時(shí)延。本方案主要思想為在接收端維持一個(gè)ACK隊(duì)列，當(dāng)收到數(shù)據(jù)包時(shí)不要立刻回傳ACK，而是將其放在隊(duì)列中，當(dāng)發(fā)現(xiàn)有足夠的內(nèi)存空間可以容納ACK數(shù)量的新數(shù)據(jù)包時(shí)，再回傳ACK。也就是說(shuō)ACK的發(fā)送不再是連續(xù)不斷的，而是要考慮發(fā)送的時(shí)間和緩沖區(qū)具體狀態(tài)。將交換機(jī)緩存大小作為ACK控制算法的初始化門限值。缺點(diǎn)：數(shù)據(jù)中心中交換機(jī)緩沖區(qū)大小差異較大，將交換機(jī)緩沖區(qū)大小作為ACK控制算法的初始值會(huì)不妥，使用ECN作為擁塞標(biāo)記，ECN固有的屬性會(huì)在未到達(dá)發(fā)送端之前被丟包。
相關(guān)工作中將incast解決方案分為兩類：一種是基于窗口大小調(diào)整的，一種是基于恢復(fù)的?；诖翱诖笮≌{(diào)整的典型方案有DCTCP和ICTCP，思想為調(diào)整擁塞窗口大小避免交換機(jī)緩沖池的溢出和丟包。缺點(diǎn)：擁塞窗口的最小值是受限的，為一個(gè)最大分段長(zhǎng)度，因此為了保證不發(fā)生incast問(wèn)題，發(fā)送端的數(shù)量會(huì)受到限制?；诨貜?fù)的方案主要思想為最小化RTO，即最小化丟包后的影響。TCP的特性為當(dāng)發(fā)生丟包后RTO時(shí)間一到會(huì)立即重傳，不用等到鏈路空閑。
評(píng)價(jià)方案指標(biāo)：同時(shí)連接的發(fā)送端數(shù)量，是否需要對(duì)TCP/IP協(xié)議棧做修改，是否需要額外的硬件或?qū)Ｓ媒粨Q機(jī)之類的成本引入。
M21TCP：由交換機(jī)告知連接的服務(wù)器此時(shí)有多少服務(wù)器也同時(shí)連接在該交換機(jī)上并與前端服務(wù)器通信。后端服務(wù)器會(huì)根據(jù)此消息限定自身?yè)砣翱诖笮。_(dá)到避免incast擁塞的效果，對(duì)比方案為RED和ECN。此方案同時(shí)利用了傳輸層和網(wǎng)絡(luò)層，利用了基于流控制方案的路由/交換機(jī)思想。缺點(diǎn)是該方案只針對(duì)單路徑TCP設(shè)計(jì)。
