摘要：
首先說明更便宜的內存，高速鏈路、和更高速處理器會解決計算機網絡中的擁塞是假的；然后建議一個給予供給和需求的簡單擁塞定義和各種擁塞模式。使擁塞控制變得困難被討論并呈現且影響擁塞模式設計的架構決策。針對長期、中期和短期擁塞問題有不同的方法被討論。
介紹
擁塞控制是關于在需求超過或接近網絡資源容量的時候如何分配資源來得到一個可接受的性能級別。網絡資源包括鏈接貸款、緩沖區空間（內容）和中間節點處理器能力。盡管資源分配即使在低負載的時候也是很重要的，但隨著負載增加公平性問題和低overhead變得更重要，如果沒有適當的擁塞控制機制，在重負載下網絡吞吐量會減少的很嚴重。
關于擁塞控制的神話
擁塞發生在需求大于可用資源；因此就會說如果資源不再昂貴，擁塞問題就會被解決，這就是下面的幾個神話：
1. 擁塞由空間缺乏導致的，能隨著內存便宜而解決，因為有無限的內存。
2. 擁塞由低速鏈路造成的，隨著高速鏈路普及而被解決。
3. 擁塞由慢處理器導致的，隨著處理器速度的提高被解決。
實際上即使上面的這些說法，如果沒有適當的協議控制，上面的解決辦法不會解決擁塞反而導致更多擁塞因此降低性能。下面詳細解釋。
1. 大的緩沖區空間不能解決擁塞問題。一些研究發現無限緩沖區大小的交換機與有限緩沖區大小有同樣的擁塞。有限緩沖區交換機會丟包；但無限緩沖區的交換機會將數據緩沖的太長而導致應用層已經認為數據無效而重傳。總之，無限緩沖區實際上是有害的，主要因為其可能導致無效的使用網絡資源。
2. 高速鏈路的使用不會解決擁塞問題，反而增加了對擁塞控制的需求。因為所有的高速網絡都是和低速網絡連接的，而且隨著高速網絡的增加也不會導致低速網絡就能自動消失，這要求應用層設計協議能確保不會降低性能。
3. 高速處理器的引入也不能解決擁塞問題；因為和鏈路速率一樣這也會導致擁塞速率不匹配的問題。
4. 即使所有的網絡資源都是同等速度的，但仍然不能解決這個問題。這是因為不能保證網絡的任何地方都是合理配置而保證沒有不匹配現象。
因此擁塞是一個動態問題，不可能使用靜態的辦法來解決，這需要協議設計來保存擁塞下的網絡。高速網絡的擴大導致更多不平衡的網絡是擁塞的原因，而由緩沖區缺乏導致的丟包是一個癥狀但不是擁塞的原因。
擁塞問題的定義和解決方法
計算機網絡中，如果一段時間總資源的需求數量是小于可用資源數據量，就導致簡單的擁塞。計算機網絡中有很多資源，如：緩沖區、鏈路帶寬、處理器和服務器等。如果某個間隔緩沖區空間不夠，那么導致包丟失。簡單的說，如果短時間內期望進入鏈路的總流量比帶寬大，那么鏈路就是擁塞的。
擁塞模式分為兩大類：
1. 動態增加可用資源
2. 動態降低需求
資源創建模式
這個模式同通過動態的重新配置資源來決定，例如：
1. 在高使用率情況下增加撥號連接
2. 增加衛星鏈路的電力來增加帶寬
3. 考慮使用低負載時非優化的網絡來傳輸額外的數據
上面的所有模式，資源用戶都不需要被通知，他們甚至不知道網絡的擁塞，網絡自己負責接著擁塞問題。
需求減少模式
這通常要求資源的用戶能知道負載的狀況來調整流量。三種基本的模式：
1. 服務拒絕模式：擁塞時不允許建立新的會話。面向連接的計算機網絡使用相似的模式在中間節點上組織會話的建立。
2. 服務降級模式：這個要去所有的用戶（已經存在的或新加入的）減少負載。動態窗口就是這種方法的表現。
3. 計劃模式：這種模式要去用戶能計劃資源而保證小于容量。必須指出的是這種模式只是降級模式的特殊情況。
在無連接網絡中，會話的建立不需要中間節點的同意，因此服務拒絕模式通常無效，而使用服務降級模式和計劃模式。
反饋和控制
所有上面的模式通常都是先測量網絡的負載然后采取補救措施。第一部分叫做反饋，后面的叫做控制。反饋通常是從擁塞資源出到一個或多個控制點；在需求減少的模式，控制點一般是數據源，而創建型模式控制點可能是中間節點。
反饋模式
1. 反饋消息，擁塞資源點生成單獨的消息發送給控制點；源收到消息后降低負載或者增加負載如果沒有收到的話。代價是需要額外的負載。
2. 路由消息中的反饋:每個中間節點給鄰居發送負載信息
3. 注入更多的流量：背壓
4. 探測包：發送探測包來得到負載狀況
5. 順帶包中的反饋字段：不單獨產生反饋包，而是在反向數據中捎帶。
控制點位置
1. 傳輸層: 通訊流量是由終端系統產生的，因此最好的控制點在傳輸層。例如動態窗口機制。
2. 網絡接入層：就像告訴公路的入口出的紅綠燈，在網絡層增加訪問控制來限制擁塞時流量進入網絡。
3. 網絡層：在路由器和網關上增加對擁塞控制的處理。
4. 數據鏈路層：在每跳的數據鏈路層上使用流控機制。
為什么問題是困難的？
雖然有很多關于擁塞控制的提案，但這方面的研究至少進行了20多年，主要有兩方面的原因。首先對擁塞控制模式的需求很難讓其達到一個滿意的方案；其次有幾個網絡策略影響擁塞模式的設計。因此一個模式在一種結構下工作很好，但其他結構卻不一定。關于第二點的幾個問題下面來討論。
1. 模式必須是低開銷的：這要求控制不會增加額外的開銷，這就是為什么單獨反饋消息是不合理的原因。有些人建議只有在低負載的時候發送反饋，而缺少反饋默認表示高負載。
2. 模式必須是公平的：公平性在高負載的時候非常重要；重要的問題是如何合理分配資源。
3. 模式必須是反應靈敏的：網絡可用資源是變化的，隨著節點和鏈路的增加或減少，可用容量增加或減少；用戶開始或停止，需求也增加或降低。擁塞控制模式應該能和需求以及可用容量動態匹配。因此其在可用容量增加的時候要告訴用戶增加需求，反之告訴用戶減低需求。需求曲線應該和容量跟隨緊密。
4. 模式必須能在差的網絡環境下工作：
5. 模式必須是社會最優的：
影響擁塞控制模式的策略
擁塞控制的基本原則
擁塞控制是一個關于控制的問題，大多數擁塞控制模式都是由反饋機制和控制機制組成。在控制理論中，控制頻率應該等于反饋頻率。快則不穩定，慢則反應不夠。這個必須在設計控制模式的時候考慮怎么樣處理間隔。
另外一個可以從控制理論中學習的是，沒有任何模式可以解決持續時間小于反饋延遲的擁塞。傳輸層的動態窗口（或速率）模式，只有在擁塞持續幾個RTT才能控制；對于時間非常短的擁塞，數據鏈路和網絡層控制更合適（例如：優先級，緩沖區，輸入限制等等）。
如果是長期的擁塞，或者是會話級別的禍資源創建性模式應該被使用。如果擁塞持續時間不確定，安裝一個額外資源是最好解決問題的辦法，而很短的擁塞動態模式更好。
顯然擁塞長短不能提前檢測，因此最好的辦法是將不同層次的方法合并起來。
其他建議方法
基于時間溢出的擁塞控制
這種方法是基于這樣的想法：包丟失是擁塞的好的指示，而時間溢出表明網絡上的負載要減少。后來如果沒有丟失，那么負載慢慢的增加。其中之一CUTE（congestion using timeout at the End-to-end layer）窗口在時間溢出的時候降低到1，僅僅只能傳輸一個包。
擁塞避免的DECbit模式
正常的數據傳輸表現這樣的特點：在低負載時，吞吐量隨著負載增加而增加；如果網絡負載達到網絡容量是，吞吐量停止增加，這個點叫做knee，如果負載進一步增加，開始排隊，可能導致丟包，達到一定程度吞吐量突然下降，這個點叫做cliff。
擁塞避免模式就是讓網絡在knee和cliff之間運行。
簡單的擁塞避免方法是在網絡層頭加一個bit，參見：congestion avoidance in computer networks with a connectionless network layer.
擁塞避免基于延遲的模式