TCP的擁塞控制 (三)

1.   Multiple Packet Losses

Fast Retransmit/Fast Recovery機制能夠很好地處理單個packet丟失的問題，但當大量packet同時丟包時(一個RTT內)，FR機制可能無濟於事。

下面舉例說明。

下面兩張圖是一次多包丟失的情景。其中上圖中的三條線分別描述的是SND.UNA，SND.NXT，SND.UNA+SND.WND三個變量隨着時間變化的狀況，下圖中的線描述的是擁塞窗口cwnd隨着時間變化的狀況。

因爲丟包具備隨機性，咱們假設下面的情景開始以前，小於65號的包都已經被sender發送出去，但51, 53, 55號在網絡中被丟棄。

在0.83s以前，sender正常的發送packet，而且收到了前面發送的packet的ACK，所以cwnd也在線性增長。可是因爲這個階段發送窗口太大，大量的packet被同時投遞到網絡中，實際上已經致使了網絡擁塞，大量包被丟棄(因爲丟包具備隨機性，咱們假設50號以後的奇數號包被丟棄)，在0.83s才被sender察覺到。此時sender收到packet51的3個重複ACK，按照算法會進入Fast Recovery階段，即重傳packet51，並將cwnd和ssthresh減半。

0.83s以後，sender仍然會繼續收到重複ACK，cwnd會線性增長。在0.96s時刻，cwnd恢復到了Fast Recovery以前的值，以後雖然有新的packet進入擁塞窗口，但超過了發送窗口的範圍，所以仍然不被髮送。在1s時刻，sender收到了響應重傳packet51的ACK，按照算法，cwnd減爲ssthresh，而且發送窗口向前滑動，一個新的packet進入發送窗口，但因爲該packet超過了擁塞窗口的範圍，所以仍然不被髮送。

1s以後，packet51以後的packet都沒法獲得響應。本應用於響應這些packet的ACK被做爲packet51的重複ACK，而且因爲sender再沒法發送新的packet，也就不能產生重複ACK，所以，packet51以後的packet再也沒法獲得響應。此時，網絡處於乾涸狀態(dryout)。最終，只有等到這些packet超時。

在1.5s時刻，packet53超時，觸發重傳，而且進入Slow Start階段。以後，整個網絡又從0開始，嚴重影響網絡性能。

致使這種現象的緣由是不恰當的初始窗口大小，也即ssthresh的值。在早期階段，因爲sender的實際發送窗口較大，其在一個RTT時間內，將發送窗口內的packet一次性投送到網絡上，致使了網絡上的某些路由器隊列溢出，大量的packet被丟棄。

圖 1 一個窗口內丟失多個包的情景

2.   Damped Slow Start

因爲receiver端空洞的存在，每當receiver填充完一個空洞時，就會回覆一個同時響應一大塊區域的ACK，這會致使sender端的發送窗口忽然增大，會有致使網絡擁塞的風險。

一樣看上面的例子。因爲多個包被丟失，在receiver端產生了一個個的空洞。例如，51, 53, 55號包被丟棄，其餘的包被reciever正常接收。

在1.5s時刻時，packet53超時致使重傳，receiver收到packet53以後，填入緩衝區的空洞中，並使用1個ACK響應竟可能大的連續區域，即packet53, 54。

在1.61s時刻，sender收到了一個ACK，將發送窗口向前滑動，並按照算法將cwnd+1。並將窗口裏的packet55, 56發送出去。

在1.73s時刻，sender收到了一個同時響應packet55, 56的ACK，將發送窗口向前滑動，並將cwnd+1。

在1.74s時刻，sender收到了一個響應packet56的ACK，將發送窗口向前滑動，並將cwnd+1。此時，packet56實際上有兩個ACK。

圖 2 窗口激增

3.   False Fast Retransmit

當超時或者收到3次重複ACK時，發送窗口會縮減，許多本來在發送窗口之中的packet離開了發送窗口。當Fast Retransmit結束後，發送窗口又從新開始增加。這會致使以前已經發送出去的packet從新進入發送窗口，被再次發送。重複發送receiver端已有的數據包，不但浪費帶寬，也會致使另外一個問題: False Fast Retransmit。下面舉例說明。

假設TCP處於Slow Start階段。packet58, 59, 60已經在receiver端緩存，當前發送窗口大小爲2，起始爲packet55。

sender將packet55, 56發送出去，收到ACK以後，發送窗口增大爲4，並滑動到packet57，此時，packet57, 58, 59, 60位於發送窗口中，被髮送出去。

receiver在收到packet57後，採起累積確認的方式，在ACK中指明packet61。

sender收到packet57的ACK以後，發送packet61。以後，sender又陸續收到packet58, 59, 60的ACK，均指明packet61，這樣，就收到了3次重複ACK，致使packet61的重傳。

實際上，此時packet61並無丟包，但sender沒法意識到這一點，仍然按規則進行了Fast Retransmit，這就是False Fast Retransmit。

核心問題是，sender沒法區分這兩種狀況致使的3次重複ACK：真正的丟包產生的，以及重複發送receiver端已緩存的包產生的。那麼爲何會有重複發送receiver端已緩存的包的狀況存在呢？這是因爲在多包丟失時，sender端是沒法知道具體哪些包丟失的。由於第一批到來的ACK指明的都是第一個丟失的packet，而沒有其餘丟失的packet的信息。所以，sender要麼採起保守的策略，認爲只有一個packet丟失，從而重傳ACK中指明的那個packet，對於其餘丟失的packet，此時已經沒有可用的重複ACK了，故只能等到超時的到來纔有機會重傳。sender要麼採起更積極的策略，一次重傳多個packet。重傳多個packet雖然可以覆蓋全部的丟失的packet，但也會一併重傳已經被receiver端正常接收並緩存的packet。這就是爲何會有重複發送receiver端已緩存的包的狀況存在。

4.   Multiple Fast Retransmits

因爲False Fast Retransmit時常發生在Fast Recovery階段，所以，算上Fast Recovery階段傳統的Fast Retransmit，若是又發生了False Fast Retransmit，那麼就產生了另一個問題Multiple Fast Retransmits，即一個窗口內，進行了屢次Fast Retransmit，致使窗口迅速減少，影響TCP的性能。

能夠看出，Multiple Fast Retransmits雖然不影響TCP的正確性，但會影響其性能，因此消除Multiple Fast Retransmits有必定的意義。能夠經過消除False Fast Retransmit來達到這一目的。實際上，從上文已經知道，False Fast Retransmit並非必須的，其所重傳的packet會在Fast Recovery階段的其它步驟中發送出去，所以，直接消除False Fast Retransmit並不會影響TCP的正確性。

那麼如今須要考慮的是如何消除False Fast Retransmit。咱們知道，在Fast Recovery階段，觸發False Fast Retransmit的重複ACK，與觸發Fast Retransmit的重複ACK，回覆的都是同一個窗口內的packet，所以，只要在Fast Retransmit以後避免同一個窗口內其餘Fast Retransmit便可。具體方式是，進入Fast Recovery時，標記當前窗口的最大序號high_seq，後續若再次收到3次重複ACK，則判斷其序號是否在當前窗口內(比較與high_seq的大小)。若是是，則忽略這3次重複ACK，不進行Fast Retransmit，不然會致使Multiple Fast Retransmits；若是不是，則進行Fast Retransmit，由於這是下一個窗口的packet，不該算在當前窗口內。

5.   Partial Acknowledgement

當收到3次重複ACK時，sender進入Fast Recovery階段，重傳ACK中指明的packet，以後，當響應這個重傳的packet的ACK到來時，會攜帶receiver端最新的信息，其中包括所等待的下一個packet。

若是當前發送窗口只有一個packet丟失，那麼這個ACK中指明的即爲已接收到的最大的packet序號，它一併回覆了重傳以前sender已發送的全部packet。

例如，sender的發送窗口爲[51, 54]，將全部packet發送出去以後，packet51丟失, sender會收到3次重複ACK，進而重傳packet51，以後，sender會收到重傳的packet51的ACK，其中指明packet55。

而若是當前發送窗口有多個packet丟失，那麼這個ACK指明的就不是最大的packet序號，它僅僅回覆了sender所發送的部分packet。這個ACK就稱爲Partial Acknowledgement。

例如，sender的發送窗口爲[51,58]，將全部packet發送出去以後，packet51, 54, 55丟失，sender會首先收到指明瞭packet51的3次重複ACK，進而重傳packet51，以後，收到packet51的ACK，其中指明的是packet54，由於packet54是receiver端未收到的最小的packet。這個ACK指明的不是packet59，所以沒有回覆sender發送的全部的packet。

傳統TCP認爲一個窗口內只有一個packet會丟失，所以每次Fast Retransmit只會重傳一個packet。當多個packet丟失時，receiver端響應的全部ACK都指明瞭丟失的最小的packet，而不會指明其餘丟失的packet，這就致使只有丟失的最小的packet會被重傳，其餘丟失的packet會被隱藏，只有等到超時才能重傳。然而，重傳丟失的最小的packet以後，響應它的ACK其實是一個Partial Acknowledgement，它指明瞭第二個丟失的packet，能夠藉此重傳其餘丟失的packet，而無需等到超時的發生。這就是Partial Acknowledgement的做用。

對於sender如何處理Partial Acknowledgement，還有一些問題須要考慮。

首先是每當收到一個Partial ACK後，該重傳多少個packet？也即發送窗口的大小設置爲多少？

一種保守的策略是隻重傳一個packet，即Partial ACK中指明的packet。這種方式不會致使重傳receiver端已經緩存的packet，從而避免了False Fast Retransmit。

另外一種更快速的策略是Slow Start，每當收到一個Partial ACK，就增長髮送窗口，這樣能夠更快地覆蓋全部丟失的packet，但會致使不少已經被receiver端緩存的packet被重複發送。

進一步，若是採起第二種策略，該若是解決False Fast Retransmit的問題？實際上，咱們已經在Multiple Fast Retransmit中討論了這個問題。只需在收到同一個窗口裏的重複ACK以後，忽略掉便可。

 

參考文獻

[1] Braden, R. "RFC 1122." Requirements for Internet Hosts—Communication Layers (1989).

[2]  Postel, Jon. "RFC 793: Transmission control protocol, September 1981." Status: Standard (2003).

[3]  Jin, Cheng, David X. Wei, and Steven H. Low. "FAST TCP: motivation, architecture, algorithms, performance." INFOCOM 2004. Twenty-third AnnualJoint Conference of the IEEE Computer and Communications Societies. Vol. 4. IEEE, 2004.

[4]  Jin, Cheng, et al. "FAST TCP: From theory to experiments." Network, IEEE 19.1 (2005): 4-11.

[5]  Clark, David D. "RFC 813: Window and acknowledgement strategy in TCP, July 1982." Status: UNKNOWN.

[6]  Jacobson, Van. "Congestion avoidance and control." ACM SIGCOMM Computer Communication Review. Vol. 18. No. 4. ACM, 1988.

[7]  Hoe, Janey C. Start-up dynamics of TCP's congestion control and avoidance schemes. Diss. Massachusetts Institute of Technology, 1995.

[8]  Nagle, John. "RFC 896: Congestion control in IP/TCP internetworks." (January 1984) (1984).

[9]  Allman, Mark, Vern Paxson, and William Stevens. "RFC 2581: TCP congestion control." (1999).

[10]  Allman, Mark, and Vern Paxson. "RFC 5681: TCP congestion control." (2009).

[11]  Allman, Mark, and Vern Paxson. "RFC 6298: Computing TCP's Retransmission Timer." (2011).

[12]  Stevens, W. "RfC 2001: TCP Slow Start." Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms 1 (1997).

[13]  Floyd, S., and T. Henderson. "RFC 2582-The NewReno Modification to TCP’s Fast Recovery Algorithm, april 1999." Status: PROPOSED STANDARD: 115.

[14]  Floyd, S., and T. Henderson. "RFC 3782: The NewReno Modification to TCP's Fast Recovery Algorithm, IETF." (2004).

[15]  Gurtov, Andrei, and Sally Floyd. "Resolving Acknowledgment Ambiguity in non-SACK TCP." Next Generation Teletraffic and Wired/Wireless Advanced Networking (NEW2AN’04) (2004).

[16]  Floyd, Sally. TCP and successive fast retransmits. Technical report, October 1994. ftp://ftp. ee. lbl. gov/papers/fastretrans. ps, 1995.

[17]  Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, April 1996.