软件测试管理

当前位置:首页 > 软件测试管理

《计算机网络:自顶向下方法》第三章 续7

3.6.3网络辅助的拥塞控制例子:ATMABR拥塞控制


我们现在通过个简要的学习案 例来结束本节,该案例是ATM ABR中的拥塞 控制算法,即一种采用网络辅助方法解决拥塞控制的协议。我们强调此时的目的不是详细地描述ATM体系结构的方方面面,而只是为了说明该协议为拥塞控制所采用的方法明显不同于因特网TCP协议的方法。事实上,我们下面仅给出为了理解ABR拥塞控制所需要的ATM体系结构的几个方面。


ATM基本上采用一种面向虚电路(VC)的方法来处理分组交换。回想我们在第1章中的讨论,这意味着从源到目的地路径上的每台交换机将维护有关源到目的地VC的状态。这种逐个VC的状态允许交换机跟踪各个发送方的行为(例如,跟踪它们的平均传输速率),并采取特定源的拥塞控制动作( 例如,当交换机变得拥塞时,向发送方发显式信令以减少它的速率)。网络交换机上的这种逐VC状态使ATM非常适合执行网络辅助拥塞控制。


ABR已被设计成一种弹性数据传输服务,该服务方式使人联想起TCP。当网络轻载时,ABR服务会充分利用空闲的可用带宽;当网络拥塞时,ABR服务会将其传输速率抑制为某些预先确定的最小传输速率。[Jain 1996]提供了一个关于ATM ABR拥塞控制与流量管理的详细学习指南。


图3-50显示了ATM ABR拥塞控制框架。在下面的讨论中,我们将采用ATM的术语(如使用术语交换机而不使用路由器;使用术语信元(cell) 而不使用分组)。对于ATMABR服务,数据信元从源经过一系列中间交换机传输到目的地。在数据信元中夹杂着所谓的资源管理信元( Resource- Management cell, RM信元);这些RM信元可被用来在主机和交换机之间传递与拥塞相关的信息。当一个RM信元到达目的地时,它将被掉转方向并向发送方发送(很可能是在目的地修改了该RM信元的内容之后)。交换机也有可能自己产生一个RM信元,并将该RM信元直接发送给源。因此,RM信元可用来提供直接网络反馈和经由接收方的网络反馈,如图3-50所示。


《计算机网络:自顶向下方法》第三章 续7


ATMABR拥塞控制是“种基于速率的方法。即发送方明确地计算出它所能发送的最大速率,并据此对自己进行相应的调整。ABR 提供三种机制用于从交换机向接收方发送与拥塞相关的信令信息:


●EFCI比特。每个数据信元都包含1比特的显式转发拥塞指示( Explicit ForwardCongestion Indication, EFCI) 比特。某拥塞的网络交换机可把一个数据信元中的EFCI比特设置为1来向目的主机发送网络已经拥塞的信令。其目的地必须检查所有收到的数据信元中的EFCI比特。当一个RM信元到达目的地时,如果多数近来收到的数据信元的EFCI比特都被置为1,则目的地就会将RM信元的拥塞指示比特(CI比特)置为1,并将该RM信元发送回发送方。使用数据信元中的EFCI比特和RM信元中的CI比特,发送方因而能在网络交换机拥塞时得到通知。


●CI和NI比特。如上所述,发送方到接收方的RM信元是夹杂在数据单元当中的。RM信元的夹杂比率是一个可 调参数,默认值是每32个数据信元中有一个 RM信元。这些RM信元中有一个拥塞指示(CongestionIndication,CI)比特和无增长(No Increase, NI) 比特,这两个比特可被一台 拥塞的交换机设置。特别是,交换机可以在轻微拥塞时将经过的RM信元中的NI比特置为1,在严重拥塞时,把CI比特置为1。当目的主机收到一个RM信元时,它将把该RM信元发回给发送方,而保持CI与NI比特不变(除了CI比特也许会因为上面描述的EFCI机制而由目的端置为1之外)。


ER的设置。每一个RM信元还包含一个两字节的显式速率( Explicit Rate, ER )字段。一个拥塞的交换机也许会降低经过的RM信元中ER字段所包含的值。以这种方式,ER字段将被设置为在源至目的地的路径上的所有交换机中的最小可支持速率。


一个ATM ABR源以返回的RM信元中的CI、NI 及ER值为函数,来调整其发送信元的速率。进行速率调整的规则非常复杂而且繁琐,感兴趣的读者可以参考[Jain 1996]以得到详细信息。


3.7 TCP 拥塞控制


在本节中,我们再次来学习TCP。如我们在3.5节所见,TCP为运行在不同主机上的两个进程之间提供了可靠传输服务。TCP 的另一个关键部分就是其拥塞控制机制。如在前一节所指出, TCP必须使用端到端拥塞控制而不是使网络辅助的拥塞控制,因为IP层不向端系统提供显式的网络拥塞反馈。


TCP所采用的方法是让每一个发送方根据所感知到的网络拥塞程度来限制其能向连接发送流量的速率。如果一个TCP发送方感知从它到目的地之间的路径上没什么拥塞,则TCP发送方增加其发送速率;如果发送方感知沿着该路径有拥塞,则发送方就会降低其发送速率。但是这种方法提出了三个问题。第一,一个TCP发送方如何限制它向其连接发送流量的速率呢?第二,一个TCP发送方如何感知从它到目的地之间的路径上存在拥塞呢?第三,当发送方感知到端到端的拥塞时,采用何种算法来改变其发送速率呢?


我们首先分析一下TCP发送方是如何限制向其连接发送流量的。在3.5节中我们看到,TCP连接的每一端都是由一个接收缓存、一个发送缓存和几个变量( LastByteRead、rwnd等)组成。运行在发送方的TCP拥塞控制机制跟踪一个额外的变量,即拥塞窗口(congestion window)。拥塞窗口表示为cewnd,它对一个TCP发送方能向网络中发送流量的速率进行了限制。特别是,在一个发送方中未被确认的数据量不会超过cwnd与rwnd中的最小值,即


LastByteSent一LastByteAcked≤min { cwnd, rwnd}


为了关注拥塞控制(与流量控制形成对比),我们后面假设TCP接收缓存足够大,以至可以忽略接收窗口的限制;因此在发送方中未被确认的数据量仅受限于cwnd。我们还假设发送方总是有数据要发送,即在拥塞窗口中的所有报文段要被发送。


上面的约束限制了发送方中未被确认的数据量,因此间接地限制了发送方的发送速率。为了理解这一点,我们来考虑一个丢包和发送时延均可以忽略不计的连接。因此粗略地讲,在每个往返时间(RTT) 的起始点,上面的限制条件允许发送方向该连接发送ewnd个字节的数据,在该RTT结束时发送方接收对数据的确认报文。因此,该发送方的发送速率大概是ewnd/RTT字节/秒。通过调节cwnd的值,发送方因此能调整它向连接发送数据的速率。


我们接下来考虑TCP发送方是如何感知在它与目的地之间的路径上出现了拥塞的。我们将一个TCP发送方的“丢包事件”定义为:要么出现超时,要么收到来自接收方的3个冗余ACK。(回想我们在3.5.4节有关图3-33中的超时事件的讨论和收到3个冗余ACK后包括快速重传的后继修改。)当出现过度的拥塞时,在沿着这条路径上的一台(或多台)路由器的缓存会溢出,引起-个数据报(包含一个TCP报文段)被丢弃。丢弃的数据报接着会引起发送方的丢包事件( 要么超时或收到3个冗余ACK),发送方就认为在发送方到接收方的路径上出现了拥塞的指示。


考虑了拥塞检测问题后,我们接下来考虑网络没有拥塞这种更为乐观的情况,即没有出现丢包事件的情况。在此情况下,在TCP的发送方将收到对于以前未确认报文段的确认。如我们将看到的那样,TCP将这些确认的到达作为一切正常的指示,即在网络上传输的报文段正被成功地交付给目的地,并使用确认来增加窗口的长度( 及其传输速率)。注意到如果确认以相当慢的速率到达(例如,如果该端到端路径具有高时延或包含一-段低带宽链路),则该拥塞窗口将以相当慢的速率增加。在另一方面,如果确认以高速率到达,则该拥塞窗口将会更为迅速地增大。因为TCP使用确认来触发(或计时)增大它的拥塞窗口长度,TCP被说成是自计时( self clocking)的。


给定调节ewnd值以控制发送速率的机制,关键的问题依然存在: TCP发送方怎样确定它应当发送的速率呢?如果众多TCP发送方总体上发送太快,它们能够拥塞网络,导致我们在图3-48中看到的拥塞崩溃。事实上,为了应对在较早TCP版本下观察到的因特网拥塞崩溃[ Jacobson 1988],研发了该版本的TCP (我们马上将学习它)。然而,如果TCP发送方过于谨慎,发送太慢,它们不能充分利用网络的带宽;这就是说,TCP发送方能够以更高的速率发送而不会使网络拥塞。那么TCP发送方如何确定它们的发送速率,既使得网络不会拥塞,与此同时又能充分利用所有可用的带宽? TCP发送方是显式地协作,或存在一种分布式方法使TCP发送方能够仅基于本地信息设置它们的发送速率? TCP使用下列指导性原则回答这些问题:


●一个丢失的报文段表意味着拥塞,因此当丢失报文段时应当降低TCP发送方的速率。回想在3.5.4节中的讨论,对于给定报文段,一个超时事件或四个确认(一个初始ACK和其后的三个冗余ACK)被解释为跟随该四个ACK的报文段的“丢包事件”的一种隐含的指示。从拥塞控制的观点看,该问题是TCP发送方应当如何减小它的拥塞窗口长度,即减小其发送速率,以应对这种推测的丢包事件。


●一个确认报文段指示该网络正在向接收方交付发送方的报文段,因此,当对先前未确认报文段的确认到达时,能够增加发送方的速率。确认的到达被认为是一切顺利的隐含指示,即报文段正从发送方成功地交付给接收方,因此该网络不拥塞。拥塞窗口长度因此能够增加。


●带宽探测。给定ACK指示源到目的地路径无拥塞,而丢包事件指示路径拥塞,TCP调节其传输速率的策略是增加其速率以响应到达的ACK,除非出现丢包事件,此时才减小传输速率。因此,为探测拥塞开始出现的速率,TCP发送方增加它的传输速率,从该速率后退,进而再次开始探测,看看拥塞开始速率是否发生了变化。TCP发送方的行为也许类似于要求(并得到)越来越多糖果的孩子,直到最后告知他/她“不行!”,孩子后退一点,然后过一会儿再次开始提出请求。注意到网络中没有明确的拥塞状态信令,即ACK和丢包事件充当了隐式信号,并且每个TCP发送方根据异步于其他TCP发送方的本地信息而行动。


1.慢启动


当一条TCP连接开始时,ewnd 的值通常初始置为一个MSS的较小值[ RFC3390],这就使得初始发送速率大约为MSS/RTT。例如,如果MSS=500字节且RTT=200ms,则得到的初始发送速率大约只有20kbps。由于对TCP发送方而言,可用带宽可能比MSS/RTT大得多,TCP发送方希望迅速找到可用带宽的数量。因此,在慢启动(slow-start)状态,cwnd 的值以1个MSS开始并且每当传输的报文段首次被确认就增加1个MSS。在图3-51所示的例子中,TCP向网络发送第一个报文段并等待一个确认。当该确认到达时,TCP发送方将拥塞窗口增加一个MSS,并发送出两个最大长度的报文段。这两个报文段被确认,则发送方对每个确认报文段将拥塞窗口增加-一个MSS,使得拥塞窗口变为4个MSS,并这样下去。这一过程每过一个RTT,发送速率就翻番。因此,TCP发送速率起始慢,但在慢启动阶段以指数增长。


《计算机网络:自顶向下方法》第三章 续7


但是,何时结束这种指数增长呢?慢启动对这个问题提供了几种答案。首先,如果存在一个由超时指示的丢包事件(即拥塞),TCP发送方将ewnd设置为1并重新开始慢启动过程。它还将第二个状态变量的值ssthresh (“慢启动阈值”的速记)设置为ewnd/2,即当检测到拥塞时将shrsh置为拥塞窗口值的一半。慢启动结束的第二种方式是直接与ssthresh的值相关联。因为当检测到拥塞时ssthresh设为ewnd的值一半,当到达或超过ssthresh的值时,继续使ewnd翻番可能有些鲁莽。因此,当cwnd的值等于ssthresh时,结束慢启动并且TCP转移到拥塞避免模式。我们将会看到,当进人拥塞避免模式时,TCP更为谨慎地增加cwnd。最后一种结束慢启动的方式是,如果检测到3个冗余ACK,这时TCP执行一种快速重传(参见3.5.4 节)并进入快速恢复状态,后面将讨论相关内容。慢启动中的TCP行为总结在图3-52中的TCP拥塞控制的FSM描述中。慢启动算法最早源于[ Jacobson 1988];在[Jain 1986]中独立地提出了一种类似于慢启动的方法。


《计算机网络:自顶向下方法》第三章 续7



相关内容

文章评论

表情

共 0 条评论,查看全部
  • 这篇文章还没有收到评论,赶紧来抢沙发吧~