用戶每200ms向TCP輸出一個新的字符，并且這個連接要經(jīng)過以太網(wǎng)，此以太網(wǎng)
的往返時間包括了50ms的軟件處理時間。如果沒有任何機(jī)制來防止短數(shù)據(jù)報的
擁塞，與 每個字符對應(yīng)的數(shù)據(jù)包將被送出，響應(yīng)是最佳的。開銷將是4000%，
但在以太網(wǎng)上可以接受的。而典型的定時器方案，每秒兩個數(shù)據(jù)包的限制，將使
兩個或三個字符在一個數(shù)據(jù)包中被傳送。響應(yīng)性能將降低，即使在高帶寬的以太
網(wǎng)上也是沒有用的。開銷降到1500%，但在以太網(wǎng)上這是個不太好的替換方案。
而我們的方案，用戶所敲擊的每個字符將找到一條空閑的TCP連接，字符將立刻
被傳送，正如在無控制的情況一樣。用戶將不會感覺到延遲。這樣，我們的方案
既可作為無控制的方案運(yùn)行又可以提供比定時器方案更好的響應(yīng)。

    第二個測試的情況是同樣的Telnet測試，但是測試是在有5秒往返時間的
長距離連接上。如果沒有任何機(jī)制防止短數(shù)據(jù)包擁塞，25個數(shù)據(jù)包將在5秒內(nèi)
被送出。這兒開銷是4000% 。用典型的定時器方案且同樣是每秒2個數(shù)據(jù)包的限
制，將仍有10 個數(shù)據(jù)包不能處理并引起擁塞。當(dāng)然往返時間將不會因傳送很多
的數(shù)據(jù)包而得到改善；通常，它會因數(shù)據(jù)包競爭行時間而變得更糟。這時開銷降
到了1500%。然而，用我們的方案，來自用戶的第一個字符將發(fā)現(xiàn)空閑的TCP連
接且立即傳送。接下來的24個字符，以200ms的間隔從用戶端到來，將等待遠(yuǎn)
端主機(jī)來的報文。當(dāng)一個對第一個數(shù)據(jù)報的確認(rèn)ACK在5秒末到來時，這24個
等待的字符封裝到數(shù)據(jù)包中被傳送出去。這樣，我們的方案導(dǎo)致了在沒有損失響
應(yīng)時間的情況下開銷減少到320%。用我們的方案響應(yīng)時間通常因為數(shù)據(jù)包開銷
減少而得到改善。擁塞將減少且往返時間延遲將顯著下降。在這個情況中，我們
的方案明顯優(yōu)于其他方法。

    我們對所有的TCP連接使用我們的方案，不僅僅是Telnet連接。讓我們看
看用我們的方法為文件傳輸建立數(shù)據(jù)連接時將會發(fā)生什么。我們將再一次考慮到
這兩個極端的情況。

    象前面所提的一樣，我們首先考慮以太網(wǎng)的情況。用戶現(xiàn)在以512字節(jié)塊的
大小按TCP所能接受的速度向TCP寫數(shù)據(jù)。用戶第一次向TCP寫的數(shù)據(jù)啟動傳輸；
我們的第一個數(shù)據(jù)報的大小將是512+40字節(jié)或552字節(jié)。用戶的第二次寫數(shù)據(jù)
不會引起傳送但會使這個塊被緩沖。設(shè)想用戶在第一個確認(rèn)到來之前填充TCP的
輸出緩沖區(qū)。然后，當(dāng)ACK到來時，滿足窗口大小的所有排隊數(shù)據(jù)將被送出，從
那時起，窗口保持為滿，每個ACK開始一個傳送循環(huán)，等待的數(shù)據(jù)被送出。這樣,
在一個往返時間初始周期以后，只有一個塊要傳送時，我們的方案解決了最大吞
吐量的情況。由于啟動延遲在以太網(wǎng)上只有50ms，因此，啟動的瞬時延遲是無
關(guān)重要的。三種方案都對這種情況提供了等價的性能。

    最后，讓我們看看在有5秒往返時間的連接上的文件傳輸。在第一個確認(rèn)回
來之前只有一個數(shù)據(jù)包被發(fā)送；窗口將被填充并填滿。因為往返時間是5秒，只
有512字節(jié)的數(shù)據(jù)在第一個5秒被發(fā)送。假定有一個2k的窗口，一旦第一個確
認(rèn)來到，2K的數(shù)據(jù)將被發(fā)送，之后，將保持每5秒2K的穩(wěn)定速率。只有在這種
情況下我們的方案才比定時器方案差，差別只在啟動瞬時。穩(wěn)定狀態(tài)下的吞吐量
是相同的。樸素的方案和定時器方案在上面所提的情況下都要花250秒來傳輸
100K字節(jié)的文件，我們的方案將花254秒，1.6%的差別。
     			
帶ICMP的擁塞控制

    解決了短數(shù)據(jù)報問題以及在我們自己網(wǎng)絡(luò)中的極端的短數(shù)據(jù)報擁塞問題，我
們把注意力轉(zhuǎn)向通常的擁塞控制。既然我們的網(wǎng)絡(luò)是沒有點對點流量控制的純數(shù)
據(jù)報網(wǎng)絡(luò)，對我們而言，在IP標(biāo)準(zhǔn)下可獲得的唯一機(jī)制是ICMP源抑制報文。在
精心的控制下，我們發(fā)現(xiàn)這足以防止嚴(yán)重的擁塞問題。我們發(fā)現(xiàn)留心主機(jī)或交換
節(jié)點對源抑制報文的行為是必要的。
何時發(fā)ICMP源抑制報文    
    當(dāng)前的ICMP標(biāo)準(zhǔn) 規(guī)定，無論何時包丟失，ICMP源抑制報文就應(yīng)該被發(fā)送，
此外，當(dāng)網(wǎng)關(guān)發(fā)現(xiàn)自己資源不足時也應(yīng)發(fā)送源抑制報文。這里有些二義性，但很
明顯,沒有送ICMP報文而丟棄數(shù)據(jù)包違背了的標(biāo)準(zhǔn)。

    我們的基本假設(shè)是，在網(wǎng)絡(luò)正常運(yùn)行時數(shù)據(jù)包不應(yīng)該被丟棄。因此我們想在
發(fā)送方使交換節(jié)點和網(wǎng)關(guān)超負(fù)荷之前抑制發(fā)送方重發(fā)。我們的交換節(jié)點在緩沖區(qū)
耗盡之前能很好地發(fā)送ICMP源抑制報文；直到它們在發(fā)送ICMP源抑制報文之前
必須丟棄報文時才等待。正如我們在短數(shù)據(jù)報問題的分析中演示的，僅僅提供大
量的緩沖是不能解決問題的。通常，我們的經(jīng)驗是，當(dāng)用了緩沖區(qū)的一半左右，
源抑制報文就應(yīng)該發(fā)送了；這不是基于廣泛的實驗，但似乎是個合理的技術(shù)決定。
可以討論一個自適應(yīng)方案，這個方案可以調(diào)整基于近期經(jīng)驗的抑制產(chǎn)生邊界；到
目前為止我們還沒有發(fā)現(xiàn)這個必要性。

    還有其他的網(wǎng)關(guān)實現(xiàn)算法，僅在不只一個包被丟棄之后才產(chǎn)生源抑制報文。
我們認(rèn)為這種方法是不好的，因為任何基于包丟棄的擁塞控制系統(tǒng)浪費(fèi)帶寬，且
可能在負(fù)荷重時容易受擁塞崩潰的影響。我們理解的是，被動地產(chǎn)生源抑制報文
的方案基于這樣的擔(dān)心，害怕確認(rèn)傳輸將被抑制以及這將導(dǎo)致連接失敗。正如下
面將要展示的，在主機(jī)實現(xiàn)中的恰當(dāng)?shù)脑匆种瓶刂婆懦诉@種可能性。


在收到ICMP源抑制報文時做什么
  
     當(dāng)ICMP收到一個源抑制報文時我們通知TCP或者該層上的任意其他協(xié)議。
我們的TCP具體實現(xiàn)的基本行為是減少與源抑制報文中所指出的主機(jī)的連接上
未處理的數(shù)據(jù)的數(shù)量。使發(fā)送端TCP的反應(yīng)就象遠(yuǎn)端主機(jī)窗口大小已經(jīng)減少,從
而實施這個控制。我們的第一個實現(xiàn)過于簡單化但卻有效；一旦收到源抑制報文，
只要窗口不為空，我們的TCP就認(rèn)為窗口大小為0并做相應(yīng)處理。這個行為將持
續(xù)到收到一定數(shù)量（現(xiàn)在是10）的ACK為止，到那時，TCP回到正常的運(yùn)行狀態(tài)
 。Linkabit公司的David Mills 在他的DCN系統(tǒng)中實現(xiàn)了一個類似的但更詳細(xì)
的對未處理的數(shù)據(jù)包的節(jié)流控制。這個附加的復(fù)雜性好象提供了一個獲得吞吐量
的方式，但我們沒有做過正式的測試。兩個實現(xiàn)都有效地防止了交換節(jié)點的擁塞
崩潰。

    這樣，源抑制方法有效地限制了到有限數(shù)量（可能為1）的未處理報文的連
接。因此，通信能繼續(xù)但是速率降低，那正是期望的效果。

    這個方案有個重要的性質(zhì)，源抑制不能禁止確認(rèn)和重傳的發(fā)送。源抑制在
IP層上的完全實現(xiàn)通常是不成功的，因為IP缺少足夠的信息來正確地控制一個
連接的流量。抑制確認(rèn)信息往往產(chǎn)生重傳和不必要的傳輸。抑制重傳可能因重傳
超時而使連接丟失。我們的方案將在服務(wù)器超負(fù)荷下保持活動連接但減少每個連
接的帶寬。

    在同一層與TCP一樣的其他協(xié)議也應(yīng)該響應(yīng)源抑制。在每種情況下，我們建
議應(yīng)該控制新的傳輸流量但正常對待確認(rèn)。唯一嚴(yán)重的問題來自于用戶數(shù)據(jù)報協(xié)
議，而通常不的主要傳輸發(fā)生器。我們?nèi)晕丛谶@些協(xié)議中實現(xiàn)任何流量控制。
網(wǎng)關(guān)的自防御
    正如我們已經(jīng)顯示的，網(wǎng)關(guān)易受擁塞管理不善的主機(jī)的攻擊。由于產(chǎn)生過多
通信量而引起的主機(jī)錯誤行為不僅防止了主機(jī)自身的傳輸而且能影響了其他不
相關(guān)的傳輸。這個問題可以在主機(jī)級處理，但既然一臺有故障的主機(jī)能影響其他
主機(jī)，將來的網(wǎng)關(guān)應(yīng)該有防御能力使它們自己不被那些可惡可憎的主機(jī)的這種行
為所影響。我們提供了一些基本的自防御技術(shù)。

    曾經(jīng)在1983年下半年，一個在ARPANT主機(jī)中的TCP故障使主機(jī)以ARPANET
所能接受的速度瘋狂地產(chǎn)生相同數(shù)據(jù)報的重發(fā)報文。通過ARPANET連接到我們網(wǎng)
絡(luò)的網(wǎng)關(guān)飽和，既然這個網(wǎng)關(guān)到ARPANET的帶寬比到我們網(wǎng)絡(luò)的要寬，少量有用
的傳輸能通過。網(wǎng)關(guān)忙于發(fā)送源抑制報文但故障主機(jī)忽略它們。這持續(xù)了幾個小
時，直到故障主機(jī)崩潰。在這期間，我們的網(wǎng)絡(luò)有效地從ARPANET上斷開。

    當(dāng)網(wǎng)關(guān)被迫丟棄一個數(shù)據(jù)包時，網(wǎng)關(guān)慎重地選擇要丟棄的數(shù)據(jù)包。做這個決
定的典型技術(shù)是丟棄最近收到的數(shù)據(jù)包，或者數(shù)據(jù)包在最長的輸出隊列的末端。
我們提出一個值得的實用方法是，丟棄在網(wǎng)關(guān)中產(chǎn)生最多數(shù)據(jù)包的隊列的對應(yīng)主
機(jī)所產(chǎn)生的最近的數(shù)據(jù)包，這種策略有助于平衡使用這個網(wǎng)關(guān)的各主機(jī)間的吞吐
量。我們還沒有嘗試過這個策略，但它似乎是網(wǎng)關(guān)自保護(hù)的一個合理開始點。

    另一個策略是丟棄新到來的數(shù)據(jù)包，如果這個數(shù)據(jù)包已經(jīng)在隊列中做了一個
拷貝。如果使用哈希技術(shù)，為實現(xiàn)這一檢查的計算負(fù)荷就不是問題。這個檢查不
能防止惡毒主機(jī)的攻擊，但提供了一些保護(hù)措施來防止帶低劣重傳控制的TCP實
現(xiàn)。如果本地主機(jī)與本地網(wǎng)絡(luò)很好地協(xié)調(diào)工作，那么在快速本地網(wǎng)與慢速長距離
網(wǎng)絡(luò)之間的網(wǎng)關(guān)可以發(fā)現(xiàn)這個檢查是有價值的。

    理想的情況是網(wǎng)關(guān)應(yīng)該檢測出故障主機(jī)并抑制它們；這樣的檢測在純數(shù)據(jù)報
系統(tǒng)中是困難的。雖然，對ICMP源抑制報文的響應(yīng)失敗應(yīng)該被認(rèn)為是網(wǎng)關(guān)與主
機(jī)斷開的依據(jù)。檢測這樣的失效是重不尋常的但它是一個值得進(jìn)一步研究的領(lǐng)
域。
 
結(jié)論
     
    與純數(shù)據(jù)報網(wǎng)絡(luò)相關(guān)的擁塞控制問題是困難的，但有效的解決辦法是存在
的。如果TCP/IP在重負(fù)荷下運(yùn)行，TCP實現(xiàn)算法必須以至少和這里描述過的解
決方法一樣有效的方式來解決這幾個關(guān)鍵的問題。
   在純ARPANET網(wǎng)中沒有這個問題，因為當(dāng)沒有處理的數(shù)據(jù)包過多時，IMP機(jī)制將封鎖主
機(jī)，但在這種情況下，涉及到純數(shù)據(jù)報本地網(wǎng)（比如以太網(wǎng)）或者一個純數(shù)據(jù)報網(wǎng)關(guān)（比如
ARPANET/MILNET 網(wǎng)關(guān)），有大量的小數(shù)據(jù)報未處理是有可能的。
  ARPANET RFC 792 是當(dāng)前的標(biāo)準(zhǔn)。國防通訊部門通告我們，在MIL-STD-1777
中的ICMP描述是不完全的，且在這個標(biāo)準(zhǔn)將來的修訂版中將被刪除。
  這點遵從控制學(xué)的觀點“不要受比例控制的干擾除非它不工作了。”

RFC896——Congestion Control in IP/TCP Internetworks        TCP/IP互聯(lián)網(wǎng)上的擁塞控制


1
RFC文檔中文翻譯計劃