TCP友好拥塞控制机制基础.doc

第一章 引言近年来，Internet上引入大量的实时视频和音频流应用，如视频点播(VOD)、视频广播、视频会议、远程教学、交互式游戏等。丰富的多媒体流应用对用户有很强的吸引力，可以预料，多媒体流应用必然会成为未来网络的主流应用。这类应用的主要特点是：（1）对时延敏感；（2）能容许一定的数据丢失；（3）数据传输本质上是基于速率。目前Internet上大多数多媒体实时业务流一般是基于UDP的。UDP是一种无连接传输协议，在传输媒体流方面要比面向连接的TCP更有优势。UDP不支持拥塞控制，所以这些业务流通常都没有进行端到端拥塞控制，或者说，都不是TCP-friendly。这样的业务流过多出现在Internet上，将对Internet产生严重的负面影响。我们知道，拥塞控制是计算机网络，特别是Internet中的一个重要机制。广泛的研究及实践使人们认识到，如果缺乏有效的拥塞控制机制将会导致严重的后果，如拥塞崩溃1。1986年10月，由于拥塞崩溃的发生，美国LBL到UC Berkeley的数据吞吐量从32Kbps跌落到40bps2。在那之后，人们在拥塞控制领域开展了大量的研究工作。拥塞控制算法对保证Internet的稳定具有十分重要的作用。当今Internet的稳定主要依赖于TCP的端到端拥塞控制机制。TCP使用和式增加积式减少（Additive Increase Multiplicative Decrease, AIMD）基于窗口的拥塞控制机制。这种拥塞控制机制对Internet上传统的尽力（best-effort）型服务如FTP、WWW,具有较好的适应性，但对于当今大量涌现的有实时质量要求的音频和视频流应用却并不适应。这主要是因为在拥塞时速率减半的策略将引起多媒体数据传输速率过大的抖动，会明显降低用户可察觉的质量（user-perceived quality）。因此，按网络拥塞水平适当的调整发送速率更适合发送速率相对稳定（即相对“平滑”，smoothness）、时延抖动受限的多媒体数据流3。一个传输多媒体流的可选方案是利用资源预留（RSVP）4或区分服务（DiffServ）5。但是，即使这些技术能够广泛地推广，仍然会有很大的一个用户群体，他们需要用比较低廉的价格来传输实时多媒体业务，而价格最低廉的服务正是best-effort服务。就算在那些支持RSVP和DiffServ的网络上，在相同服务等级中，各个用户享用资源的权利是平等的，所以他们互相之间还是一种best-effort服务。可见研究用best-effort传输多媒体数据是非常有意义的工作6。本文将从分析目前多媒体流的TCP友好拥塞控制机制研究入手，然后结合多媒体流的本身特点，试图提出一种更加有效的TCP友好拥塞控制机制。1.1 多媒体流的TCP友好拥塞控制机制研究当前的Internet主要是利用没有拥塞控制的UDP传输多媒体业务，文献7对当前最流行的RealNetworks公司的商业流式播放器RealPlayer分别基于UDP和TCP进行了测试，发现诸多使用UDP的好处，包括拥塞时获得更高的平均带宽及更加平滑的播放速率等。但由于UDP没有拥塞控制机制，当基于TCP的应用和基于UDP的应用共享网络资源时，一方面，基于UDP的应用将会占尽所有的带宽，导致带宽分配的严重不公平8,9。而另一方面，TCP又是Internet中的主要传输协议，它占了整个IP包的83% ，并承载了大约90%的Internet通信量10。因此，为保持Internet的稳定，应对基于UDP的应用程序增加拥塞控制机制，并且该机制能够确保UDP和TCP数据流和平友好共处。所以，随着以音视频实时传输为主的多媒体应用在Internet上的广泛开展，“TCP友好”（TCP-friendly）1作为一种新的拥塞控制机制好坏的评价标准，也日益被大家认可。在本文中，TCP友好是指：用best-effort服务传输的多媒体实时流必须与同等条件下的TCP流的吞吐量近似的、平均的相等。1.1.1 TCP友好拥塞控制机制研究最新进展近几年来，研究人员相继提出了许多TCP友好（TCP-friendly）拥塞控制机制1121。这些新的拥塞控制机制的主要目标是试图与基于TCP的应用公平的分享可用带宽。TCP-friendly协议主要分为两类：一类是基于AIMD的，如文献1117等，另一类是基于数学模型的，如文献1821等。AIMD拥塞控制算法最主要特点就是：和式增加积式减小（AIMD）的窗口（速率）调节机制，数学式表示为 （1.1）其中I表示因为在RTT内接收到ACK包而引起窗口增加，D表示遇到拥塞后窗口减小，wt是t时刻窗口的大小，R是RTT，是常数。在GAIMD（General AIMD）16中，主要讨论了这类算法的稳定性和公平性。RAP13机制模仿了TCP的和式增加积式减小的拥塞控制机制。并通过接收方的缓存策略来对吞吐量的抖动进行一定的过滤。但它的速率波动还是比较大，不利于实时多媒体的传输。LDA12机制则利用了目前用于实时流传送的RTP（Real Time Protocol）和RTCP（Real Time Control Protocol）协议来传送网络参数。源端可利用控制包提供的信息计算出丢包率和RTT。TEAR14(TCP Emulation At Receivers)在接收端维持一个类似TCP一样的拥塞窗口，接收端通过到达分组来确定拥塞窗口的增减。接收端维持拥塞窗口的一个指数加权移动平均值，并且将它除以估计的RTT以获得一个TCP友好的发送速率。TEAR基于速率来发送数据。AIMD机制的缺陷在于每个丢包都引起发送速率的减小，对于实时流的控制不是很合适，会造成接收者感受服务质量的降低。因此，如何平滑地调整非响应流的发送速率，使之成为TCP友好的业务流，就成为基于数学建模的控制机制的研究出发点。近年来，人们对TCP流量模型进行了大量的研究。这些模型在一定的参数取值范围很好的解释了TCP的吞吐量。文献22中推导出AIMD(1,1/2)控制下的TCP流量满足 （1.2）其中，s是平均包长，tRTT和p是稳定状态下的RTT和丢包率，tRTO是TCP的重传超时时间。Sally Floyd等人提出的TFRC21（TCP-Friendly Rate Control）机制就是根据这个TCP吞吐量公式来调整服务器端的发送速率，取得了较好的结果。2003年1月，TFRC已正式被IETF工作组接纳，成为RFC3448 23。TFRC机制一方面不像非响应流那样侵略性地抢占可用带宽，而是根据丢失事件率的减小而平滑的增加发送速率；另一方面，它也不会因为单个包的丢失而将速率减半造成抖动，只是在多个连续的丢失事件发生后才减小一半的速率，比较适合实时媒体流的拥塞控制。表1.1 当前的主要TCP友好拥塞控制协议的特性协议单播/多播拥塞控制机制网络支持协议复杂度TCP友好性RAP单播速率端到端低有限LDA(+)单播速率端到端高可接受TFRCP单播速率端到端中等可接受TFRC单播速率端到端中等好LTRC多播速率端到端中等有限TRAM多播速率可选低有限TEAR多播速率端到端低好RLA& LPR多播窗口端到端低好MTCP多播窗口需要低好NCA多播窗口需要中等好PGMCC多播窗口需要中等好另外，文献24对当前TCP友好拥塞控制机制进行了较为全面的概括。表1.1中概况了当前主要的TCP友好拥塞控制机制的特性，主要参照文献24。端到端的机制能完全在端结点上实现，不需要额外的网络支持。注意TCP友好性一栏中，“好”是指对TCP没有不公平的行为，“可接受”指在通常情况下有较好的TCP友好性，但在某些特殊情况下会出问题。“有限”是指在一些比较常见的网络状况下（如高丢失率），对TCP有明显的不公平行为。从表1.1中可以看出，在单播领域中，TFRC机制的TCP友好特性最为突出，且复杂度也不高。TFRC机制体现优势的关键在于采用的TCP吞吐量公式能较为准确的预测可用带宽。基于建模的方法在最近的TCP友好拥塞控制机制设计中被广泛采用，成为一个热门的研究领域，并已扩展到了多播领域，如TFMCC25，也已成为IETF的正式草案26。还值得一提的是，Microsoft公司研究员提出的媒体流TCP友好协议MSTFP27也采用了基于公式（1.2）的方法，这也足见其具有的商业价值。1.1.2 现有机制的缺陷当前的TCP友好拥塞控制研究大多集中在为多媒体流提供一种相对稳定（也就是相对“平滑”，smoothness），且TCP友好的发送速率上。但一种可操作性更好的多媒体流拥塞控制机制，则必然要考虑到多媒体流本身具有的更多约束特性。我们知道，实时多媒体流业务通常只能工作在一定的速率范围之内，即。这是由实时多媒体流业务的编码速率决定的。实时流有一个基本码速相当于Rmin，当网络可用带宽低于这个码速时，业务实际上已经不可用了（不考虑网络中有缓存节点的情况）。在实时流分层编码的情况下，要获得更好的接收质量，就要增大Rcur，但通常情况下分层都有一个上限，也就是码速有一个上限Rmax。这种实时多媒体流特有的速率阈值约束，却常常被TCP友好拥塞控制机制的设计者所忽略，他们或者事先假设网络能够承载最低质量的发送速率，如文献28等，或者只是针对TCP友好性能进行分析，如TFRC等。当然，也有设计者明确考虑到了这种限制，如文献2930等。文献30对路由器RED机制进行加强，对标记的和不标记的流量进行不同的处理，并结合端到端的控制机制，从而支持多媒体流的最少带宽保证。这种基于路由器的方法成本比较高，目前的因特网还无法在很大范围内支持这类方法。而文献29则在时采取最简单的做法：将降为0，即发送方停止发送数据。这种方法比较脆弱，当遇到一个较大的突发拥塞时，就会造成数据流停止发送，即使这种突发拥塞只持续很短的时间。基于以上的考虑，我们认为，如何在TCP-friendly与最低发送速率阈值之间做出适当的权衡策略，提出一种端到端的多媒体流拥塞控制机制，具有一定的研究价值及现实意义。1.2 实验平台：网络模拟器ns-2由于本文的所有实验都是在网络模拟器ns-2上完成，本节将对ns-2作简要的介绍。1.2.1网络模拟器的动机与历史随着互联网的快速成长，发展出许多新的网络协议。在早期，当新的算法或协议设计完成时，研究人员多借用实验或数学建模的方式，来验证其正确性及性能。但现在的网络环境越来越复杂，构建一个实验环境变得相当昂贵，而且这个环境很可能不能运用在下个实验中，更不能为全球研究人员共享；而以数学建模的方式常常因复杂度过高而难以分析，所以将新的算法以模拟的方式来验证，是目前较常用的方法。另一种情况是，在要架设一个新的网络环境之前，必须事先评估网络的拓扑及带宽是否能满足需求，这时也需要有一套网络模拟软件，事先模拟各种不同的网络环境，作为决策的参考。目前已有许多的网络模拟器，商业软件有OPNET31，BONeS32，COMNET 33，尤其OPNET的支持度相当广泛，几乎包含所有现行网络标准，但需要百万元以上，非常昂贵。而本文实验采用的NS。表1.2给出ns主要内建模块一览。表1.2 ns内建模块一览ns-2应用层HTTP,FTP,CBR,Telnet,On/Off Source传输层UDP,TCP(Reno,Newreno,Sack1,Vegas,Fack,Asym),RTP,SRM,RLM,PLM路由协议Session Routing,DV Routing,DM,Shared tree mode网络层IP数链层CSMA/CD,CSMA/CA,802.11,TDMA,MultihopNS在应用层的支持度较少，但支持的TCP版本相当齐全，而且NS开放源码，可以任意的增加修改自己想要的功能，所以研究人员一般都使用NS作为模拟平台，并且将最新的研究成果提供给NS，所以NS版本的更新速度很快，它包含有许多最新提出的协议，很适合研究工作的开展。NS的前身是Real（Realistic and Large）34，而REAL是由NEST（Network Simulation Testbed）35发展而来。目前NS几乎每天都有更新，在/nsnam/ns/CHANGES.html 可以看到整个修改的log，了解最新的功能。目前ns及内附的nam是VINT（Virual InterNetwork Testbed）计划36的一部分。该计划是由DARPA赞助，目的在提供完整、趋于真实的网络模拟环境。发展至今，ns支持大部分的Unix平台（包括Linux，FreeBSD等），还有Windows。目前最新的allinone版本是ns-allinone-2.26。ns v2.01996ns 2.26 2003ns v1.01995REAL1989NEST1988图1.2 ns演进史1.2.2 ns的运作机制ns的特色在于使用两种编程语言的架构，一些比较底层的工作，例如事件的处理、分组的转发，这些事情需要较高的处理速度，而且一旦完成就很少需要修改，所以使用C+是最佳的选择。另一方面，在做实验时，常需要设定不同的网络环境、动态调整协议的参数，这些事情使用像Tcl这类的解释性脚本语言将会有较佳的弹性。ns使用的是MIT发展的Otcl（Object Tcl）作为描述、配置、执行模拟的语言，Otcl是Tcl的面向对象的扩展版本。NS透过tclcl来连接两种语言之间的变量及对象，在两种语言的特性互补下，使得NS成为兼具高效和弹性的网络模拟器。因此，我们的研究基于该平台，所有的实验都是在最新的版本ns-allinone-2.26上完成。1.3本文工作及结构本文重点研究多媒体流的TCP友好拥塞控制机制，主要工作归结如下：（1）对目前存在的多媒体流TCP友好拥塞控制机制进行深入研究与分析。（2）对TCP友好速率控制机制（TFRC）进行研究，针对其不适应于多媒体流的最低速率阈值特性进行改进，提出一种基于阈值限定的TCP友好速率控制机制TCRC(Threshold Constrained Rate Control)。该机制引入了最低发送速率阈值限定和暂态计时器技术，有效地解决了TFRC协议在短暂拥塞时出现的不适用于媒体流应用的问题，同时又保证TCRC不会加重持续拥塞，保持全局的TCP友好，从而使媒体流应用不会受到暂时性拥塞的干扰，实现其低优先级服务。（3）对提出的TCRC机制进行改进，引入基于概率的随机试验技术，以保证MTCRC流在多路复用时，通过对部分MTCRC流的挂起，从而使MTCRC流的平均吞吐量仍保持TCP友好。该机制在低丢失率的链路中，MTCRC协议和TFRC协议都具有很好的TCP友好性；在高丢失率的链路中，MTCRC比TFRC具有更好的TCP友好性；在不稳定的链路环境中，MTCRC的性能优于TFRC；MTCRC流能保证运行时的发送速率始终在最低速率阈值以上，从而保持多媒体流的可用性。（4）利用网络模拟器ns-2进行模拟，并评估实验结果。本文共分5章，结构如下：第一章 引言 包括当前多媒体流拥塞控制机制的发展概况，网络模拟器的介绍，本文所做的主要工作；第二章 TCP友好拥塞控制机制基础 包括对TCP协议的描述，TCP友好的概念，现有的几种典型TCP友好拥塞控制机制，TCP吞吐量建模理论；第三章 基于阈值限定的拥塞控制机制(TCRC) 包括TFRC机制及其缺陷，TCRC机制的详细描述，及模拟试验，TCRC的扩展；第四章 一种基于多路复用的TCRC改进机制(MTCRC) 包括相关工作介绍，MTCRC机制的详细描述，模拟试验，MTCRC的可能扩展；最后为结论，总结全文的工作，并对未来工作提出设想。第二章 TCP友好拥塞控制机制基础TCP 37, 38（Transmission Control Protocol）是一个面向连接的单播传输协议，用于为大多数的Internet应用传输数据，如Web浏览器，email，FTP。它是Internet上最广泛使用的传输协议。试图运用在Internet上的其他拥塞控制机制，不得不在一个TCP拥塞控制占统治地位的环境中工作，他们应该保持对TCP流的友好性。在本章中，首先简要描述TCP协议，及TCP友好（TCP-friendliness）的概念，然后对现有的TCP友好拥塞控制机制进行分类，再介绍目前的一些典型TCP友好拥塞控制机制，最后讨论当前具有代表性的基于建模的机制的理论基础：TCP吞吐量的建模方法。2.1 TCP协议描述TCP用于传输从一个端主机到另一个端主机的字节流。因为底层的路由协议只提供数据包的路由，所以字节流不得不分成数据段放入单个的包中。在开始传输数据之前，TCP在通信的端主机之间建立一条全双工连接。数据段在TCP接收端确认以保证端到端的可靠性。如果在TCP之下的网络层出现丢包，这种丢失行为会通过缺失的确认信息察觉出来，然后丢失的数据将由TCP发送方进行重传。为增加可靠性，TCP通过使用滑动窗口来提供拥塞控制（congestion control）和流控制（flow control）。流控制是数据的接收方调节发送方的传输速率的一种机制，以便使数据不要到达太快以至于来不及处理。同时，拥塞控制防止发送方发出的数据超出网络的容量。下面详细介绍TCP的拥塞控制机制，主要参考文献24。TCP发送方用拥塞窗口来控制网络中明显未确认数据包的数目，即给定时间内允许发送的数据量。当发现拥塞，拥塞窗口减小，而没有拥塞时，窗口增大。在未收到接收方的ACK之前，TCP发送方只会按最小的流控制窗口和拥塞窗口传输分组。一开始，TCP通过一个慢启动（slow-start）过程迅速达到一个公平的网络可用带宽值，而不会向网络发送过多的数据包。在慢启动期间，每个确认使拥塞窗口尺寸翻一倍（指数增长）。在达到一个特定的窗口尺寸阈值或发现第一个丢包2时，慢启动过程结束。在慢启动阶段之后，TCP开始使用和式增加积式减小（AIMD）机制探测额外的可用带宽，并对以丢包为标识的拥塞敏感。一旦收到ACK，TCP发送方就将拥塞窗口以每个RTT内大约一个分组的速度增长。如果一个数据分组在一个重传超时值的时间跨度内没有得到接收方确认，发送方即认为出现了严重的拥塞，则拥塞窗口将会降为1， 并且未被确认的分组将被重传。TCP又重新进入慢启动阶段。重传超时值对TCP性能的影响极大，因此它会在每个RTT中不断地调整以适应变化。另外，超时是用来探测丢包的另一种机制。一旦有分组到达，TCP接收方就会确认按序最后达到的分段，如果中间有分段丢失，则接收方会在有新分段到达时确认丢失分段之前的分段。因此，分组丢失和分组重排序会导致重复确认。对同一序号的四个确认，称为三重ACK（TDACK），这是一种很强的信号，指示有一个或更多的分段丢失。因此，发送方将拥塞窗口减半，并开始重传被认为是已丢失的数据段。自从TCP第一个版本的实现，到现在，TCP已经经历了多次改良。今天，TCP不同的版本都在使用着，其中最广泛应用的是TCP Reno 和 TCP Sack。关于这些TCP版本的性能比较及差异，可以参看文献39。2.2 TCP友好（TCP-friendliness）因为目前的Internet上的主要业务都是基于TCP的，例如，E-mail，FTP，Web等，为了满足协议之间的公平性要求，多媒体流的传输协议必须使自己的业务流的吞吐量与TCP大致相等，如此就出现了TCP-friendly的概念。在文献1中，TCP友好的定义如下：如果长时间（long-term）内一个非TCP流的吞吐量不超过在相同网络条件下同一路径上的一条与之并存的TCP流的吞吐量，则该非TCP流是TCP友好的。在文24中，作者给出了一个稍微不同的TCP友好定义（针对单播流）：当对任意一条与之并存的TCP流，一个单播流所造成的长时间吞吐量下降并不比在在相同网络条件下同一路径上的一条TCP流作造成的下降更大，则认为该单播流是TCP友好的。显然，第二个定义具有更多的限制性。定义中的吞吐量强调的是一个非TCP流与TCP流竞争而不是与非TCP流竞争时的吞吐量。当然，这只是从公平性的角度来定义的。作为一个性能良好的多媒体流传输协议，也要考虑到多媒体流本身的特点。如果满足了这两个要求，那么这种TCP友好传输协议就是一种理想的多媒体传输方案。2.3 TCP友好拥塞控制机制分类在最近几年中，提出了一些新的拥塞控制方案，例如TFRC21，TEAR14，用来支持那些不能利用TCP进行传输的应用。典型的例子是诸如Internet上传输音频及视频的媒体流应用。这些拥塞控制方案的一个主要目标就是试图以一种公平的方式与那些基于TCP的应用分享可用带宽，因而称它们为TCP-友好（TCP-friendly）的拥塞控制机制。TCP友好拥塞控制机制可按照众多特征分类。下面按文24中的方法进行分类。2.3.1 基于窗口与基于速率基于窗口（window-based）的机制通过调整一个拥塞窗口来适应性的改变它提供的网络载荷以保证TCP友好，这类似于TCP的拥控机制。而基于速率（rate-based）的机制通过动态的调整传输速率以适应某个指示拥塞的网络反馈机制，来达到TCP友好。后者有可细分为简单的AIMD机制和基于模型的控制机制。简单的AIMD机制模仿TCP拥塞控制的行为，其结果在速率上也如TCP一样表现为典型的短期锯齿形态。这导致简单的AIMD机制对于连续媒体流是不合适的。而基于模型的拥塞控制使用2.5.2节中介绍的TCP模型来估计长时间（long-term）内的TCP吞吐量，并将发送速率调整到该估计值。基于模型的拥塞控制能产生更加平滑的速率改变，更适于媒体流应用。这种方案不会模仿TCP短期的发送速率，但在长时间内能保持TCP友好。基于速率的机制强调的是通过直接对速率的调控来保证与TCP流或其他流公平的竞争，所以这种拥塞控制机制也可直接称为速率控制机制。2.3.2 单播与多播单播和多播都应该保证TCP友好。然而，设计一种好的多播拥塞控制协议的难度远远大于设计单播协议。理想的多播拥塞控制方案应该能扩展到很大的接收用户群中，并且应该能够适应接收方的网络异构条件。例如，如果对所有的接收方，发送方都用相同的速率发送，那必须考虑在网络拥塞时，如何降低发送速率。这是很重要的，因为在大型多播会话中，接收方可能会出现不相关的丢失。因而发送方会探测到大量的传输分组的丢失，他们至少是在一个接收方上丢失的。如果发送方对每个丢失都以降低拥塞窗口响应，那么在某一时间段后，传输将会停止。这个问题称之为loss path multiplicity problem 40。不论何时，速率调整都不能基于某一个接收方反馈的拥塞信息，它应是基于整个接收分布树上的全局拥塞信息。如果协议没设计好，其性能会变得非常糟糕。2.3.3 端到端与路由器支持 许多TCP友好方案都是为尽力服务的网络设计，这样的网络不提供额外的路由器上的机制来支持协议。因此，他们能很方便的部署在今天的Internet上。这些方案称为端到端的拥塞控制。他们又可分为基于发送方(Sender-Based）和基于接收方(Receiver-Based)的方法。在基于发送方的方法中，发送方利用反馈的网络拥塞信息来调整速率或窗口尺寸，以达到TCP友好。接收方只提供反馈，调整速率的责任全落在发送方的身上。基于接收方的拥塞控制通常与分层的拥塞控制方法一并使用。接收方决定是否加入或离开一个层次，这基于网络的拥塞状况。通过在网络中设置智能（如，在路由器中或单独的代理中），可为拥塞控制协议的设计，特别是资源的公平共享，带来很大的方便。端到端机制的缺点在于，它依赖于端系统之间的协作。而目前Internet中的实验表明：贪婪的用户和应用程序可能会使用非TCP友好的机制以获得更大的带宽，这种情况是估计不到的。所以有人提出了依赖于网络中额外功能的拥塞控制方案，被称为路由器支持的拥塞控制。正如Floyd和Fall在文1中所说，拥塞控制的一些形式应该在路由器中得到加强，以防止拥塞崩溃。作者给出了一些路由器的机制以识别应该被约束的流：例如，当路由器发现一个流存在非TCP友好的行为，路由器能以一个比TCP友好流更高的概率丢弃这个流的分组。只有通过路由器支持，非响应流或非TCP友好流才能最终达到资源的公平共享，然而这种机制很难利用开来，因为对Internet架构的改变非常耗时，而且要花费大量的金钱和努力。2.4 典型的TCP友好拥塞控制机制下面介绍的四种典型机制中，前三种机制（RAP，TEAR，TFRC）要求流所占用的带宽能适应性地随着网络的拥塞程度的变化而调整；而后一种机制（PCC）针对的是非适应流41，这种流的发送速率由应用决定，不能随着随着网络的拥塞程度的变化而调整。2.4.1 RAPRAP协议13的主要部分是在源端实现的。RAP源发送带有序列号的数据包，RAP接收端确认每一个数据包，这样就提供了端到端的每包反馈机制。它是一种基于速率的拥塞控制方法。如果没有探测到拥塞，周期地增加传输速率，如果发现了拥塞，马上减少传输速率。RAP为了减低发送速率的剧烈波动，使用了一个精细增益速率适配算法，在一定程度上平滑了发送速率。使用了每包确认机制，这对于多媒体流是没有必要的,而且加重了网络的负荷,尤其不适应不对称网络和组播。它的速率波动还是比较大，不利于实时多媒体流的传输。2.4.2 TEARTEAR(TCP Emulation At Receivers)14 是一种混合式端到端协议，它结合了基于窗口和基于速率拥塞控制的特点。TEAR在接收端维持一个类似TCP一样的拥塞窗口，而TCP的拥塞窗口设置在发送端。TEAR接收端通过到达分组来确定拥塞窗口的增减。不同于TCP，TEAR 协议不会直接使用拥塞窗口来确定发送数据的数量，而是计算出其相应的TCP发送速率，再基于速率来发送数据。接收方维持拥塞窗口的一个指数加权移动平均值，并且将它除以估计的RTT以获得一个TCP友好的发送速率。由于TEAR较为近似的模拟了TCP的短时间行为，所以它在避免类似TCP的速率频繁抖动的同时，也表示出了TCP友好特性。2.4.3 TFRCTCP友好速率控制协议（TFRC）21从TFRCP协议20发展而来。这个基于速率的机制是针对单播通信的，它根据复杂TCP吞吐量公式42来调整其发送速率。作者选择平均丢失间隙法来估计公式用到的丢失率。这种丢失率通过测量丢失间隙获得。对一定数量的丢失间隔取加权平均，从而使较早的丢失间隔对平均值的贡献较小。对平均丢失间隔取倒数，就得到丢失率。而往返时间的测量则是通过标准的时间戳反馈方式计算得到。接收方每个RTT时间向发送方反馈报告一次。发送方利用参数计算出新的友好速率，并相应的对当前速率进行调整。在启动之后，发送方立刻进入类似于TCP的慢启动过程，从而迅速的增加速率以达到公平带宽值。当遇到第一个丢失事件时，慢启动过程结束。这种基于发送方的方法可以转换成基于接收方的方式。TFRC一方面不像非响应流那样侵略性地抢占可用带宽，而是根据丢失事件率的减小而平滑的增加发送速率；另一方面，它也不会因为单个包的丢失而将速率减半造成抖动，只是在多个连续的丢失事件发生后才减小一半的速率， 比较适合媒体流的拥塞控制。2.4.4 PCCPCC(Probabilistic Congestion Control)41是一种针对非适应流（non-adaptable）的基于速率端到端拥塞控制机制，它不需要路由器及其他网络中间设备的支持。目前的PCC机制基于接收方，并只能用于单播。文献41首次提出“非适应流”的概念：一个数据流的发送速率是由应用决定，且不能随网络拥塞程度的变化而调整。它只有两种可接受的状态：一是on状态，按应用确定的速率传输数据；一是off状态，意味着完全没有数据传输。非适应流的典型例子如网络游戏中产生的流。目前存在的TCP友好拥塞控制机制，都要求流所占带宽能随着网络状况适应性的调整。显然非适应流无法利用这些拥塞控制机制。PCC针对非适应流，采取这样一种方式：它“部分的”（partly）允许一个流传输，并且持续的调整流的数目以适应于网络状况。PCC机制的观点是：只要达到高度的统计多路复用（multiplexing），则单个的非适应流在某一时间点上是否TCP友好并不重要，重要的是在给定链路中的所有非适应流的集合（aggregation）是否TCP友好。另外，在相同网络条件下，所有PCC流产生的流量在某一给定时间点上要与相同数目的TCP流产生的流量基本相等。如果能满足多路复用的要求，每个PCC流就会有一个期望的平均TCP友好速率。PCC试图在恰当的时刻挂起流，已使多个非适应流的集合的行为是TCP友好的。如何决定流的挂起是基于一个由概率决定的随机试验。PCC机制中的概率算法会在本文第四章提出的MTCRC机制中用到，所以将在第四章中详细介绍。2.4.5 典型机制的比较文献21,43,44中，研究人员通过模拟实验分析证明：GAIMD和RAP协议的各项性能（包括平滑性，公平性等）明显低于TFRC（我们的仿真结果也证明了这一点），而TEAR的性能与TFRC相当，但TEAR协议较为复杂。文献45证明了TFRC在长时间(long-run)内的TCP-friendly性。文献24对当前TCP友好拥塞控制机制进行了较为全面的概括，对各种机制的TCP友好性进行了评估（见引言中表1.1），其中 TFRC机制的TCP友好特性最为突出，而且复杂度也不高。TFRC机制体现优势的关键在于采用的TCP吞吐量公式能较为准确的预测可用带宽。基于建模的方法在最近的TCP友好拥塞控制机制设计中被广泛采用，成为一个热门的研究领域。2.5 TCP吞吐量建模上节介绍的基于公式的拥塞控制机制是目前最受人关注的一类控制机制。如其中的TFRC机制，在2003年3月正式成为RFC3448。TFRC机制采用的公式来自于由Padhye等人提出的一个TCP吞吐量模型42。TFRC机制优良的TCP友好特性正是得益于该模型对TCP协议行为的精确刻划。由于本文后面提出的TCRC及MTCRC机制中也运用了这个模型得出的公式，所以下面将对TCP吞吐量的建模方法进行较为详细的介绍。90年代末，在文献4647中，研究者开始将一个有大量数据传输的TCP流的发送速率分析描述为丢包和RTT的函数。激励这项研究的原因之一是，在一个给定的环境中将TCP发送速率进行简单的量化描述，为一个与TCP流竞争的非TCP流提供了一种定义其TCP-friendly的发送速率的方法。TCP吞吐量主要依赖于往返时间tRTT，重传超时值tRTO，及包尺寸s，和丢包率p。使用这些参数，能得出一个TCP吞吐量的估计值。2.5.1 基础模型文献1给出了一个能得到TCP稳态吞吐量上界的的基本模型。其中假定丢包是定期的，每1/p时间内丢失一个包，并且每次发生丢包时，拥塞窗口尺寸都为W，丢包导致窗口减半，变为W/2，在下一个1/p时间内，不会发生其他的丢包，在这段时间期间，拥塞窗口每个RTT时间增加一个数据包。在W/2个RTT时间后，拥塞窗口又重新达到W，在经历一个增加下降的周期（即连续两次丢包之间）中，TCP发送方至少发送了 （2.1）个包。因为这完全是在一个丢包周期内发生，所以丢包率和窗口尺寸关系可表示如下： （2.2）TCP吞吐量RTCP则可用该周期内传输的数据总数除以周期长度得到： （2.3）如果每个数据包都产生一个ACK回应包，在目前的实现当中，吞吐量只有 （2.4）该模型的缺陷是：没有考虑由于等待重传计时器超时造成的TCP延迟。因此，当拥塞窗口小于4个包且出现丢包时，公式（2.3）过高估计了稳态下的带宽。从公式（2.2）可以看出，即当丢包率大于等于16%时，会发生这种情况。（如果拥塞窗口是4或更大时，TCP连接才可能收到三个重复的确认信息，从而利用快速重传（Fast Retransmit）恢复。当拥塞窗口小于4时，TCP连接通常只能等待一个重传超时39。）在更加特殊的情况下，譬如丢包率达到100%, 则此稳态模型会假定TCP连接仍保持每个RTT时间内发送一个包，并且公式(2.3)（因为它应用了公式（2.1）的一个近似值）得出的TCP发送速率会稍微大于1包/RTT。如果在模型中增加对重传计时器的考虑，会得到一个更加现实的结果。文42中给出了这样一个更加复杂的模型，如下所述。2.5.2 考虑超时重传的复杂模型有别于先前的模型，超时重传的复杂模型考虑了由于TCP超时造成的速率下降，它更加准确地描述了具有高丢包率的网络环境。（2.5）其中，b表示每个ACK包确认的数据包数，Wm表示拥塞窗口的最大尺寸。对于大多数的应用，可以忽略Wm造成的影响，并将，b = 1，则公式可以表示为下面的近似形式：（2.6）在文献42中，作者指出该模型有待改进的地方：l 应考虑快速恢复和快速重传的影响；l 模型假定在一个给定的往返过程中一旦有一个分组丢失，则往返过程中的其他分组也都丢失，这种假设是不严格的，模型可被修改以符合一个丢失分布函数；l 还应考虑在慢链路中TCP的行为，如modem链路中。另外，文献48中指出，在一个典型的TCP连接中，快速重传技术可以消除大约一半的粗粒度超时，从而使吞吐量提高大约20%左右。从这一点上看，该模型忽略对快速重传的考虑，会使计算出的TCP吞吐量偏低。2.5.3 两个模型的对比图2.1 简单（SQRT）模型和复杂（PFTK）模型的对比文献49对两个模型进行了对比，如图2.1所示。在低丢失率的情况下，以包数/RTT为单位进行吞吐量的比较，复杂模型和简单模型的结果相似；而在高丢失率的情况下，复杂模型的吞吐量下降得更快。在一个高度拥塞的网络环境中，几乎所有的TCP拥塞窗口减小都是由超时造成的。因此，复杂模型在这种条件下，对TCP行为的描述更加准确。2.6 小结本章介绍了TCP友好拥塞控制机制的一些基础知识，包括TCP协议、TCP友好、现有的TCP友好机制的分类，通过对现有的几种典型TCP友好拥塞控制机制的分析比较，发现这些机制中基于建模的机制（如TFRC）的各项性能优于其他机制，最后介绍了基于建模的TCP友好拥塞控制机制的理论基础，即TCP吞吐量模型，为下一章在TFRC机制的基础上提出改进机制奠定了理论基础。参考文献1 Floyd S, Fall K. Promoting the use of end-to-end congestion control in the Internet. In: IEEE/ACM Transactions on Networking, 1999, 7(4): 4584722Jacobson V. Congestion avoidance and control. In: Proc. of ACM SIGCOMM. Stanford, California, 1988, 18(4):314-3293 罗万明，林闯，阎保平. 一种支持多媒体通信QoS的拥塞控制机制.电子学报，2000，28(11):48-52 4Braden B, Zhang L. Resource ReSerVation protocol (RSVP)-version 1 message processing rules. RFC 2209, IETF, 1997 5 Blake S, Black D, Carlson M, et al. An architecture for differentiated service. RFC 2475, IETF, 19986胡严，张光昭，张国清. RAAR:多媒体流在Internet上传输的一种TCP-Friendly拥塞控制机制. 计算机学报，2003，26(4):427-437 7Chung J, Zhu Y, Claypool M. FairPlayer or FoulPlayer?-Head to Head Performance of RealPlayer Streaming Video Over UDP versus TCP. WPI-CS-TR-02-17, /chung02fairplayer.html, 20028 Braden B, Clark D, Crowcroft J, et al. Recommendations on queue management and congestion avoidance in the Internet. IETF RFC 2309, 19989Floyd S, Fall K. Router mechanisms to support end-to-end congestion control. /papers/collapse.ps , LBL-Berkeley, 199710 McCreary S, Claffy K. Trends in wide area IP traffic patterns: A view from AMES internet exchange. In: Proc. of 13th ITC Specialist Seminar, 2000, 11111 Jacobs S, Eleftheriadis A. Providing video services over networks without quality of service guarantees. In: Proc. of World Wide Web Consortium Workshop on Real-Time Multimedia and the Web, Sophia Antipolis, France,199612 Sisalem D, Schulzrinne H. The loss-delay based adjustment algorithm: a TCP-friendly adaptation scheme. In: Proc. of NOSSDAV, Cambridge, UK, 1998, 215-22613 Rejaie R, Handley M, Estrin D. RAP: An End-to-End Rate-based Congestion Control Mechanism for Realtime Streams in the Internet. In: Proc. of IEEE INFOCOM, New York, NY, 1999, 1337-134514 Rhee I, Ozdemir V, Yi Y. TEAR: TCP emulation at receivers - flow control for multimedia streaming. Technical report, NCSU, 200015 Sisalem D, Wolisz A. LDA+ TCP-friendly adaptation: A measurement and comparison study. In: Proc. of NOSSDAV, Chapel Hill, NC, 2000, 1619-162216 Yang Y, Lam S. General AIMD congestion control. In: Proc. of IEEE ICNP 2000, Osaka, Japan, 200017 Bansal D, Balakrishnan H. Binomial congestion control algorithms. In: Proc. of IEEE INFOCOM. Alaska, 2001, 631-64018 Mahdavi J, Floyd S. TCP-friendly Unicast Rate-based Flow Control. /networking/papers/tcp_friendly.html, 1997-0119Turletti T, Parisis S, Bolot J. Experiments with a layered transmission scheme over the Internet. INRIA Research Report No. 3296, Sophia Antipolis, France, 1997 20Padhye J, Kurose D, Towsley R, et al. A model based TCP-friendly rate control protocol. In: Proc. of IEEE NOSSDAV99, Basking Ridge, New Jersey, 1999, 137-15121Floyd S, Handley M, Padhye J, et al. Equation-based congestion control for unicast application. In: Proc. of ACM SIGCOMM. Sweden, 2000, 43-5622Padhye J, Firoiu V, Towsley D, et al. Modeling TCP throughput: A simple model and its empirical validation. In: Proc. of