友好TCP拥塞控制协议总结

Friendly TCP Congestion Control Summary

Abstract With the increase of video streaming applications in the network, non-TCP traffic increases. Because these applications usually do not use TCP compatible congestion control mechanisms, they treat competing TCP flows unfairly: when encountering congestion, all competing TCP flows will reduce their data rates to try to eliminate congestion, while non-TCP flows continue to send at their original rates. This extremely unfair situation leads to insufficient TCP traffic. The existence of friendly TCP congestion control can ensure that TCP flows in data flows will not be unfairly treated by non-TCP flows. Therefore, in this paper, we explore friendly TCP congestion control, summarize several friendly TCP congestion control protocols, and compare these protocols.

Key words TCP; TCP congestion control; friendly TCP congestion control

摘要 随着网路中视频流应用程序的增加，使得非TCP流量增加。这些非TCP流量会以不公平的方式对待竞争的TCP流，如果遇到拥塞，TCP流会降低其数据速率，以试图消除拥塞，而非TCP流则继续以其原始速率发送。这种极不公平的情况导致TCP流量不足。友好TCP拥塞控制的存在能够确保数据流中的TCP流不会受到非TCP流的不公平对待。因此在本文中我们对友好TCP拥塞控制进行了探究，同时总结了几个友好TCP拥塞控制协议，并对这些协议进行了对比。

关键词 TCP；TCP拥塞控制；友好TCP拥塞控制

在网络传输时，数据包丢失可能是由于传输错误造成的，但最常见的原因是拥塞造成的数据包丢失。TCP的端到端拥塞控制机制通过减少网络中允许的未确认数据段的数量来应对数据包丢失。具有相似RTT且共享同一链路的TCP流会降低其速率，因此在理想情况下，带宽可以在它们之间平均分配。
但是并非所有的互联网应用程序都使用TCP，因此这些应用程序不遵循公平共享可用带宽。到目前为止，这些非TCP应用程序的不公平性所带来的不良影响还没有产生重大影响，因为Internet中的大多数流量都使用基于TCP的协议，如超文本传输协议（HTTP）、简单邮件传输协议（SMTP）或文件传输协议（FTP）。然而，音频/视频流应用程序的不断增长，比如视频会议和类似类型的实时应用程序等，这导致了非TCP流量的增加。由于这些应用程序通常不使用与TCP兼容的拥塞控制机制，因此它们以不公平的方式对待竞争的TCP流：在遇到拥塞时，所有竞争的TCP流都会降低其数据速率，以试图消除拥塞，而非TCP流则继续以其原始速率发送。这种极不公平的情况导致TCP流量不足，甚至是拥塞崩溃。因此，需要为非TCP流量定义适当的速率自适应规则和机制。这些速率自适应规则应使非TCP应用程序对TCP友好，使得带宽能够公平分配。
在本文中，我们对友好TCP拥塞控制就行了总结，我们还介绍了几种友好TCP拥塞控制协议，同时我们还对这些协议就行了总结和对比。

1. TCP协议介绍

首先我们对TCP和TCP的拥塞控制机制进行一下简要的介绍。
TCP是传输层中面向连接的单播协议，它提供了可靠的数据传输以及流量和拥塞控制。
TCP的拥塞控制通过维护拥塞窗口，来控制网络中未确认数据包的数量。发送数据会占用发送方窗口中的槽位，并且发送方只能在有空闲槽位时才发送数据包。当接收到未完成数据包的确认消息（ACK）时，发送方窗口移动，空出确认消息对应数据包所占用槽位，以便后面的数据包可以继续发送。
在传输数据时，TCP进行慢速启动，在此期间TCP发送速率大约是两倍的RTT，来快速获得其能够使用的带宽。在稳定状态下，TCP使用AIMD机制来检测额外的带宽并对拥塞做出反应。如果发生数据包丢失，TCP会将拥塞窗口增加1个时隙/RTT；在数据包丢失时，如果是超时指示的数据包丢失，那么拥塞窗口减少到一个槽位，同时TCP重新进入慢速启动阶段；如果是由三个重复ack指示的数据包丢失，那么窗口大小减少到以前大小的一半。

2. TCP友好性

在这个部分我们对TCP友好性进行介绍，这将有利于理解后面的友好TCP拥塞控制。
文献[1]中对TCP友好性的定义为：当“非TCP流的长期吞吐量不超过相同条件下一致TCP连接的吞吐量”时，非TCP流为TCP友好流[1]。
文献[2]中对TCP友好性的定义为：对于单播流，TCP友好性为单播流不会比同一路径上的另一个TCP流在相同网络条件下减少任何共存TCP流的长期吞吐量更多；对于多播流，TCP友好性为对于每个发送方-接收方对，数据流都具有单播TCP流的友好性[2]。文献[2]中对TCP友好的定义侧重于非TCP流对竞争TCP流的影响，而不是对非TCP流的吞吐量的影响。
综上所述，TCP友好性确保数据流中的TCP流不会受到非TCP流的不公平对待。

3. 友好TCP拥塞控制

因为友好TCP拥塞控制有许多类别，我们根据每个类别来对友好TCP拥塞控制进行具体介绍。

3.1 基于窗口和基于速率的拥塞控制

友好TCP拥塞控制可以分为基于窗口的友好TCP拥塞控制和基于速率的友好TCP拥塞控制。
基于窗口调整的拥塞控制在发送方使用拥塞窗口来确保TCP友好性。发送数据时的每个数据包占用拥塞窗口中的一个插槽，接收到数据包的确认消息时释放插槽。只有当空闲插槽可用时，发送方才允许传输数据包。拥塞窗口的大小在没有拥塞指示的情况下增大，在发生拥塞时减小。
基于速率的TCP友好拥塞控制协议通过AIMD来实现TCP的公平性或者根据TCP流量模型调整传输速率。文献[3]介绍了该领域的早期工作，其中该方法用于调整单播视频流的速率，以便对拥塞做出充分反应。

3.2 单播和多播拥塞控制

友好TCP拥塞控制可以分为单播友好TCP拥塞控制和多播友好TCP拥塞控制。
然而，设计一个好的多播拥塞控制协议要比设计单播协议困难得多。理想情况下，多播拥塞控制应该扩展到大型接收器集，并能够应对接收器处的异构网络条件。比如下面这种情况，发送方以相同的速率传输数据包到对应的接收机，必须注意在网络拥塞的情况下如何降低发送速率。这是非常重要的，因为在大型多播会话中，接收器可能会经历不相关的丢失，因此大多数发送的分组很可能丢失给至少一个接收机。如果发送方通过减少拥塞窗口来应对这些损失中的每一个，那么传输可能会在一定时间后停止。这个问题被称为丢失路径多重性问题。当速率调整决策不是基于特定接收器的拥塞信息，而是基于整个分布树中存在的总体拥塞信息时，如果协议设计不正确，则协议性能会受到很大影响。

单速率和多速率拥塞控制

友好TCP拥塞控制可以分为单速率友好TCP拥塞控制和多速率友好TCP拥塞控制。
在单速率友好TCP拥塞控制中，数据以相同的速率发送给接收机。这限制了该机制的可伸缩性，因为所有接收器都被限制为对瓶颈接收器TCP友好的速率。
多速率友好TCP拥塞控制协议可以沿不同网络路径来灵活分配带宽。这样可以更好地扩展到大型接收机集，但是这会导致接收机的异构性增加。多速率友好TCP拥塞控制常用分层多播，通过将发送方将数据分为几层，并将其传输到不同的多播组。每个接收器可以单独选择加入该接收器和发送器之间带宽瓶颈允许的尽可能多的组。加入的组越多，接收器的接收质量也就越好。
对于分层组播，拥塞控制通过底层组播协议的组管理和路由机制间接执行的。为了使这种机制有效，在一个共同的瓶颈后面协调接收方的加入和离开决策是至关重要的：如果只有一些接收方离开一层，而其他接收方保持订阅状态，那么就不可能减少拥塞。此外，当接收器未订阅路由树子部分中已经存在的层时，它们无法有效地使用多播层。他们可以以更高的速率接收数据，而无需额外成本。因此，共享瓶颈链接的接收方应该同步其加入和离开层的决策。但是离开延迟（leave latency）是另一个值得关注的问题：在收到一个层的离开消息时修剪多播树可能需要相当长的时间。

3友好TCP拥塞控制协议

这个部分我们对不同类别的友好TCP拥塞控制中的几个协议进行介绍。

3.1 基于速率的单速率拥塞控制协议

RAP

文献[5]中提出的速率自适应协议（RAP）是一种简单的单播流AIMD方案。由于RAP的速率降低类似于TCP对三重ACK的反应，因此在TCP没有或很少超时的环境中，RAP实现的速率类似于TCP。然而，RAP不考虑超时，因此当TCP的吞吐量由超时事件控制时，RAP更具攻击性。

TFRC

TCP友好速率控制协议（TFRC）[6]是从TFRCP协议演变而来的。它是为单播通信指定的，尽管经过一些修改，它可以适应多播。与TFRCP类似，它根据复杂的TCP方程调整其发送速率，但使用更复杂的方法来收集必要的参数。对损失率估计器提出了若干要求，作者确定了能满足这些要求的平均损失区间法。丢失率是根据丢失间隔来衡量的，覆盖连续丢失事件之间的数据包数。使用衰减权重对一定数量的损失间隔进行平均，以便旧的损失间隔对平均值的贡献较小。损失率计算为平均损失间隔大小的倒数。作者提供了额外的机制，以防止损失率对单一损失事件的反应过于强烈，并确保损失率能够快速适应长时间间隔而不发生任何损失。RTT是通过向发送方反馈时间戳的标准方法来测量的。
TFRC的一个主要优点是，它具有相对稳定的发送速率，同时能对竞争流量提供足够的响应。

TEAR

文献[7]提出的TEAR是一种同时基于窗口和速率的拥塞控制协议。TEAR接收方维护一个类似于TCP的拥塞窗口，同时TEAR接收方计算接收速率，然后发送回发送者，发送者调整发送速率。由于TCP的拥塞窗口位于发送方，TEAR接收方必须尝试从到达的数据包中确定TCP何时增加或减少拥塞窗口大小。由三个重复ACK引起的加性增加和窗口减少易于仿真。但是，由于缺少ACK，只能粗略估计超时事件。
与TCP相比，TEAR协议不直接使用拥塞窗口来确定要发送的数据量，而是计算相应的TCP发送速率。该速率大致相当于每个RTT的拥塞窗口数据量。为了避免TCP的锯齿状速率形状，TEAR计算一轮的平均速率，该速率定义连续速率降低事件之间的时间。为了防止丢失模式中的噪声导致的进一步不必要的速率变化，平滑速率通过使用特定时期的加权平均值来确定最终速率的。然后将该值报告给发送方，发送方相应地调整发送速率。由于速率是在接收机处确定的，并且TEAR避免确认分组，因此它可以用于多播以及单播通信，前提是在多播情况下使用可扩展的方案来确定RTT并报告速率。对于多播拥塞控制，TEAR发送方必须将速率调整到接收方报告的最小速率。
由于对TCP的短期行为进行了细致的建模，TEAR在避免TCP频繁的速率变化的同时，显示了TCP友好的行为。

3.2 基于窗口的单速率拥塞控制协议

TCP很好地覆盖了基于窗口的单播拥塞控制领域。在组播中使用基于窗口的拥塞控制需要解决两个主要问题。首先，协议应该防止由于前面提到的丢失路径多重性问题而导致的速率下降到零。第二个问题是如何释放拥塞窗口中的插槽。发送方不可能从每个接收方接收每个数据包的ACK，这将导致ACK内爆。
Golestani和Sabnani建议使用基于窗口的方法，其中每个接收器保持一个单独的拥塞窗口，该窗口的调整类似于TCP的拥塞窗口[4]。根据窗口的大小和未完成数据包的数量，每个接收器计算出它能够接收的最高序列号，而不要求不公平的带宽量。
需要将此信息传达给发送者，而不会导致反馈内爆。他们证明可以使用接收方或其他中间系统形成的树结构来聚合信息：每个节点获取所有传入消息中包含的最小序列号，并将该序列号转发给其父节点。当聚合信息到达发送方时，允许其发送数据包，最大发送到其接收到的最小序列号。每个接收机都维护自己的拥塞窗口，从而避免了丢失路径的多重性问题。Golestani和Sabnani的观察为基于窗口的组播拥塞控制提供了理论背景。它们需要通过实际的算法来具体化，比如下面的算法。

RLA和LPR

文献[8]中提出的随机侦听算法（RLA）通过引入一些多播增强扩展了TCP选择性ACK（SACK）。对于每个接收方，多播发送方存储平滑的RTT和测量的拥塞概率。发送方通过识别不连续的ACK或超时来检测丢失。基于这些丢失指示，跟踪具有高拥塞概率的接收机n的数目。如果检测到拥塞，则在以下两种情况下窗口将减半：
（1） 如果之前的窗口切割时间太长
（2） 如果生成的均匀随机数小于或等于1/n
当一个数据包已被所有接收方确认时，拥塞窗口cwnd将增加1/cwnd，与TCP相同。RLA中还包括一种具有快速恢复功能的类TCP重传方案。通过上述机制，RLA避免了丢失路径的多重性问题，同时实现了统计上的长期公平性。在文献[8]中，根据有界公平性的定义，证明了RLA对TCP是公平的。
文献[9]提出的线性比例响应（LPR）是一种概率损失指示过滤方案，是对相应RLA机制的改进。多播源减少拥塞窗口大小的概率与接收端的丢失概率成正比；也就是说，当p小于时，窗口大小减半。
其中，Xi是接收机i处的丢失数。与RLA的窗口调整指示方案相比，LPR方案对竞争单播会话实现了更好的多播会话公平性。文献[9]中的数学证明和仿真证明了当与RLA的窗口调整机制相结合时，LPR可以实现良好的TCP友好性。

MTCP

文献[10]中提出的多播TCP（MTCP）是一种可靠的多播协议，它使用基于窗口的拥塞控制来实现TCP友好性。MTCP将会话参与者分组到一个逻辑树结构中，其中树的根是数据的发送者。逻辑树结构中的父结点存储收到的数据包，直到其所有子结点都确认收到为止。在接收到数据包后，子结点使用单播向其父结点发送ACK。
当任何子结点报告三个连续的NACK时，拥塞窗口的大小将减半，或者当发生超时时，拥塞窗口的大小将设置为1，因为子结点根本没有确认数据包。传输窗口跟踪父节点的子节点尚未确认的数据量。
对于每个ACK，父节点都会将拥塞摘要发送给其自己的父节点。此拥塞摘要包含其自身拥堵窗口大小及其子项报告的最小值，以及其自身公交窗口大小及其子项报告的最大值。然后允许发送方传输最小拥塞窗口大小和最大传输窗口大小之间的差值。
在MTCP中，通过在中间节点进行聚合，避免了丢失路径的多重性问题。每个节点将其子节点的瓶颈链接信息转发给其父节点。因此，发送方将接收关于整个瓶颈链路的信息，而不是关于不相关的分组丢失的信息。MTCP的主要缺点是其复杂性和需要设置树结构，其中每个节点必须执行包存储、修复和拥塞监控功能[15]。

3.3 基于速率的多速率拥塞控制协议

Internet中分层多播传输的第一个工作示例之一是用于视频传输的接收器驱动分层多播（RLM）。RLM的重点不是TCP友好性，而是如何根据发送方和接收方之间可用的带宽为每个接收方提供尽可能最佳的视频质量。在RLM中，发送方将视频分为几层。接收器通过监听第一层开始接收。当接收器在一段时间内没有经历以丢包形式出现的拥塞时，它监听下一层。当一个接收器经历数据包丢失时，它会从当前接收的最高层取消监听。
使用RLM来控制拥塞是有问题的，因为RLM基于包丢失检测添加或删除单层的机制不利于TCP，并且可能导致在并发RLM会话之间不公平地分配带宽。此外，离开多播组可能需要大量时间，通常需要几秒钟。因此，失败的加入实验就可能导致的额外拥塞而言，代价非常高昂。为了使分层方案有效，同一链路上的接收方必须同步其加入和离开。

RLC

Vicisano在其关于接收器驱动分层拥塞控制（RLC）的工作中解决了大多数这些问题[12]。他们建议对层进行尺寸标注，以便每个新层所消耗的带宽呈指数级增长。另一方面，当拥塞以分组丢失的形式变得明显时，立即丢弃层。这模拟了TCP的行为，因为带宽的增加与在允许加入层之前通过而不丢失数据包所需的时间成正比。同时，对拥塞的反应是成倍减少，因为丢弃一层会导致总体接收速率减半。
为了改进接收机之间的同步，接收机可以仅在同步点（SP）处加入层。与较低层相比，较高层中的SP的频率呈指数级降低。因此，仅订阅了少量层的接收器可能会赶上订阅级别更高的接收器。一段时间后，共享同一链路的接收器应该同步加入和离开层。
尽管RLC相比于RLM的拥塞控制机制有所改进，但RLC仍存在一些缺点。速率适应网络条件的粒度非常粗糙，可能导致不公平行为。

FLID-DL

文献[13]为了解决RLC的不足，提出了采用动态分层的公平分层增加/减少（FLID-DL）。该协议在源位置使用数字喷泉。使用数字喷泉编码，发送方对原始数据和冗余信息进行编码，以便接收方在收到固定数量的任意但不同的数据包后可以对原始数据进行解码。由于没有必要确保特定数据包的交付，分层方案更加灵活。
FLID-DL引入了动态分层的概念，以减少与添加或删除层相关的连接和离开延迟。使用动态分层，层消耗的带宽会随着时间的推移而减少。因此，接收机必须周期性地加入附加层以保持其接收速率。接收速率仅通过不连接其他层来降低，而速率的提高需要连接多个层。为了减少该机制所需的总层数，在一定时间内没有数据通过层传输的静默期之后，层被重用。
动态分层由FLID方案进行补充，该方案的接收速率对TCP流公平，固定RTT的丢失率相同。FLID保留了RLC关于发送方发起的同步点来协调接收方的概念，但避免了包突发来探测可用带宽。FLID使用概率增加信号，以便接收机仅以一定概率订阅附加层。选择这些概率是为了实现与TCP兼容的速率。
FLID-DL协议是对RLC的重大改进，可以认为是分层拥塞控制的最新技术。它不受长离开延迟的影响，并且在层上的带宽分布方面更加灵活。然而，与RLC一样，FLID-DL不考虑RTT，因此在某些网络条件下表现出对TCP的不公平行为。由于加入和离开决策的发生频率更高，这也会导致底层多播路由协议的主要开销。

3.4 基于窗口的多速率拥塞控制协议

Rainbow

文献[14]中的Rainbow-Rainbow是一种基于窗口的拥塞控制方案，用于可靠传输海量数据。与FLID-DL一样，数据使用数字喷泉进行编码。因此，接收器获得的特定数据包并不重要，重要的是它接收的不同数据包的数量。
Rainbow的关键思想是接收器单独请求传输每个数据包。每个接收者都有一个拥塞窗口，每个请求都有一个标签，该标签基本上指示了请求在拥塞窗口中的位置。如果多个具有相同标签的请求来自不同的接收方，则这些请求由中间路由器累积。此外，路由器存储有关其收到的请求的信息。距离发送方最近的路由器将请求发送给发送方，发送方又根据每个请求发送一个数据包。路由器按照请求的相反方向转发数据包。当数据包被转发到接收方时，路由器会删除有关请求的信息。因此，这种拥塞控制方案在很大程度上依赖于路由器中的额外智能。
接收器中的拥塞窗口模仿TCP拥塞窗口的行为。当数据包到达时，标签落在当前拥塞窗口中，将立即传输新的请求。对于接收到的每个数据包，拥塞窗口大小增加一个（在慢速启动期间），或者在接收到完全拥塞窗口时（在拥塞避免期间），拥塞窗口大小增加一个。当检测到包丢失时，窗口大小减半。
Rainbow允许参与者以不同的速率接收数据。通过对数据进行特殊编码以及每个参与者发送的数据请求，可以实现这种行为。
同时Rainbow有两个主要限制：
（1） 必须能够对数据使用数字喷泉编码。
（2） 路由器必须支持请求的累积和存储。

4. 协议对比

表1 友好TCP拥塞控制协议对比
Table1 Comparison of Friendly TCP Congestion Control Protocol

Protocol	Network support	Protocol complexity	Smooth of the rate	Bias against high RTTS	TCP friendliness
RAP	End-to-end	Low	Sawtooth	Yes	Limited
TFRC	End-to-end	Medium	Smooth	Yes	Good
TEAR	End-to-end	Low	Smooth	Yes	Good
RLA LPR	End-to-end	Low	Sawtooth	Yes	Good
MTCP	End-to-end	Low	Sawtooth	Yes	Good
RLC	Optional	Medium	Sawtooth	Yes	Good
FLID-DL	End-to-end	Medium	Layer-dependent	No	Acceptable
Rainbow	End-to-end	High	Layer-dependent	No	Acceptable

表1显示了这些协议的主要特征。它根据协议是否支持组播以及拥塞控制机制的类型对协议进行分类。端到端工作的协议可以在端节点中完全实现，不需要网络的额外支持。
复杂性评估仅考虑拥塞控制机制的复杂性。协议的总体复杂性还包括网络或数据分层所需的额外复杂性。
速率的平滑度指示该协议是否可用于依赖相对稳定发送速率的应用程序。额定值是指在静态环境下，协议在稳定状态下的行为，并定期丢失。在真实网络环境中，速率的平滑度在很大程度上取决于响应能力以及用于增减机制的特定参数；因此很难预测。通常协议具有“锯齿状”发送速率将显示更多的速率振荡。分层协议的平滑度取决于所使用的层数以及层数之间的带宽分布。大多数分层协议使用的层数相对较少，这导致发送速率的变化很大。TCP吞吐量随RTT的增加而降低。因此，希望符合TCP的协议粗加工必须偏向于高RTT连接。RLC和FLID-DL协议没有表现出这种偏差，因此可能是不公平的。
TCP友好性评估是基于协议作者的评估和理论，例如协议是否考虑了TCP超时，或是否具有比TCP更具攻击性的速率增加。因为目前没有标准化的形式来直接比较TCP友好的拥塞控制方案。因此，这一评估是主观的。评级为“良好”的协议预计不会显示对TCP不公平行为的迹象。评级为“可接受”的协议通常可能显示良好的TCP友好性。

4 总结

本文首先介绍了TCP以及TCP拥塞控制，然后对TCP友好性的定义进行了介绍，对友好TCP的了解有利于后续TCP拥塞控制的理解。在介绍完TCP友好性之后本文对不同类别的友好TCP拥塞控制进行了介绍和对比。同时本文还对每个类别的部分协议就行了详细介绍。最后对这些协议就行了总结和对比。
通过对本文的阅读，读者能够对友好TCP拥塞控制有较深的认识，读者能够根据不同协议的总结和对比在现实场景中选择合适的友好TCP拥塞控制协议。

参考文献
[1] S. Floyd and K. Fall, “Promoting the Use of End-to-end Congestion Control in the Internet,” IEEE/ACM Trans. Net., vol. 7, no. 4, Aug. 1999, pp. 458–72.
[2] J. Widmer, R. Denda, and M. Mauve, “A Survey on TCP-Friendly Congestion Control (Extended Version),” Tech. rep. TR-2001-002, Dept. of Math. and Comp. Sci., Univ. of Mannheim, Feb. 2001.
[3] S. Jacobs and A. Eleftheriadis, “Providing Video Services over Networks Without Quality of Service Guarantees,” W3C Wksp. Real-Time Multimedia and the Web, Oct. 1996.
[4] S. J. Golestani and K. K. Sabnani, “Fundamental Observations on Multicast Congestion Control in the Internet,” Proc. INFOCOM ’99, Mar. 1999, vol. 2, pp. 990–1000.
[5] R. Rejaie, M. Handley, and D. Estrin, “Rap: An End-to-End Rate-Based Congestion Control Mechanism for Realtime Streams in the Internet,” Proc. IEEE INFOCOM, Mar. 1999.
[6] S. Floyd et al., “Equation-based Congestion Control for Unicast Applications,” Proc. ACM SIGCOMM, Stockholm, Sweden, Aug. 2000, pp. 43–56.
[7] I. Rhee, V. Ozdemir, and Y. Yi, “TEAR: TCP Emulation at Receivers - Flow Control for Multimedia Streaming,” Tech. rep., Dept. of Comp. Sci., NCSU, Apr. 2000.
[8] H. A. Wang and M. Schwartz, “Achieving Bounded Fairness for Multicast and TCP Traffic in the Internet,” Proc. ACM SIGCOMM, 1998.
[9] S. Bhattacharyya, D. Towsley, and J. Kurose, “A Novel Loss Indication Filtering Approach for Multicast Congestion Control,” J. Comp. Commun., Special Issue on Multicast, 2000.
[10] I. Rhee, N. Balaguru, and G. Rouskas, “MTCP: Scalable TCP-Like Conges- tion Control for Reliable Multicast,” Proc. IEEE INFOCOM, Mar. 1999, vol. 3, pp. 1265–73.
[11] S. McCanne, V. Jacobson, and M. Vetterli, “Receiver-driven Layered Multi- cast,” Proc. ACM SIGCOMM, Palo Alto, CA, Aug. 1996, pp. 117–30.
[12] L. Vicisano, J. Crowcroft, and L. Rizzo, “TCP-like Congestion Control for Layered Multicast Data Transfer,” Proc. IEEE INFOCOM, Mar. 1998, vol. 3, pp. 996–1003.
[13] J. Byers et al., “FLID-DL: Congestion Control for Layered Multicast,” Proc. 2nd Int’l Wkshp. Networked Group Commun., Palo Alto, CA, Nov. 2000.
[14] K. Yano and S. McCanne, “A Window-based Congestion Control for Reli- able Multicast Based on TCP Dynamics,” Proc. ACM Multimedia, Oct. 2000.
[15] 钟玉琢,向哲,沈洪流媒体和视频服务器北京：清华大学出版社 , 2003.06