rfc2887.txt

很多RFC的中文文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：范晨 (fanchen  [e-mail])
译文发布时间：2001-10-11
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。


Network Working Group                                         M. Handley
Request for Comments: 2887                                      S. Floyd
Category: Informational                                            ACIRI
                                                              B. Whetten
                                                                Talarian
                                                              R. Kermode
                                                                Motorola
                                                             L. Vicisano
                                                                   Cisco
                                                                 M. Luby
                                                  Digital Fountain, Inc.
                                                             August 2000

大量数据传输的可靠多播设计空间
（RFC2887——The Reliable Multicast Design Space for Bulk Data Transfer）

本备忘录状态 
本文档讲述了一种Internet通信的标准Internet跟踪协议,并对其改进提出了讨论和
建议。请参考最新版本的"Internet Official Protocol Standards" (STD 1) 来获得本协
议的标准化进程和状态，此备忘录的发布不受任何限制。
版权注意
版权归因特网协会（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. 简介
术语“一般用途的可靠多播协议”是一种自相矛盾的提法。不同的应用对于可靠多播传
输有不同的要求，而且这些要求往往使得要求不同的两个应用没有一个共同的解决方案。当
然，也有一些设计得很好的可靠多播协议能够较好满足多种不同的特定要求。
在本文档中我们试图回顾大量数据传输的可靠多播协议的设计空间。术语“大量数据传
输”（bulk data transfer）在这里是一个广义的名词，主要是指数据流是连续的并且长期
有效，这些限制对于我们所采取的拥塞控制方式是很有必要的。这样一个回顾的目的是为了
得到对这个领域的一个总体看法，并且使得各种特定机制所带来的影响更加明晰。我们的目
的是为了能够为将来这方面的协议标准化工作提供指导。在这里，我们将各种可能的解决方
案收集起来并大致分成若干类，一个实际的协议可能由其中的多种组成。
对解决方案最主要的一个限制是需要扩展到一个更大的接收者集合。对于一个小的接收
者集合，设计空间所受到的限制是很少的。
2.  应用限制
不同应用场合对于可靠多播（RM）的要求非常广泛和多样。然而，其中有一些要求对于
RM协议的设计有重大的影响，其中主要包括：
?	上层应用需要知道每个人都在接收数据吗？
?	上层应用需要限制不同接收端的差异吗？
?	上层应用需要扩展接收端集合吗？ 
?	上层应用需要是完全可靠的吗？ 
?	上层应用需要数据传输是有序的吗？ 
?	上层应用需要低延时传输吗？ 
?	上层应用需要传输有时间限制吗？ 
?	上层应用需要有很多交互的发送端吗？ 
?	数据流的传送是断断续续的吗？ 
?	上层应用需要在因特网中工作吗？ 
?	上层应用需要在单向信道中工作吗？（例如卫星信道）
?	上层应用需要数据传输是安全的吗？ 
   在对大量数据传输协议的标准化过程中，我们可以不考虑有多个交互的发送端和断断续
续的数据流的应用场合。并不是说这些应用不重要，而是因为我们对于这类应用缺乏有效的
拥塞控制手段。
2.1.  每个人都在接收数据吗？
在很多中应用中一个逻辑数据块需要发送给多个客户端，例如一个文件或一组文件，一
个软件包，一个股票配额或者一组股票配额，一个事件通知，一组幻灯片，视频流中的一帧
或者一块。我们将用户数据单元（Application data unit, ADU）定义为应用中有用的一个
逻辑上分离的数据单元。在某些情况下，一个逻辑数据单元可以小到放进一个单独的分组里
（例如一个时间通知或者一个股票配额），然而在另外一些情况下一个逻辑数据单元可能比
一个分组的长度大出很多（例如一个软件包）。
协议中可以将发送确认作为一个选项，从而保证可靠的传输。也就是接收端通知发送端
数据已经送到了这样一种机制。可以有两种类型的确认，一种是在ADU层，另一种是在分组
层。ADU确认在应用层非常有用，它可以使发送端了解接收端的接收进度并决定何时停止发
送一个特定ADU的分组。分组确认主要用于传输层，通知发送端某个分组以及接收到，这样
发送端就可以把该分组所占用的缓冲区释放掉。
某些应用要求所有的接收端都要对是否收到ADU做出确认，这样就可以知道哪些接收端
没有收到数据。这类应用包括收端按数据付费的应用，以及可靠文件系统复制的应用。其它
的一些应用并没有这方面的要求，一个典型例子就是自由软件发布下载。
如果应用确实需要知道是否每个接收端都收到了ADU，就必须从每个接收端都收到一个
正向的确认，当然也可以把这些确认联合起来发送。如果应用中需要确切知道哪个接收端没
有收到ADU，对于确认联合就需要有一些额外的限制。
在同一个应用中ADU层确认和分组层确认可以使用不同的确认机制。比如在ADU层使用
正向确认，而在分组层使用NACK或者基于FEC的传输。一般说来这种做法只是在ADU的长
度远远大于分组长度的时候比较有效。
2.2. 限制接收端的差异
在某些应用中需要限制接收端的差异，所有接收端的数据接收能力和特点都应当在一个
特定范围之内。一个典型的例子就是传送股票价格。如果有一个接收终端的接收延时明显比
其它终端要大，那么这将是不能接受的。
如果不损失一点点性能的话，这个要求是很难满足的。最典型的一种解决方法是要求发
送端在没有收到所有接收端的正向确认之前，发送的数据量不能超过一个限定的值。但是这
样一种方案在遇到网络故障或者某个终端故障的时候就会出问题。
2.3.  接收端集合扩展
在很多传送实时音视频的应用中并不需要扩展到很多的接收端。对于这些应用，就会有
很多不满足接收端扩展要求的解决方案可以满足它们的要求。
一个好的协议必须能够实现ADU到接收端的一个较高的吞吐量。这也就是说发送到接收
端的大部分数据对于重建ADU都是有用的。协议中还必须提供一个好的拥塞控制机制，与其
它应用公平地共享网络资源。要满足这些要求的话，接收端集合扩展是最重要的一个限制，
因为它把那些可以满足这些要求的方案严格限制到那些同时能够高效实现集合扩展的子集
中。为了实现这些目标，很多系统中都使用了确认分组，但必须认识到在不同方案中使用确
认分组的程度和方法有所不同。
在一个比较小的系统中，要求接收端对每一个分组做出确认是可行的。这样发送端就可
以得到所有接收端的接收状况的最多可能的信息，然后利用这些信息来实现一个较高的吞吐
量以及进行拥塞控制。
在一个大系统中，这样一个“平均ACK”方案在发送端引发“确认爆炸”（acknowledge 
implosion）。有些研究人员提出可以通过以较低的频率发送联合确认（aggregate ACK）来
缓解这个问题[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.  网络协作
一个可靠多播协议必然会涉及到运行在终端主机上的一套机制，同时也肯定会涉及到路
由器转发多播分组的机制。在某些情况下，可以在一定程度上依靠某些网络元素来协助实现
可靠多播传输。广义上我们按照依靠其它网络元素支持的程度来把实时多播协议分成四类：
?	不需要额外支持
路由器只是单纯的转发分组，可靠多播协议仅仅涉及到发送端和接收端。