本備忘錄狀態
本文檔講述了一種Internet通信的標準Internet跟蹤協議,并對其改進提出了討論和
建議。請參考最新版本的"InternetOfficial議的標準化進程和狀態，此備忘錄的發布不受任何限制。
版權注重
版權歸因特網協會（2000）所有，保留一切權利。
摘要
可靠多播傳輸的設計空間很廣，并且以及有很多可能的解決方案以及提出來了。然而，
實際應用中的一些具體要求將可能的解決方案限制在一個相對很小的空間之中。本文檔給出
了對于設計空間的一個概述，以及實際應用的限制條件如何影響可能的解決方案。
目錄
1.簡介 2
2.應用限制 2
2.1.每個人都在接收數據嗎？ 3
2.2.限制接收端的差異 3
2.3.接收端集合擴展 4
2.4.完全可靠vs半可靠 4
2.5.限時傳送 5
3.網絡限制 5
3.1.外聯網vs內聯網 5
3.2.返回路徑 5
3.3.網絡協作 5
4.實現高吞吐的機制 6
4.1.基于ACK的機制 6
4.2.基于NACK的機制 7
4.3.復制 8
4.4.分組層前向糾錯 9
4.5.分層FEC 9
5.擁塞控制機制 10
6.安全性問題 11
7.結論 11
8.致謝 12
9.作者地址 12
10.參考文獻 13
11.版權聲明 15
致謝 15

1.簡介
術語“一般用途的可靠多播協議”是一種自相矛盾的提法。不同的應用對于可靠多播傳
輸有不同的要求，而且這些要求往往使得要求不同的兩個應用沒有一個共同的解決方案。當
然，也有一些設計得很好的可靠多播協議能夠較好滿足多種不同的特定要求。
在本文檔中我們試圖回顧大量數據傳輸的可靠多播協議的設計空間。術語“大量數據傳
輸”（bulkdatatransfer）在這里是一個廣義的名詞，主要是指數據流是連續的并且長期
有效，這些限制對于我們所采取的擁塞控制方式是很有必要的。這樣一個回顧的目的是為了
得到對這個領域的一個總體看法，并且使得各種特定機制所帶來的影響更加明晰。我們的目
的是為了能夠為將來這方面的協議標準化工作提供指導。在這里，我們將各種可能的解決方
案收集起來并大致分成若干類，一個實際的協議可能由其中的多種組成。
對解決方案最主要的一個限制是需要擴展到一個更大的接收者集合。對于一個小的接收
者集合，設計空間所受到的限制是很少的。
2.應用限制
不同應用場合對于可靠多播（RM）的要求非常廣泛和多樣。然而，其中有一些要求對于
RM協議的設計有重大的影響，其中主要包括：
? 上層應用需要知道每個人都在接收數據嗎？
? 上層應用需要限制不同接收端的差異嗎？
? 上層應用需要擴展接收端集合嗎？
? 上層應用需要是完全可靠的嗎？
? 上層應用需要數據傳輸是有序的嗎？
? 上層應用需要低延時傳輸嗎？
? 上層應用需要傳輸有時間限制嗎？
? 上層應用需要有很多交互的發送端嗎？
? 數據流的傳送是斷斷續續的嗎？
? 上層應用需要在因特網中工作嗎？
? 上層應用需要在單向信道中工作嗎？（例如衛星信道）
? 上層應用需要數據傳輸是安全的嗎？
在對大量數據傳輸協議的標準化過程中，我們可以不考慮有多個交互的發送端和斷斷續
續的數據流的應用場合。并不是說這些應用不重要，而是因為我們對于這類應用缺乏有效的
擁塞控制手段。
2.1.每個人都在接收數據嗎？
在很多中應用中一個邏輯數據塊需要發送給多個客戶端，例如一個文件或一組文件，一
個軟件包，一個股票配額或者一組股票配額，一個事件通知，一組幻燈片，視頻流中的一幀
或者一塊。我們將用戶數據單元（applicationdataunit,ADU）定義為應用中有用的一個
邏輯上分離的數據單元。在某些情況下，一個邏輯數據單元可以小到放進一個單獨的分組里
（例如一個時間通知或者一個股票配額），然而在另外一些情況下一個邏輯數據單元可能比
一個分組的長度大出很多（例如一個軟件包）。
協議中可以將發送確認作為一個選項，從而保證可靠的傳輸。也就是接收端通知發送端
數據已經送到了這樣一種機制?？梢杂袃煞N類型的確認，一種是在ADU層，另一種是在分組
層。ADU確認在應用層非常有用，它可以使發送端了解接收端的接收進度并決定何時停止發
送一個特定ADU的分組。分組確認主要用于傳輸層，通知發送端某個分組以及接收到，這樣
發送端就可以把該分組所占用的緩沖區釋放掉。
某些應用要求所有的接收端都要對是否收到ADU做出確認，這樣就可以知道哪些接收端
沒有收到數據。這類應用包括收端按數據付費的應用，以及可靠文件系統復制的應用。其它
的一些應用并沒有這方面的要求，一個典型例子就是自由軟件發布下載。
假如應用確實需要知道是否每個接收端都收到了ADU，就必須從每個接收端都收到一個
正向的確認，當然也可以把這些確認聯合起來發送。假如應用中需要確切知道哪個接收端沒
有收到ADU，對于確認聯合就需要有一些額外的限制。
在同一個應用中ADU層確認和分組層確認可以使用不同的確認機制。比如在ADU層使用
正向確認，而在分組層使用NACK或者基于FEC的傳輸。一般說來這種做法只是在ADU的長
度遠遠大于分組長度的時候比較有效。
2.2.限制接收端的差異
在某些應用中需要限制接收端的差異，所有接收端的數據接收能力和特點都應當在一個
特定范圍之內。一個典型的例子就是傳送股票價格。假如有一個接收終端的接收延時明顯比
其它終端要大，那么這將是不能接受的。
假如不損失一點點性能的話，這個要求是很難滿足的。最典型的一種解決方法是要求發
送端在沒有收到所有接收端的正向確認之前，發送的數據量不能超過一個限定的值。但是這
樣一種方案在碰到網絡故障或者某個終端故障的時候就會出問題。
2.3.接收端集合擴展
在很多傳送實時音視頻的應用中并不需要擴展到很多的接收端。對于這些應用，就會有
很多不滿足接收端擴展要求的解決方案可以滿足它們的要求。
一個好的協議必須能夠實現ADU到接收端的一個較高的吞吐量。這也就是說發送到接收
端的大部分數據對于重建ADU都是有用的。協議中還必須提供一個好的擁塞控制機制，與其
它應用公平地共享網絡資源。要滿足這些要求的話，接收端集合擴展是最重要的一個限制，
因為它把那些可以滿足這些要求的方案嚴格限制到那些同時能夠高效實現集合擴展的子集
中。為了實現這些目標，很多系統中都使用了確認分組，但必須熟悉到在不同方案中使用確
認分組的程度和方法有所不同。
在一個比較小的系統中，要求接收端對每一個分組做出確認是可行的。這樣發送端就可
以得到所有接收端的接收狀況的最多可能的信息，然后利用這些信息來實現一個較高的吞吐
量以及進行擁塞控制。
在一個大系統中，這樣一個“平均ACK”方案在發送端引發“確認爆炸”（acknowledge
implosion）。有些研究人員提出可以通過以較低的頻率發送聯合確認（aggregateACK）來
緩解這個問題[RMWT98,BC94]，但是在這類方案中很難實現有效的擁塞控制，因為反饋信息
的頻率過低。
用反向確認（NACKs）來替代正向確認（ACKs）能夠將這個問題降低為“反向確認爆炸”。
并且事實上發送端也只需要知道至少有一個接收端丟失了數據，我們可以使用多種NACK抑
制機制來實現較高的吞吐率。
環形拓撲ACK方案也是一種可行的解決方案，但是它比樹形拓撲更難組建和維護。還有
一種方法是在路由器中添加一些機制，由它們來幫助實現較高的吞吐率并盡可能降低代價。
以上這些方案都有助于改善接收端集合擴展，但是它們都有一些這樣那樣的局限。有一
類方案可以擴展到無窮多的接收端，即徹底取消所有的反饋信道，這樣就可以實現很高的吞
吐率。這樣一類開環解決方案將原始數據用FEC機制進行編碼，然后把這些編碼后的數據放
在一個連續的數據流中傳輸。接收端可以加入這個多播會話，然后接收足夠多的分組直到能
夠解碼出原始數據，之后它們就退出會話。
因此，會話的目標規模顯然是可能解決方案的一個限制條件。所有的解決方案對于小規
模的會話都可以工作得很好，但是隨著會話得目標規模增大，可用的解決方案也就越來越少。
應當指出以上這些方案的混合也可能是可行的，比如在分組層使用一種方案，而在ADU
層使用另一種方案（典型情況下overhead高），這在ADU遠遠大于分組長度的情況下也可
以得到比較好的效果。
2.4.完全可靠vs半可靠
很多應用要求ADU的傳輸是完全可靠的。假如任何一個ADU丟失，那么接收到的所有其
它ADU都沒有意義。最典型的例子就是文件傳輸應用。
然而，有些應用并不需要傳輸是完全可靠的。這方面的一個例子的音頻廣播，在這種應
用中，丟失的分組會使得重建的音頻信號質量下降，但并不會致使整個信號失效。這類應用
在ip層之上不加任何額外可靠機制的情況下有時也可以正常工作，但是最好是能夠有一個
半可靠的傳輸協議。
2.5.限時傳送
多數應用要求數據盡可能快地被傳送到接收端，但通常并沒有一個絕對的傳輸最后期
限。
然而，有些應用對于數據傳送有硬性的時間限制，假如數據沒有在一個特定時間之前到
達接收端，那么傳輸這些數據就沒有任何意義了。這些時間限制其實是音視頻傳輸的實時限
制的結果，或者是新數據取代舊數據的結果。相對于文件傳輸，這兩類應用對于傳輸時間必
須進行更加精確的控制。
限時傳送一般也隱含著傳輸是半可靠的，但是反過來并不成立。
3.網絡限制
應用所配置的網絡本身的一些特點也對可靠多播設計空間增加了一些限制條件。
3.1.外聯網vs內聯網
原理上外聯網和內聯網是一樣的，但是在實際應用中，內聯網是集中控制治理的，可以
使用一些在外聯網上根本不可能實現的解決方案。因此在內聯網中，假如數據的價值非常高，
可以通過適當升級路由器來協助實現一個可靠多播傳輸協議。而在公開的外聯網中，這方面
的額外開支是不可接受的。
3.2.返回路徑
理論上講當接收端要將反饋信息傳回發送端的時候，既可以用多播，也可以用單播。用
多播來傳送反饋信息有更大的優勢，非凡是在基于NACK的協議中要抑制NACK的時候。但是，
我們并不清楚ISP是否答應一個會話的所有成員都把反饋信息發向這個會話。假如不答應使
用多播反饋，那么就只能用單播來進行反饋，這樣的代價是引入更多的消息機制。
有些網絡中不答應任何形式的反饋。一個例子就是在衛星廣播信道中，反向信道通常帶
寬非常窄，甚至根本不存在。在這樣的網絡中就只有基于FEC的解決方案才有可能工作。如
果接收端直接從衛星信道接收數據，那么擁塞控制是不需要的。但是作這樣的假定是很危險
的，因為也有可能衛星信道下來以后還有一個下游網絡。因此，仍然需要考慮一個不需要返
回路徑的擁塞控制的解決方案。
3.3.網絡協作
一個可靠多播協議必然會涉及到運行在終端主機上的一套機制，同時也肯定會涉及到路
由器轉發多播分組的機制。在某些情況下，可以在一定程度上依靠某些網絡元素來協助實現
可靠多播傳輸。廣義上我們按照依靠其它網絡元素支持的程度來把實時多播協議分成四類：
? 不需要額外支持
路由器只是單純的轉發分組，可靠多播協議僅僅涉及到發送端和接收端。
? 分層方式
數據被分發到多個多播組中，接收端通過加入適當的多播組來接收它們所需要的數
據。在某些情況下，這要求路由器能夠支持快速加入和離開一個多播組，并且支持
更多的轉發狀態。
? 基于服務器的方式
用一些額外的節點來協助實現數據發送和反饋信息的聯合。這些額外的節點可能并
不是一般意義上的發送端或者接收端，它們在反饋樹中的作用只是協助實現可靠多
播協議。它們并不需要接收多播數據。
? 基于路由器的方式
在基于路由器的方式中，從發送端到接收端的數據流路徑上的路由器可以協助實現
數據的發送和反饋信息的聯合與抑制。因為路由器可以直接改變多播的路由，因此
這種方式比起基于服務器的方式對于數據流量以及哪些流量發給哪些組成員可以有
更靈活的控制。然而，一般說來路由器并沒有太多剩余的存儲量和運算量，這就限
制了能夠加入多少額外的功能。并且，路由器的代碼比應用程序的代碼更難維護，
因此基于路由器的方式應當盡可能具有普適性，它們一旦投入使用就很難再去改變。
4.實現高吞吐的機制
作為一個可靠多播協議，有兩個問題是必須解決的，一個是擁塞控制，另一個是高吞吐
率。丟包是跟這兩個問題都有關的一個核心問題。在多數網絡中擁塞的主要征兆就是丟包。
而實現高吞吐率的主要障礙也是丟包。因此度量丟包率和抑制丟包就成為解決這兩個問題的
要害所在。針對這些問題的可靠多播解決方案大致可以分為以下幾類：
? 數據包確認
? 丟失數據包的反向確認
? 加入冗余，使接收端能夠恢復丟包
這些方法還可以再進行細分，這樣我們就可以檢查每一種技術能夠應用在何種限制條件
下。在這一節中，我們重點探討使用這些機制來實現高吞吐率，而在下一節中我們將重點研
究使用這些機制來實現擁塞控制。
4.1.基于ACK的機制
在最簡單的基于ACK的機制中，每個接收端對于收到的每個數據包都要發一個ACK包給
發送端，對于每個丟失的數據包發一個重傳包給發送端。這樣一種機制只能應用于小規模的
多播，否則就會在發送端引發ACK確認爆炸。由于這個原因，這種機制對于大多數應用來說
是不可行的。
將多個ACK放入一個單獨的數據包[RMWT98]可以緩解確認爆炸的問題，多播組的規?？?br />以更大一些。然而很快會走到另一個極端，從接收端到發送端的反饋信息頻率過低，從而基
于發送端的擁塞控制機制不能夠可靠工作。
將接收端排成一個環[WKM94]，通過在環上傳送一個“ACK令牌”就可以杜絕確認爆炸問
題的出現。然而環本身的生成和維護很成問題。而且假如環的生成過程中不考慮網絡的實際
拓撲（了解網絡拓撲在實際中是一個很難的問題），那么每個數據包引發的ACK包通過網絡
干線的次數將隨著接收端的數量以O(n)增長。
4.1.1.基于樹的ACK機制
將接收端排成樹形結構[MWB+98,KCW98]，每個接收端將ACK確認發給它的父節點，父
節點再將這些ACK確認聯合起來一起發給更上層的父節點。這樣一種機制比起環形結構更穩
健也更輕易配置。這樣一個樹形結構只是用于ACK的聯合，數據包的多播仍然按照正常方式
進行。樹形結構比環形結構更易于構造，因為有更多的局部信息可以利用。而且樹形結構的
容錯能力也更強，假如有某個節點出故障，受到影響的只是它的所有后代節點。這些后代節
點在發現父節點出現故障之后還可以直接越過父節點，直接向更高一層的節點報告。用這樣
一個優秀的ACK樹形結構，基于樹的ACK機制將有可能成為擴展性最好的一種可靠多播解決
方案。
為了更易于配置，基于樹的協議必須是自組織的，也就是說那些接收端必須利用局部信
息以一種可擴展的方式自己生成樹形結構的拓撲。這種方式是完全可行的，但卻并不輕易。
對于基于數的協議來說，限制擴展規模的主要因素是樹的生成和維護機制，而不是ACK確認。
假如沒有這樣一個可擴展的自動生成樹形拓撲的機制，協議在實現的時候就必須依靠手工來
配置，這就大大降低了它的可用性和可擴展性。
與樹的生成有關的另外一個問題是子樹的重傳問題。通過適當的路由機制，或者使用多
個多播組，可以由中間節點來把下層節點丟失的數據包重新發給它們，而不是由發送端來重
傳這些數據。這依靠于ACK樹拓撲和實際數據樹的拓撲的中間節點有很好的相關性，并且需
要有相關的機制來限制從發送端到子樹的重傳。一個好的樹拓撲自動生成機制與分區治理的
多播組結合起來可能提供這樣一個解決方案。假如沒有這樣的一個樹自動生成機制，就很難
在Internet上的一個很大的多播組中使用子樹重傳技術。這也可以通過使用傳輸層路由器
的支持來幫助執行重傳，盡管當前的路由器機制[FLST98]支持基于NACK的協議，而不支持
基于ACK的協議。
另外一個重要的問題是ACK樹中間節點所做的聯合操作的本質是什么。這些節點能夠：
1． 假如所有子節點都發送ACK，就把它們聯合起來，發送一個單獨的ACK
2． 通過發送有ACK的子節點的列表，來進行ACK的聯合操作
3． 發送一個聯合的ACK，外加一個NACK子節點列表
對于數據包來說，第1種方法顯然擴展性更好。然而，假如發送端需要確切知道哪些接
收端收到了數據，第2，3種方法就提供了這些信息。幸運的是，一般說來并不需要對每個
包做這樣的操作，而只需要對每個ADU提供這樣的信息就可以了。在數據包層用第1種方法，
而在ADU層用第3種方法，這是對于需要這種信息的應用的擴展性最好的解決方案，與其它
數據包層的解決方案相比實際上并沒有帶來多少開銷。
4.2.基于NACK的機制
接收端可以不需要為每個收到的數據包都發送一個ACK，而是對每個檢測到已經丟失的
數據包發送一個反向確認（NACK）。這樣一種機制相對于基于ACK的機制有以下的優點：
? 發送端不需要知道接收端的確切數目，這樣就可以將建立拓撲階段從環狀或樹狀的
基于ACK的算法中去掉。
? 由接收端來負責可靠性，容錯措施就可以相對簡單一些。
? 發送端的狀態可以大量減少，因為發送端不需要去跟蹤接收端的狀態。
? 不管多少個接收端丟失了某個數據包，都只需要發送一個NACK給發送端就可以了。
所以NACK抑制是完全可行的。
不足之處在于發送端很難知道它何時可以釋放發送緩沖區，并且需要有一些額外的會話
層機制來通知發送端某個接收端已經收到了全部數據。對于大多數應用來說，這些問題都并
不重要。
4.2.1.NACK抑制
基于NACK的協議之間的一個最大差別就在于NACK抑制是如何做的。NACK抑制的目標是
當第一次發現某個包丟失之后，馬上發送一個并且只有一個NACK到發送端，然后丟失數據
的唯一一份拷貝重新發送出來，并且被那些需要這個包的接收端接收下來。
不同的協議用不同的方法來滿足或接近滿足這些目標。
? SRM[FJM95]中用發送端到丟失數據的節點之間的閉環傳輸時間（Roundtriptime,
RTT）來對隨機定時器進行加權。這種方法很有效，但是在NACK抑制開始之前需要
計算每個節點的RTT。
? NTE[HC97]使用一個基于隨機密鑰和滑動窗口的發送端觸發機制。這種方法不需要
隨機定時器，可以用于大型的會話，但是在進行擁塞控制的時候，很難提供一個穩
定的底層反饋流。
? AAP[Ha99]用指數分布的隨機定時器，不需要計算RTT，因此對于大型會話也很有效。
? PGM[FLST98]和LMS[PPV98]中在路由器中加入額外的算法來抑制重復的NACK。在
PGM中，路由器可以與SRM中的隨機定時器協同工作，并且使抑制局部化，從而不
需要對整個多播組進行整體的NACK抑制。
這些方法中最一般的可能是指數分布的隨機定時器。盡管使用SRM中的定時器可以減少
反饋延時，但是在RTT未知或接收端總數未知的情況下，它很難得到實際的應用。相比之下，
指數分布的隨機定時器對于一個大型的會話，不管其延時特性是好是壞，都可以很好地工作。
只要有可能，任何一種形式的基于隨機定時器的方法都可以與路由器的支持結合起來。
發送端觸發機制[HC97]就很難與路由器的相關支持結合起來。
4.3.復制
有些可靠多播協議設計時多數情況下并不需要有顯式的可靠機制。比如說，在一個用多
播實現的多人網絡游戲中，將一個運動物體的位置不停地用多播發出去。這種位置流信息并
不需要額外的可靠保證，因為在重傳一個舊的位置之前，新的位置已經取代了舊的位置。然
而，當運動物體與其它物體相交互或者停止移動的時候，就需要保證交互信息或者最終的位
置信息的傳送是完全可靠的。
并不只是游戲需要考慮這類問題。NTE共享文本編輯器[HC97]使用同樣的機制來處理一
行文字的變化。對于每次更改，都重新發送整個行，那么這種情況下不需要有額外的可靠保
證。復制的主要優勢在于它不易收到空間上不相關的丟包的影響。對于傳統的基于ACK或
NACK的協議，任何一個包被一個很大的接收端集合中的所有接收端正確接收的概率相當低。
這就導致重傳的碼率相當高。相比起來，復制流并不受接收端集合增長的影響，不同的接收
端丟失的包通常不同，而這時并不會增加網絡的流量。
4.4.分組層前向糾錯
前向糾錯是用來保護數據使之免受誤碼破壞的一項很成熟的計數。擦除碼在可靠多播可
以得到很好的應用。
最簡單的分組層的FEC就是將若干個將要發出的分組合起來對它們進行異或操作，生成
一個新的分組，并將這個新的分組也發送出去。假如每三個原始分組生成一個新的異或分組，
那么這三個分組中的任何一個丟失，而異或分組收到的話，丟失的原始分組可以重建出來。
還有一些更為一般的擦除碼[BKKKLZ95],[Ri97],[LMSSS97]可以用k個原始分組生成n
個分組發送出去。這樣，只要接收到n個分組中的任意k個分組，k個原始分組都可以完全
重建出來。
在應用FEC的時候，發送端將數據分組分成若干輪，每次對一輪中的分組進行編碼并生
成新的監督分組。某些情況下一輪中的所有分組就構成了一個ADU，而在另外一些情況下一
輪中的分組只是ADU的一小部分。
用擦除碼來恢復丟包比起用重傳機制有很大的進步，因為這時發送端并不需要知道哪些
分組丟失了。因此，在恢復空間上無關的丟包的時候，重傳流量就大大減少了。
我們可以把分組層的FEC方案分成兩類：主動FEC和被動FEC。這兩者的區別在于：主
動FEC中發送端先驗地確定對于每一輪數據分組生成多少個監督分組；而在被動FEC中發送
端最開始只發送原始分組，并不發送監督分組，然后，發送端根據接收端的反饋來計算出丟
包最嚴重的接收端每一輪有多少個丟包，并以此來決定應當生成多少個監督分組。這些監督
分組當然也可以用于丟包不太嚴重的接收端恢復丟包。接收端通過ACK和NACK來向發送端
報告每一輪有多少個丟包。用NACK的時候，只有每一輪丟包最嚴重的接收端需要發送一個
NACK，因此它的丟包數就被用來作為NACK中隨機定時器的權重。
主動FEC和被動FEC可以結合起來使用，例如，對每一輪發送都使用一定量的主動FEC，
假如某個接收端丟包過于嚴重無法恢復時，它可以請求發送端對這幾輪數據包增加FEC監督
包的數量。
FEC對于減少丟包所造成的重傳流量是很有效的，然而，它要求數據分組分成輪來發送，
這會增加端到端的延時。對于大數據量的應用來說這一般不成什么問題，但是對于交互式應
用來說，這種方法可能就不如直接重復發送更為有效。
4.5.分層FEC
當數據被同時發往多個多播組的時候，可以應用另外一種分組層的
FEC[RVC98][BLMR98]。在這種情況下，原始的k個分組經過FEC生成n個編碼分組，n遠遠
大于k。然后這n個編碼分組被分別發往多個多播組。當某個接收端想要接收原始數據時，
它可以加入一個或多個多播組，并接收編碼分組。當它接收到k個不同的編碼分組，它就可
以退出這些多播組并重建出原始的k個分組。
這樣一種分層機制的最重要之處在于不同的接收端可以根據它們自己的容量、處理能力
等以不同的速率來接收數據。這種機制中不需要接收端送回任何反饋信息，這樣就可以保證
較高的吞吐率，并且吞吐率并不因為接收端集合的大小而受影響。然而，接收端以這種方式
來加入和離開多播組，會給擁塞控制機制帶來一定的問題。同一個擁塞控制鏈上的接收端在
加入和離開分組的時候需要相互協調一下。如下一節所述，[RVC98]中提出了一個分層的擁
塞控制方案。
5.擁塞控制機制
Internet的基本傳輸模型是最大努力服務（best-effortservice）。在這種模型中，
不保證任何的吞吐率、延時和丟包率。終端系統被認為是自適應的，能夠在網絡擁塞的情況
下把它們的傳輸率適當降低。盡管以后Internet會開始支持帶寬預留并對一些特定應用支
持不同的服務等級，但是除非終端系統明確知道它已經預留了帶寬，否則它還是要進行擁塞
控制。
廣義上講，單發送端的多播擁塞控制解決方案有五類：
? 發送端控制，單組
只有一個多播組來做數據傳輸。用從接收端傳回的反饋來控制這個組的發送速率。
目標是按照最慢的接收端的速率來進行傳輸。
? 發送端控制，多組
把最初得一個多播組按照擁塞點自適應地劃分成若干個子組。在應用層，數據首先
發送到離發送端最近的子組，然后由這個子組將數據以更低的速率轉發到更遠的子
組。用這樣一種方式，不同的接收端可以以不同的速率來接收數據。在子組內仍然
使用基于發送端的擁塞控制方案。
? 接收端控制，單組
只有一個多播組來做數據傳輸。由接收端來根據當前網絡的擁塞狀況決定是否發送
端的速率過高，不能適應這個速率的接收端就自動離開多播組。
? 接收端控制，分層組織
[RVC98]中提出了一種不需要接收端反饋的分層的擁塞控制機制。發送端將數據同
時分散的發往多個多播組，接收端根據它們自己的網絡帶寬及網絡的擁塞狀況來決
定加入哪些多播組，使得接收的數據量能夠適應網絡的擁塞狀況。然而，這種方案
要求在一條瓶頸鏈路之后的若干個接收端能夠相互協調地加入和離開不同的多播
組。并且這種方法是否能夠在實際的Internet上應用還未得到完全證實。因此，
在擁塞控制方案上還需要有更深入的工作。
? 基于路由器的擁塞控制
可以在多播路由器中加入額外的機制來協助進行多播的擁塞控制。這些機制包括：
? 條件性加入：某個接收端在加入多播組時設定一個丟包率，當高于這個丟包率
時，答應路由器拒絕其加入。
? 路由器過濾掉合理速率以上的流量。這也包括在網絡的不同位置根據局部擁塞
狀況設定不同的合理速率[LVS99]。
? 公平排隊機制結合端到端速率自適應調整
基于路由器的方案要求路由器比起傳統的干線路由器有更多的狀態。因此，在短期
內，這類方案只能應用于內聯網。
對于可靠多播協議，必須把擁塞控制和可靠傳輸放在同等重要的位置來考慮。同樣的機
制有時在提供可靠傳輸的同時也實現了擁塞控制。
在基于接收端的擁塞控制方案中，用FEC來做開環數據傳送是一個很好的選擇，對于大
數據量傳輸能夠達到較高的吞吐率。這是因為開環數據傳送不需要接收端的反饋，而基于接
收端的擁塞控制同樣也不需要接收端反饋，因此它們是一個完美的配合。
6.安全性問題
一般說來，安全性方面的考慮不會對可靠多播協議的設計帶來太大的影響。影響到協議
設計的最主要問題在于接收端集合的擴展。對于數據源和數據完整性驗證，接收端集合擴展
并不是一個很大的問題。然而，對于數據加密，密鑰分發，以及密鑰的重生都會收到接收端
集合擴展的嚴重影響。基于樹和圖的密鑰重生解決方案[WHA98,WGL97]可能是一個合適的解
決方案。然而這類密鑰重生解決方案會如何影響可靠多播協議的數據傳輸部分的設計還不是
很清楚。
可靠多播協議的安全性中需要考慮的一個主要問題在于第三方的角色。假如除了原始數
據源以外的節點可以被答應發送或轉發分組，那么協議的安全模型就必須把這一點考慮進
去。尤其是必須弄清楚這些第三方是否是受信任的。假如協議要求第三方必須是受信任的，
那么這樣一個協議就很難應用在Internet上。
假如驗證機制在設計上考慮到這一點的話，不受信任的第三方（比如重發數據的接收端）
也是可以應用的。一個典型的做法就是由發送端對數據進行數字簽名，并打上時間戳，第三
方原樣轉發這些由數字簽名和時間戳的載荷。
與單播協議不同，多播協議假如在設計的時候不加以非凡考慮，將很輕易受到拒絕服務
攻擊。這時因為任何人都可以加入多播會話，并發送反饋信息來影響整個會話乃至其它接收
端。因此必須仔細考慮怎樣設計可靠多播協議保護它免受拒絕服務攻擊。一個接收端可能會
要求重發所有的包，或者在基于ACK的協議中拒絕發送ACK確認，這樣就有可能會導致一個
可靠多播會話陷入停頓。發送端必須采取相應的策略來處理這樣的情況，并在必要的時候把
這樣的接收端從組中驅逐出去。一個單個的接收端有可能會偽裝成一大群接收端，這在基于
NACK的協議中仍然會是一個問題。在接收端第一次單播響應時為它們每個都分配一個單獨
的密鑰也許可以避免這類攻擊。
由于流量泛濫引發的拒絕服務攻擊相對起來比單播輕易防范。不想要的發送端可以用
IGMPv3[CDT99]中的機制將它們之間從樹形拓撲中刪掉。
7.結論
本文中我們縱覽了一對多大量數據傳輸的可靠多播協議設計的概況。多播應用的其它特
點本文中沒有考慮。在回顧各種設計策略的過程中，我們重申了可靠多播協議的設計受到很
多因素的影響，因此設計一個能夠適用所有情況的解決方案是沒有意義的。接著我們描述了
這些影響可靠多播協議設計的因素，并借此說明了應用的需要是如何影響設計協議時各種技
術的選用及組合。我們檢查了一種基本的技術，并闡釋了它們是如何滿足特定應用的要求的。
本文意圖為將來IETF對大量數據的可靠多播協議標準化過程提供指導。鑒于各種應用
對于可能解決方案的限制程度，以及需要支持的各種各樣應用，可以預見將來的標準化將會
在測試上做大量的工作。這也隱含著不是一次完成對可靠多播傳輸協議的標準化，而是將這
些協議分解成功能模塊，并在可能情況下最大程度上對這些功能模塊分離進行標準化。這樣
一種方法可以答應協議進化，并使得有新要求的應用能夠最大程度上重用已存在并經過測試
的一些技術。
8.致謝
本文回顧了可靠多播設計的不同解決方案。文中介紹的各種思想并不屬于作者，而是從
IRTF的可靠多播研究組的各種文檔中收集得來。盡管無法將他們的名字都列出來，我還是
要謝謝那些在文檔中做出貢獻的參與者。
9.作者地址
MarkHandley
ATTCenterforInternetResearchatICSI,
InternationalComputerScienceInstitute,
1947CenterStreet,Suite600,
Berkeley,CA94704,USA

EMail:mjh@aciri.org

SallyFloyd
ATTCenterforInternetResearchatICSI,
InternationalComputerScienceInstitute,
1947CenterStreet,Suite600,
Berkeley,CA94704,USA

EMail:floyd@aciri.org

BrianWhetten
TalarianCorporation,
333DistelCircle,
LosAltos,CA94022,USA

EMail:whetten@talarian.com

RogerKermode
MotorolaAustralianResearchCentre
Level3,12LordSt,
BotanyNSW2019,
Australia

EMail:Roger.Kermode@motorola.com

LorenzoVicisano
CiscoSystems,
170WestTasmanDr.
SanJose,CA95134,USA

EMail:lorenzo@cisco.com

MichaelLuby
DigitalFountain,Inc.
600AlabamaStreet
SanFrancisco,CA94110

EMail:luby@digitalfountain.com
10.參考文獻
[BC94]K.Birman,T.Clark."PerformanceoftheIsisDistributed
ComputingToolkit."TechnicalReportTR-94-1432,Dept.of
ComputerScience,CornellUniversity.

[BKKKLZ95]J.Bloemer,M.Kalfane,M.Karpinski,R.Karp,M.Luby,D.
ZUCkerman,"AnXOR-basedErasureResilientCodingScheme",
ICSITechnicalReportNo.TR-95-048,August1995.

[BLMR98]J.Byers,M.Luby,M.Mitzenmacher,A.Rege,"ADigital
FountainApproachtoReliableDistributionofBulkData",
ProcACMSIGCOMM98.

[CDT99]Cain,B.,Deering,S.,andA.Thyagarajan,"InternetGroup
ManagementProtocol,Version3",WorkinProgress.

[FLST98]Farinacci,D.,Lin,S.,Speakman,T.andA.Tweedly,"PGM
reliabletransportprotocolspecification",Workin
Progress.

[FJM95]S.Floyd,V.Jacobson,S.McCanne,"AReliableMulticast
FrameworkforLight-weightsessionsandApplicationLevel
Framing",ProcACMSIGCOMM95,Aug1995pp.342-356.

[Ha99]Handley,M.,"Multicastaddressallocationprotocol
(AAP)",WorkinProgress.

[HC97]M.HandleyandJ.Crowcroft,"Networktexteditor(NTE)a
scalablesharedtexteditorforMBone,"ACMComputer
CommunicationReview,vol.27,pp.197-208,Oct.1997.ACM
SIGCOMM'97,Sept.1997.

[KCW98]Kadansky,M.,Chiu,D.andJ.Wesley,"Tree-basedreliable
multicast(TRAM)",WorkinProgress.

[LMSSS97]M.Luby,M.Mitzenmacher,A.Shokrollahi,D.Spielman,V.
Stemann,"PracticalLoss-ResilientCodes",ProcACM
SymposiumonTheoryofComputing,1997.

[MWB+98]Montgomery,T.,Whetten,B.,Basavaiah,M.,Paul,S.,
Rastogi,N.,Conlan,J.andT.Yeh,"THERMTP-II
PROTOCOL",WorkinProgress.

[PPV98]C.Papadopoulos,G.Parulkar,andG.Varghese,"Anerror
controlschemeforlarge-scalemulticastapplications,"in
ProceedingsoftheConferenceonComputerCommunications
(IEEEInfocom),(SanFrancisco,California),p.1188,
March/April1998.

[Ri97]L.Rizzo,"Effectiveerasurecodesforreliablecomputer
communicationprotocols,"ACMComputerCommunication
Review,vol.27,pp.24-36,Apr.1997.

[RV97]L.Rizzo,L.Vicisano,"AReliableMulticastdata
DistributionProtocolbasedonsoftwareFECtechniques",
Proc.ofTheFourthIEEEWorkshopontheArchitectureand
ImplementationofHighPerformanceCommunicationSystems
(HPCS'97),SaniBeach,Chalkidiki,GreeceJune23-25,
1997.

[RVC98]L.Rizzo,L.Vicisano,J.Crowcroft,"TheRLCmulticast
congestioncontrolalgorithm",submittedtoIEEENetwork-
specialissuemulticast.

[RMWT98]Robertson,K.,Miller,K.,White,M.andA.Tweedly,
"StarBurstmulticastfiletransferprotocol(MFTP)
specification",WorkinProgress.

[WHA98]Wallner,D.,Hardler,E.andR.Agee,"KeyManagementfor
Multicast:IssuesandArchitectures",RFC2627,June1999.

[WKM94]BrianWhetten,SimonKaplan,andToddMontgomery,"Ahigh
performancetotallyorderedmulticastprotocol,"research
memorandum,Aug.1994.

[WGL97]C.K.Wong,M.Gouda,S.Lam,"SecureGroupCommunications
UsingKeyGraphs,"TechnicalReportTR97-23,Department
ofComputerSciences,TheUniversityofTexasatAustin,
July1997.
11.版權聲明
版權歸Internet協會所有（2000）。保留所有權利。
本文及其譯本可以提供給其他任何人，可以預備繼續進行注釋，可以繼續拷貝、出版、
發布，無論是全部還是部分，沒有任何形式的限制，不過要在所有這樣的拷貝和后續工作中
提供上述聲明和本段文字。無論如何，本文檔本身不可以做任何的修改，比如刪除版權聲明
或是關于Internet協會、其他的Internet組織的參考資料等。除了是為了開發Internet
標準的需要，或是需要把它翻譯成除英語外的其他語言的時候，在這種情況下，在Internet
標準程序中的版權定義必須被附加其中。
上面提到的有限授權答應永遠不會被Internet協會或它的繼續者或它的下屬機構廢除。
本文檔和包含在其中的信息以"Asis"提供給讀者，Internet社區和Internet工程任務
組不做任何擔保、解釋和暗示，包括該信息使用不破壞任何權利或者任何可商用性擔保或特
定目的。
致謝
Internet協會當前為RFC編輯提供了資助，對此表示感謝。