本備忘錄的狀態
本文檔講述了一種Internet社區的Internet最優通用的實例，它需要進一步進行討論和建議以得到改進。本備忘錄的發布不受任何限制。
版權聲明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.

摘要
本文檔的目的是解釋Internet中的擁塞控制的必要性和討論什么構成了正確的擁塞控制。目標之一是闡釋忽視運用合適的擁塞控制的危險，目標之二是討論IETF（InternetEngineeringTaskForce,Internet工程任務組）在新的擁塞控制協議標準化方面的作用。

1.介紹
本文檔很大程度上采納了早期RFCs文檔，在某些地方對早期的文檔[RFC2309,RFC2357]從整體上作了重新改寫.我們還借助了旨于端到端的擁塞控制需求[參見FF99]的參考資料.

2.擁塞控制的當前標準
端到端擁塞控制的IETF標準關注的方面包括集中在特定的協議（例如TCP協議[RFC2581],可靠的多點傳送協議[RFC2357])；終端節點和路由器之間的擁塞信息(例如明確的擁塞通告[RFC2481])交換的句法和語義；不同服務的服務質量的期望值。端到端的擁塞控制的作用也在一個關于“Internet中的隊列治理和避免擁塞的建議”[參見RFC2309]的RFC報告中進行了討論。RFC2309提出了在路由器中活躍的隊列治理機制的配置和對路由器機制設計的延續來處理對擁塞通告無回應的流。我們能夠輕松地從RFC2309中借用一些端到端的擁塞控制的概括性的討論。
與上面提到的RFCs資料相比，本文檔對擁塞控制的原理進行更一般性的討論。Internet成功的一個要害因素就是TCP協議的避免擁塞機制。當前TCP協議在Internet中仍然是占主導地位的傳輸協議，但它不是適用于任何地方，有越來越多的應用由于某種原因沒有選擇使用TCP協議。通信不僅包括多點傳送通信，而且包括單點傳送通信，諸如不需要可靠性的流化的多媒體，以及包括象DNS(DomainNameServer域名服務器)或路由信息的通信，它們帶有被認為對網絡運行至關重要的短信息。許多通信并不使用任何形式的預留帶寬或端到端擁塞控制。為了保持最優傳輸量，端到端的擁塞控制的繼續使用對保持Internet的穩定至關重要。
本文檔也討論IETF在新的擁塞控制協議標準化中的一般作用。對于區別性服務和集成性服務的擁塞控制的討論在本文檔中不涉及。集成性或區別性服務能夠保證端到端的網絡帶寬，所以不需要端到端的擁塞控制機制。


3.端到端擁塞控制的發展

3.1防止網絡因擁塞而崩潰
Internet協議體系是基于使用ip協議實現無連接的端到端的包交換服務。無連接設計的優勢靈活和健壯已經被充分的證實了。然而這些優勢并不是沒有代價的：在高負載情況下提供優質服務需要更仔細的設計。實際上，不重視動態包交換會導致嚴重的服務降級或“Internet熔化“。這個現象首先被觀察到是在1980年中葉網絡的早期發展階段[參見RFC896]，在技術上稱之為”擁塞崩潰“。TCP的最初說明[參見RFC793]包括基于窗口的流控制，它作為接受方治理發送方發送數據的方式。流控制被用來防止接受方可用的數據緩沖空間的溢出。[RFC793]報告指出由于錯誤或網絡擁塞，響應擁塞的流控制窗口不進行動態的調整，數據段可能丟失。
VanJacobson提出了對“Internet熔化”的初始修補。1986年初，Jacobson開發了現在在TCP應用[參見Jacobson88,RFC2581]中的避免擁塞機制。運行在主機中的這些機制使得TCP連接在擁塞時回退，象我們所說的TCP流對網絡中的擁塞信號進行響應（例如“丟棄包”）。正是這些TCP避免擁塞算法防止了今天網絡的擁塞崩潰。
然而，故事還沒有結束。自從1988年以來對動態網絡進行了大量的研究工作，Internet也迅猛發展。TCP協議避免擁塞的機制[參見RFC2581],雖然十分必要和功能強大，但是要在所有情況下提供優質服務還顯得不足。另外，在新的擁塞控制機制[參見RFC2357]的發展中，基于路由器的機制正在終端節點的避免擁塞機制的應用中發展。
由于流不使用端到端的擁塞控制，需要提出來的一個重要問題，就是未來網絡擁塞崩潰的
潛力問題。1984年，RFC896建議網關應該監測和壓制主機的錯誤行為：對錯誤響應ICMP源結束信息，而這個信息應該被認為是一個網關斷開與主機連接的行為。檢測這些錯誤不是毫無價值的，對未來的研究是一個很有價值的領域。當前的論文仍然建議正在應用的路由器檢測和處罰流對于端到端的擁塞控制[參見FF99]是可以接受的。

3.2公平性
在關注擁塞崩潰之外，我們可以再看看盡最大努力通信的公平性。因為在擁塞時TCP回退，在同樣狀況的流之間帶寬合理公正的共享，大量的TCP連接能夠共享一個單獨的擁塞連接。流之間帶寬公正的共享依靠所有的流都運行兼容的擁塞控制算法。對于TCP協議，這意味著擁塞控制算法構成了當前TCP的說明[參見RFC793,RFC1122,RFC2581].
在相互競爭的流之間的公平問題變得越來越重要由于下面幾個原因：第一，由于使用窗口縮放[參見RFC1323]單個的TCPs即使在高傳輸延遲的通路上都能使用高帶寬。第二，隨著網絡的發展，網絡用戶希望高帶寬和低延遲的通信，而不是在后臺的一個大文件的傳輸。不使用TCP的盡最大努力通信的發展強調擁塞時通信競爭時的公平性。
Internet的普及帶來了TCP應用的增長，其中有一些因為缺少工具[參見RFC2525]而不能正確的應用TCP避免擁塞機制。其它一些可能特意應用避免擁塞算法，它們在帶寬的使用方面比TCP應用更有利。這使得開發商能夠提出一個“快速TCP”。這個應用的邏輯結果將是TCP應用的盤旋上升或者傳輸協議的增加，回到沒有有效的避免擁塞和網絡持續的擁塞的狀況。
有一個聞名的方法，不改變傳輸協議，改變粒度的層次而達到更有效的性能。如同過去對一些WEB瀏覽器的做法，對同一個地方開放多個連接。這樣，有效傳輸協議不是盤旋上升，相反，帶來的是有效的WEB瀏覽器的盤旋上升或者有效的應用的增加。
這使得合適的“流”的粒度的問題的出現，我們定義‘流’為對于兼顧公平和擁塞控制的應用比較適合的粒度的層次。RFC2309的有一些自然的回答：（1）一個TCP或UDP連接（源地址/端口，目的地址/端口）；（2）一個源/目的主機對；（3）一個給定的源主機或一個給定的目的主機。我們認為源/目的主機對提供了在許多情況下最合適的粒度。擁塞控制的流的粒度，至少部分上，是需要被更廣泛的IETF社團接受的政策問題。
再回到RFC2309，我們使用術語“TCP兼容”描述在擁塞情況下行動的流如同產生于確認TCP的流。一個TCP兼容的流響應擁塞通告，并且能夠在可比的條件下（丟棄率，RTT,MTU等），穩定地使用和確認的TCP相同的帶寬。
很方便的把流分為三類：（1）TCP兼容流，（2）無響應流，例如當擁塞發生時不減慢的流，（3）響應但不是TCP兼容的流。后面兩類包含對網絡性能極其重要的更有效的流，我們下面將要討論。
除了穩定狀態的公平性，初始的慢啟動的公平性也是一個關注點，還有一個很有效的慢啟動過程的流對其它流的短暫影響，慢啟動的性能對于許多短期只有少量數據傳輸的流非凡重要。

3．3關于吞吐量，延遲，丟失的性能優化
除了防止擁塞崩潰和關注公平性，使用端到端擁塞控制的流的第三個理由是它自身的吞吐量，延遲和丟失的性能優化。在某些情況下，例如在高統計的多路技術的環境下，一個流的延遲和丟失大部分獨立于自身的發送速率。然而，在低統計多路技術或單個流調度的環境下，一個流的延遲和丟失部分上與流自身的發送速率有關。因此，一個流能使用端到端擁塞控制來限制自身的包的延遲和丟失。然而我們注重到，在象當前的盡最大努力通信的網絡環境下，關于擁塞崩潰和流之間競爭的公平性的關注限制了對流來說有用的擁塞控制行為的范圍。

4．標準處理的作用
傳輸協議的標準化不僅包括能夠影響互操作性（例如終節點的信息交換）的協議的標準化，而且包括對性能（例如在TCP中，由于包的丟失而減少擁塞窗口）至關重要的機制的標準化。同時，特定應用的細節和傳輸協議的其它方面，不影響互操作，也不影響性能，就不需要標準化。TCP不需要標準化的區域包括快速重傳[參見RFC2582]之后TCP的快速修復過程的細節。附錄使用TCP的實例來更具體的討論在擁塞控制發展中的標準進程的作用。

4.1新的傳輸協議的發展
除了關注擁塞崩潰的危險，新的傳輸協議的標準化進程注重在競爭協議中避免擁塞控制的‘軍備競賽’。舉個例子，在RFC2357中，TSV區域指揮者和高級職員勾劃出了關于可靠的多路傳輸協議的網絡草案的RFC資料的準則。從[RFC2357]看到：“一個IETF的非凡關注是在網絡擁塞時可靠多路的通信對其它通信的影響，尤其是在TCP通信的競爭中可靠多路通信的影響...IETF面臨的挑戰是鼓勵可靠多路技術的研究和應用，使得可靠多路技術的應用需求能盡可能快的被滿足，同時保護網絡免于由于不正確的可靠多路機制的廣泛應用帶來的擁塞災難或崩潰。“
關于新的可靠多路傳輸協議的RFC資料的技術準則包括：“是否有擁塞控制機制？它是如何執行的？它何時無效？注重網絡中比TCP更有效的擁塞控制機制面臨并不威脅網絡穩定的許多負擔。
期望在通信競爭中的新的傳輸協議的效果將不僅應用于可靠的多路協議，而且同樣應用于不可靠的單路、可靠的單路和不可靠的多路通信量中。這是很合理的。

4.2影響擁塞控制的應用層問題
一個瀏覽器對相同的目的地址打開多個連接的問題可以在RFC2626中找到，RFC2616在8.1.4節中說明“使用不間斷的連接的客戶機應該限制它們同時保持與給定的服務器連接的數量。單用戶客戶機不應該保持多于2個與任何服務器或代理的連接。”

4.3標準化進程的新發展
IETF能夠影響擁塞控制的進展，其最明顯的發展集成和區分服務[參見RFC2212,RFC2475]和明確的擁塞通告[參見RFC2481]。然而，其它戲劇性的發展同樣可能影響擁塞控制。
已經在努力構建終節點擁塞治理[參見BS00]來使得一個發送方的多個并發流到達相同的接受方來共享擁塞控制狀態。通過答應對同一個目的多個連接在端到端的擁塞控制過程中作為一個流，擁塞治理者能夠答應單個慢啟動的連接利用先前端到端路徑的擁塞狀態信息。進一步，擁塞治理者能夠去除在相同源/目的對中打開的多個流的擁塞控制危險，能夠用來答應一個瀏覽器同時開放對同一個目的的多個連接。

5.擁塞崩潰的描述
這部分討論非傳遞的包的擁塞崩潰的某些細節，并且說明非響應流如何有助于網絡擁塞崩潰。這部分采用了[FF99]的資料。
一般說，擁塞崩潰發生在網絡負載的增加導致網絡效率的降低的時候。第三部分已經討論過，擁塞崩潰最先在1980年中葉[RFC896]提出，主要由于TCP連接的不必要的重傳那些正在傳送或已經被接收方接收了的數據包。我們稱不必要的重傳數據包而引起的擁塞崩潰為典型的擁塞崩潰。典型的擁塞崩潰是導致吞吐量只是正常情況下的一小部分的穩定狀況[參見RFC896].典型的擁塞崩潰的問題已經通過定時器和在現代TCP[參見Jacobson88]的應用中的擁塞控制機制的改進基本得到解決。
第二種形式潛在的擁塞崩潰由于非傳遞的數據包而發生。當網絡傳送的數據包在到達最終目的地之前被丟棄而導致帶寬被浪費的時候就會出現由于非傳遞的數據包而發生擁塞崩潰。由于擁塞連接的部分帶寬用來可再生性的工作，不同的設定可能有不同程度的擁塞崩潰。非傳遞數據包的擁塞崩潰的危險基本上是由于開路循環應用的增加的配置沒有使用端到端擁塞控制。甚至更多的破壞將是盡最大努力通信的應用通過增加發送率來增加包的丟棄率（例如自動使用FEC增加的層次）。
表1給出了在數據包未到達目的地卻很少帶寬浪費情況下非傳送數據包的擁塞崩潰的在某個設定下的結果。這個模擬設定在三個TCP流和一個UDP流在一個1.5Mbps的鏈路上競爭。所有節點的存取連接是10Mbps而UDP流的接收方的存取連接是128Kbps，只有共享帶寬的9%。當UDP源速率超過128Kbps，大多數UDP包將在最終連接的輸出端口丟棄。
到達UDPTCP總計
比率正常輸出正常輸出正常輸出
---------------------------------------------------------
0.70.798.599.2
1.81.797.399.1
2.62.696.098.6
5.35.292.797.9
8.88.487.195.5
10.58.484.893.2（續）
（續）
13.18.481.489.8
17.58.477.385.7
26.38.464.572.8
52.68.438.146.4
58.48.432.841.2
65.78.428.536.8
75.18.419.728.1
87.68.411.319.7
105.28.43.411.8
131.58.42.410.7

表1三個TCP流和一個UDP流的模擬
表1顯示在擁塞的1，5Mbps鏈路上發送方的UDP的到達率，UDP的正常輸出（定義為傳輸到接收方的帶寬），TCP正常輸出（定義為傳輸到TCP接收方的帶寬），和總計正常輸出。每個比率作為擁塞鏈路的帶寬的一部分。隨著UDP源比率的增加，TCP的正常輸出直線下降，UDP的正常輸出幾乎保持不變。因此，隨著UDP數據流增加它的負載，只是影響TCP和總計的正常輸出。在擁塞鏈路上，UDP流極其浪費本應屬于TCP流的帶寬，從整體上使得網絡的正常輸出降低到擁塞鏈路的帶寬的一小部分。
表1的模擬闡釋了不公平性和擁塞崩潰。[FF99]中談到兼容擁塞控制不是提供公平性的唯一方法，在擁塞的路由器中單流調度也是保證公平性的可選機制。然而，[FF99]談到單流調度不能防止擁塞崩潰。
消除非傳遞數據包的擁塞崩潰的危險有兩個可選的方法。第一個方法是終端節點使用有效的端到端的擁塞控制。更為非凡的是，需要一個流避免在路徑的第一個擁塞連接的下端出現嚴重的丟失現象。（這里，我們將考慮一個擁塞鏈路，鏈路上的任何流正在被鏈路上其它通信使用的帶寬。）假定一個終端節點不能區別一個擁塞鏈路的路徑和一個多個擁塞鏈路的路徑，對于一個流避免在路徑的擁塞連接的下端出現嚴重的丟失現象，最可靠的方法是使用端到端的擁塞控制，減少發送方現在丟失的發送比率。
第二個方法是保證網絡中擁塞鏈路上的數據包將被傳送到接收方[參見RFC2212,RFC2475]。我們注重到在第一個端到端的擁塞控制方法和第二個端到端的帶寬保證方法之間選擇不是一個或者這個或者那個的問題，一些通信使用端到端的擁塞控制和其余通信使用端到端的帶寬保證能夠防止擁塞崩潰。

6.端到端的擁塞控制的構成
本文檔已經討論了擁塞控制新的構成中擁塞崩潰和TCP公平性。然而，這不意味著擁塞崩潰和TCP的公平性對所有的在基于TCP通過折半減少發送速率來響應每個包的丟失的“加法增加乘法遞減算法”的情況下盡最大努力的通信配置擁塞控制都有必要。這部分單獨討論擁塞崩潰和TCP公平性兩個方面的關聯。

6.1避免擁塞崩潰的端到端的擁塞控制
非傳遞數據包的擁塞崩潰的避免需要流避免在鏈路的下端設定高的發送率，多擁塞鏈路和持續的高包丟棄率。因為引起擁塞崩潰的由浪費帶寬的數據包組成的非傳遞數據包只在鏈路下端被丟棄，所以這種擁塞崩潰不可能在每個流只在一個擁塞連接上通過或者只有一小部分數據包在第一個擁塞鏈路的下端被丟棄的環境下出現。因此，任何形式的擁塞控制成功地在現存的對于避免非傳遞數據包的擁塞崩潰應該有足夠的包丟棄率的情況下避免高的發送速率。
我們將注重到附加的對IP體系結構的明確擁塞通告不會去除盡最大可能的通信的擁塞崩潰危險。明確擁塞通告答應路由器在包的頭部設置一位作為終節點的擁塞的標記，不強制性的依靠于以包的丟棄來標記擁塞。然而，通過明確擁塞通告，包的標記將在適中的擁塞中取代包的丟棄。非凡情況下，當擁塞非常嚴重，并且路由器的緩存溢出時路由器只有丟棄達到的包。

6.2為了TCP公平性的端到端的擁塞控制
在[RFC2357]中，TCP的公平性對可行的在盡可能傳送的通信中的端到端的擁塞控制機制的范圍有重要但不削弱的局限。在所有擁塞鏈路上的單流調度環境將使流彼此孤立，并且消除擁塞控制機制成為TCP兼容的需要。在區別性的服務的環境下，流標記為某一特定服務類別，答應在擁塞控制不需要成為TCP兼容的通信中一個完整的服務類別的出現。
類似的，一個有價格限制的環境，或者一個有價格范例的不同的服務類別能夠替代對TCP的公平性的關注。然而，對于當前的網絡環境，其它的盡最大努力傳輸的通信能夠在先進先出的隊列中與TCP通信相競爭，TCP由于沒有公平性會導致在高擁塞的情況下一個流會‘餓死’另外一個流，這個問題已經在表1中闡述了。
然而TCP兼容擁塞控制過程的列表不局限于使用與TCP相同的增加/減少參數的“加法式增加/乘法式減少“算法。其它的TCP兼容擁塞控制過程包括基于速率的“加法式增加/乘法式減少“變量；有不同但卻保證同樣穩定狀態的增加/減少參數的“加法式增加/乘法式減少“算法；基于平衡的擁塞控制，發送方通過調整發送速率來響應長期的包丟失的信息；接收方從分層多路技術組提交和不提交的分層多路技術；還有可能我們沒有考慮的其它形式。
7.致謝
本文檔的許多資料直接取自RFC關于端到端擁塞控制。這里試圖對這些年來許多人討論出來的思想作個總結。尤其感謝“終端到終端研究"工作組，“可靠多路研究“工作組和傳輸領域指導委員會的成員。本文檔也受益于傳輸領域工作組的討論和反饋。非凡感謝MarkAllman對本文檔的早期版本的意見。

8.參考資料
[BS00]BalakrishnanH.andS.Seshan,"擁塞治理",
WorkinPRogress.

[DMKM00]Dawkins,S.,Montenegro,G.,Kojo,M.andV.Magret,
"慢速鏈路的端到端的性能關聯",
WorkinProgress.

[FF99]Floyd,S.andK.Fall,"在網絡中促進使用端到端的擁塞控制",IEEE/ACM
ransactionsonNetworking,August1999.URL
http://www.aciri.org/floyd/end2end-paper.Html

[HPF00]Handley,M.,Padhye,J.andS.Floyd,"TCP擁塞的窗口有效性",RFC2861,June2000.

[Jacobson88]V.Jacobson,擁塞的避免和控制,ACMSIGCOMM'88,August1988.

[RFC793]Postel,J.,"傳輸控制協議",STD7,RFC793,September1981.

[RFC896]Nagle,J.,"在IP/TCP中的擁塞控制",RFC896,January1984.

[RFC1122]Braden,R.,Ed.,"網絡主機的需求-通信層",STD3,RFC1122,October1989.

[RFC1323]Jacobson,V.,Braden,R.andD.Borman,"TCP高性能的擴展",RFC1323,May1992.

[RFC2119]Bradner,S.,"在RFCs中標志需求層次的要害字",BCP14,RFC2119,March1997.

[RFC2212]Shenker,S.,Partridge,C.andR.Guerin,"保證服務質量的說明",RFC2212,September1997.

[RFC2309]Braden,R.,Clark,D.,Crowcroft,J.,Davie,B.,
Deering,S.,Estrin,D.,Floyd,S.,Jacobson,V.,
Minshall,G.,Partridge,C.,Peterson,L.,Ramakrishnan,
K.K.,Shenker,S.,Wroclawski,J.,andL.Zhang,
"網絡中隊列治理和避免擁塞的建議",RFC2309,April1998.

[RFC2357]Mankin,A.,Romanow,A.,Bradner,S.andV.Paxson,
"評估可靠的多路傳輸和應用協議的IETF準則",RFC2357,June
1998.

[RFC2414]Allman,M.,Floyd,S.andC.Partridge,"增加中的TCP的初始化窗口",RFC2414,September1998.

[RFC2475]Blake,S.,Black,D.,Carlson,M.,Davies,E.,Wang,Z.
andW.Weiss,"區分服務的體系結構",RFC2475,December1998.

[RFC2481]RamakrishnanK.andS.Floyd,"添加明確擁塞通告到IP的建議",RFC2481,
January1999.


[RFC2525]Paxson,V.,Allman,M.,Dawson,S.,Fenner,W.,Griner,
J.,Heavens,I.,Lahey,K.,Semke,J.andB.Volz,
"有名的TCP應用問題",RFC2525,March
1999.

[RFC2581]Allman,M.,Paxson,V.andW.Stevens,"TCP擁塞控制",RFC2581,April1999.

[RFC2582]Floyd,S.andT.Henderson,"TCP的快速修復算法的新的修改",RFC2582,April1999.

[RFC2616]Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.,
Masinter,L.,Leach,P.andT.Berners-Lee,"超文本傳輸協議--HTTP/1.1",RFC2616,June1999.

[SCWA99]S.Savage,N.Cardwell,D.Wetherall,andT.Anderson,
一個錯誤行動的接收方的TCP擁塞控制,ACM
ComputerCommunicationsReview,October1999.

[TCPB98]HariBalakrishnan,VenkataN.Padmanabhan,Srinivasan
Seshan,MarkStemm,andRandyH.Katz,一個繁忙的網絡服務器的TCP行為:分析和改進,IEEEInfocom,March1998.Availablefrom:
"http://www.cs.berkeley.edu/~hari/papers/infocom98.ps.gz".

[TCPF98]DongLinandH.T.Kung,TCP快速修復策略:分析和改進,IEEEInfocom,March1998.Availablefrom:
"http://www.eecs.harvard.edu/networking/papers/infocom-tcp-final-198.pdf".

9.TCP要說明的問題
在這部分我們將討論TCP擁塞的非凡情況，來闡釋擁塞控制原理的實現，包括加入到傳輸協議產品的一些細節。

9.1慢啟動
TCP發送方不能通過一次性發送一個很大的數據（例如接收方建議的窗口）來打開一個新的連接。TCP發送方對擁塞窗口的初始值有限制。在慢啟動過程中TCP發送方能通過在一個循環周期把兩個因素并為一個來提高發送速率。當監測到擁塞或發送方的擁塞窗口比慢啟動的臨界值大的時候慢啟動就結束了。
全局擁塞控制的潛在影響的問題已經被標準化進程鮮明的提出來了，其中包括初始窗口值的增加[參見RFC2414,RFC2581]。
標準化進程提出的問題一般被認為不需要標準化，包括基于速率的步進方式的使用與否，在擁塞窗口到達臨界值之前提早結束慢啟動的機制。這個機制使得慢啟動或多或少比標準的TCP顯得保守。
9.2加法式的增加，乘法式的降低
沒有擁塞時TCP發送方通過每個循環周期加一個包來增加擁塞窗口。出現擁塞現象時，TCP發送方折半減少擁塞窗口。（更準確地說，新的擁塞窗口是擁塞窗口最小值和接收方建議的窗口的一半）。
全局擁塞控制的潛在影響的問題已經被標準化進程鮮明的提出來了，其中包括對‘純響應‘的流的返回進行擁塞控制的額外的建議。
一個標準化進程沒有提出一般被認為不需要標準化的問題，包括擁塞窗口的改變應用在字節數的上界繼續在管道中的情況下，而不是應用在確認后滑動窗口啟動的情況下。（很明顯，接收方推薦的窗口應用在確認后滑動窗口啟動。因為從確認方接收的包被放置在TCP接收方的緩存中，還沒有傳給應用程序。然而，擁塞窗口隨管道中的包的數量而變化，不需要包括被TCP接收方在無序方式下接收的包。）

9.3重傳定時器
TCP發送方設置一個重傳定時器來告知網絡中一個包已被丟棄。當重傳定時器到時了，發送方得知已經有包丟失，把當前的窗口設為原先的一半，開始慢啟動，重傳丟失的包。假如重傳定時器因為重傳的包沒有被接收到的確認而到時，重傳定時器也‘回退‘，把下次重傳的時間間隔加倍。
標準化進程很有可能鮮明提出這么一個問題，它潛在的影響全局的擁塞控制，它包括當發送方沒有受到確認而事實上并沒有包被丟棄時，如何使得重傳定時器增加重傳時間間隔的修正機制。因為重傳定時器到時會導致增加數據包在擁塞鏈路上不必要的傳送，所以網絡標準化進程對此非常關注。

9.4快速重傳和快速修復
當看到三個重復的確認，TCP發送方知道有包丟失。接著TCP發送方把臨界值設為當前窗口的一半，減少擁塞窗口到先前的一半，并重傳丟失的包。
標準化進程很有可能鮮明提出這么一個問題，它潛在的影響全局的擁塞控制，它包括當只有一兩個重復確認就告知有包丟失的建議。假如設計不好的話，這個建議可能導致增加包在擁塞路徑上不必要的傳輸。
一個標準化進程沒有提出，一般被認為不需要標準化的問題，是建議假如擁塞窗口答應的話，發送一個‘新‘的或丟失的包來響應重復確認。舉個例子，假如只有一個重復確認，沒有更多的確認到達，則發送一個新的包響應，來保持‘響應時鐘‘運轉。這個建議是一個有益的改變，它不涉及到互操作，也不影響全局擁塞控制，因此不需要IETF標準化進程的介入，就被開發商們所應用。（這個問題事實上已經在[DMKM00]中提過，[DMKM00]建議“研究人員試圖收到重復確認后在網絡中插入新的通信，[TCPB98]和[TCPF98]都講述過。）

9.5TCP擁塞控制的其它方面
TCP擁塞控制的其它方面在上面的章節中都沒有提到，其中包括空閑或有限制的應用的時期的TCP修復[參見HPF00].

10.安全考慮
本文檔已經討論了擁塞控制的危險和擁塞控制的缺乏。章節3.2討論了假如相互競爭的流不使用兼容的擁塞控制機制而潛在的不公平性，章節5考慮了假如流不使用端到端的擁塞控制而出現擁塞崩潰的危險。
因為本文檔沒有提出任何非凡的擁塞控制機制，所以也不需要提供擁塞控制相應的安全措施。然而，我們將注重針對擁塞控制的安全性考慮，IETF文檔還有很廣闊的范圍。例如，單獨擁塞控制機制試圖解決單獨的終節點之間的端到端擁塞控制很有活力[參見SCWA99]。要非凡關注多路擁塞控制，因為通信的分布很難把握，并且單個接收方出現錯誤后報告擁塞的幾率很高。
RFC2309也討論了網絡中無響應的流的潛在威脅，就是流在出現擁塞時不減少發送速率，并且描述了網絡需要用來處理流對擁塞通告無響應的機制。我們將注重到這些領域在研究，工程，方法，配置的需要。因為網絡有數量眾多的流，一些單個流的擁塞控制的危險有一定的限度。相反，分散的危險來自許多終端節點的端到端的擁塞控制的廣泛的配置。