各种TCP版本 之 TCP Reno 与 TCP Vegas 共存

实验目的

    探讨TCP Vegas的提出，TCP Vegas的内涵 ，TCP Vegas 的优越性及其没有在Internet上广泛应用的主要原因。

基础知识回顾

【TCP Reno 性能分析】

    前面，我们了解了TCP Tahoe、TCP Reno系列及TCP Sack的工作原理，通过实验，将各种TCP版本进行了对比。综合来看，即使源端不通过等待超时来恢复一个窗口数据中丢失的包，Reno和New-Reno在一个RTT（Round Trip Time）内至多也只能重传一个被丢弃的包。SACK使用“管道”（pipe）变量表示在发送路径上损失的数据包的数量。Reno 优于Tahoe，New-Reno和SACK则优于Tahoe和Reno。由于SACK不像New-Reno一次全部重传已发送包，而是有选择地重传，因此在一个窗口中出现数据包大量丢失时，SACK的性能优于New-Reno，但SACK的最大缺点在于要修改TCP协议。

    其中，Reno是目前应用最广泛且较为成熟的算法。我们现在对Reno算法做一个简单的性能分析。优点：公平性方面，据数据统计，Reno的公平性还是得到了相当的肯定，它能够在较大的网络范围内理想地维持公平性原则。缺点：1.从Reno运行机制中很容易看出，为了维持一个动态平衡，必须周期性地产生一定量的丢失；2. AIMD（Additive-Increase，Multiplicative-Decrease，减少快，增长慢）机制限制了Reno的吞吐量；3.在大窗口环境下，由于一个数据包的丢失所带来的窗口缩小要花费很长的时间来恢复。因此，带宽利用率不可能很高且随着网络的链路带宽不断提升，这种弊端将越来越明显。

基于上述原因，TCP Vegas 应运而生。

【TCP Vegas 简介】

   Brakmo和Peterson在1995年提出了一种是用RTT测量网络状况的拥塞控制算法，称之为TCP Vegas。首先，我们来解释一下RTT的概念：RTT（Round Trip Time，回路响应时间）指一个TCP数据包从源端发送到接收端，源端收到接收端确认的时间间隔。Vegas就是通过观察以前的TCP连接中RTT值的改变情况来控制拥塞窗口cwnd。如果发现RTT变大，那么Vegas就认为网络发生拥塞，并开始减小cwnd；如果RTT变小，Vegas则解除拥塞，再次增加cwnd。这样，cwnd在理想情况下就会稳定在一个合适的值上。这样做的最大好处在于拥塞机制的触发只与RTT的改变有关，而与包的具体传输时延无关。由于它没有采用包丢失来判断网络可用带宽，而改以用RTT的改变来判断，所以能较好地预测网络带宽使用情况，并且对小缓存的适应性较强，其公平性、效率都较好。

Vegas使用了3个方法以增加传送的吞吐量（throughput）、减少数据包的丢失。下面分别进行介绍：

1.新的重送机制（New Retransmission Mechanism）

 当一个数据包被目的端接收时，目的端会根据收到的数据包序号返回一个ACK（ackonwledge）表示这个数据包已收到；如果收到非连续的数据包，则返回序号相同的ACK（Duplicate ACK，重复ACK）。TCP会根据数据包被送出及返回的时间计算数据包平均传送时间RTT。

TCP利用两种方法来检测是否有数据包丢失并重送丢失的数据包。首先，当一个数据包被送出时，TCP记录此数据包被送出的时间，并检查此数据包的ACK是否在某一个时间范围内被送回。如果没有，则传送端会在超时后重送丢失的数据包。其次，为了加快重送的速度，若TCP收到n（通常为3）个重复ACK时，TCP就直接将数据包视为已经丢失，不待超时发生便立即重送丢失的数据包。随即进入Fast Retransmit和Fast Recovery阶段。

    在TCP Vegas 中，Vegas改进了重送的机制，每当收到一个Duplicate ACK时，Vegas会特别留意RTT的值以检查是否有超时发生。若是，则不需要等待3个Duplicate ACK，Vegas就会直接重送此数据包。此外，当丢失的数据包被重送并返回新的ACK时，Vegas也会特别注意第一个或第二个返回的ACK，以检测随后的数据包是否已超时，并重送丢失的数据包。

2.新的拥塞避免机制（New Congestion Avoidance Mechanism）

我们已经知道，TCP Reno的拥塞控制算法利用数据包丢失作为网络拥塞的信号，为了增加传输效果并探测网络的可用带宽， Reno会持续增加window的大小直到数据包丢失，因此TCP Reno会周期性遭遇数据包丢失的问题。TCP Vegas则采用另一种方式来控制传送速率：通过观察RTT的变化来控制cwnd的大小。有关TCP Vegas的拥塞控制算法简述如下：

Vegas根据预期传送率和实际传送率之间的差异值来调整cwnd的大小。当Diff的值大于β时，意味着传送速率太快，应该减小cwnd的值以减缓传送的速率。反之，当Diff的值小于α时，则表明传送速率较慢，应该加大cwnd的值，以增加传送的速率。

其实，从某种角度看，Diff的值就是这个联机路径Bottleneck的队列长度，而Vegas希望能让队列长度维持在α与β之间。当Diff的值小于α时，表明网络的使用率太低，可以多送一些数据；当Diff的值大于α小于β时，网络的使用率比较稳定，可以恒速发送数据；当Diff的值大于β时，表明网络开始发生拥塞，因此应该减慢传送速度。

3.修改Slow-start阶段（Modified Slow-start）

与TCP Reno相比，TCP Vegas不仅希望能有效地利用可用频宽，而且也尽量避免因为传送太快而发生数据包丢失的情况。因此在慢开始（Slow-start）阶段，为了检测及避免数据包丢失，TCP Vegas减慢了cwnd增加的速度。Vegas 修改了TCP 的Slow-start算法：cwnd的值大约经过2个RTT后才增加1倍。与TCP Reno不同的是，Vegas根据预期传送率与实际传送率之间的差异值（Diff）来调整ssthresh（慢开始门限）的值。当TCP Vegas检测到网络开始有队列产生时，Vegas就由慢开始（Slow-start）进入拥塞避免（Congestion Avoidance）阶段。

【TCP Vegas参数设置】

     TCP Vegas 的使用与TCP Reno大致相同，只是要另外设置α和β的值（默认情况下，α为1，β为3 ）。其设置方法如下所示：

     set tcp0[new Agent/Vegas]

     $ns attach-agent $n0 $tcp0

     $tcp0 set v_alpha_ 2

     $tcp0 set v_beta_ 5

     此外，还可以自行设定γ的值。在NS中，当网络上的队列长度超过γ时，Vegas会由慢开始阶段进入拥塞避免阶段，并将cwnd的值降为原来的7/8（v_gamma 的默认值为1）。

 

  【实验步骤】

 【实验一：同构型环境】

我们先假设一个简单的网络环境（同构型环境）：传输层都使用相同的TCP版本。

 其中，n0、n1、n2、n3为结点，R0与R1为路由器，各结点与路由器的传输速率均为10Mbps，传输延迟为1ms，路由器间的传输速率是1Mbps，传输延迟是20ms。代理（Agent）为TCP Vegas，应用层（Application）为FTP。

 

2.      TCL程序代码（假设我将此代码保存于/home/ns下的lab19.tcl文件中）

#===================================

#     Simulation parameters setup

#===================================

set val(stop)   10.0                 ;# time of simulation end

 

#===================================

#        Initialization       

#===================================

#产生一个仿真对象

set ns [new Simulator]

 

#定义NAM中数据流的颜色

$ns color 1 red

$ns color 2 blue

 

#打开一个路径文件，用来记录数据包传送的过程

set nd [open out19_1.tr w]

$ns trace-all $nd

 

#打开两个文件，记录cwnd变化情况

set f0 [open cwnd0.tr w]

set f1 [open cwnd1.tr w]

 

#打开一个 NAM跟踪文件

set namfile [open out.nam w]

$ns namtrace-all $namfile

 

#===================================

#        Termination       

#===================================

#定义一个结束程序

proc finish {} {

    global ns nd namfile f0 f1 tcp0 tcp1

    $ns flush-trace

    close $nd

    close $namfile

    close $f0

    close $f1

    exec nam out.nam &

 #使用awk分析trace文件以观察队列的变化情况

 #exec 使得awk文件在finish中直接执行

exec awk {

      BEGIN {

            highest_packet_id = -1;

            packet_count = 0;

            q_len= 0;

             }

{

   action = $1;

   time = $2;

   src_node = $3;

   dst_node = $4;

   type = $5;

   flow_id = $8;

   seq_no = $11;

   packet_id = $12; 

 #如果对象是路由器R1与R2，此序号（2,3）与结点的定义顺序相对应

   if (src_node == "2" && dst_node == "3") {

        if (packet_id > highest_packet_id) {

             highest_packet_id = packet_id;       

                 }

 #如果数据包入队，队列长度加1并打印出当时的时间及队列长度

   if (action == "+") {

               q_len++;

               print time, q_len;

                }

 #如果数据包出队或被丢弃，队列长度减1并打印当时的时间及队列长度

           else if (action == "-" || action == "d") {

               q_len--;

                print time, q_len;

                }

         }

     }

 } out19_1.tr > queue_length-19.tr

 #将out19_1.tr文件用awk分析后得到的结果存入文件queue_length-19.tr中

    exit 0

}

 

#定义一个记录的程序，每隔0.01s去记录当时的cwnd。此间隔时间可变，其值

#越大，所绘图形约粗糙

proc record { } {

global ns tcp0 f0 tcp1 f1

set now [$ns now]

puts $f0 "$now [$tcp0 set cwnd_]"

puts $f1 "$now [$tcp1 set cwnd_]"

$ns at [expr $now+0.01] "record"

}

 

#===================================

#        Nodes Definition       

#===================================

#建立结点

set n0 [$ns node]

set n1 [$ns node]

set n2 [$ns node]

set n3 [$ns node]

set n4 [$ns node]

set n5 [$ns node]

 

#===================================

#        Links Definition       

#===================================

#建立结点间的链接

$ns duplex-link $n0 $n2 10.0Mb 1ms DropTail

$ns duplex-link $n1 $n2 10.0Mb 1ms DropTail

$ns duplex-link $n3 $n4 10.0Mb 1ms DropTail

$ns duplex-link $n3 $n5 10.0Mb 1ms DropTail

$ns duplex-link $n2 $n3 1.0Mb 20ms DropTail

#设置最大队列长度为15

set buffer_size 15

$ns queue-limit $n2 $n3 $buffer_size

 

#确定NAM中结点的位置

$ns duplex-link-op $n0 $n2 orient right-down

$ns duplex-link-op $n1 $n2 orient right-up

$ns duplex-link-op $n3 $n4 orient right-up

$ns duplex-link-op $n3 $n5 orient right-down

$ns duplex-link-op $n2 $n3 orient right

 

#===================================

#        Agents Definition       

#===================================

#建立一个 TCP/Vegas 代理

set tcp0 [new Agent/TCP/Vegas]

$tcp0 set v_alpha_ 1

$tcp0 set v_beta_ 3

$tcp0 set window_ 24

$tcp0 set fid_ 1

$ns attach-agent $n0 $tcp0

set sink2 [new Agent/TCPSink]

$ns attach-agent $n4 $sink2

$ns connect $tcp0 $sink2

 

#建立另一个 TCP/Vegas 代理

set tcp1 [new Agent/TCP/Vegas]

$tcp1 set v_alpha_ 1

$tcp1 set v_beta_ 3

$tcp1 set window_ 24

$tcp1 set fid_ 2

$ns attach-agent $n1 $tcp1

set sink3 [new Agent/TCPSink]

$ns attach-agent $n5 $sink3

$ns connect $tcp1 $sink3

 

#===================================

#        Applications Definition       

#===================================

#建立一个 TCP/Vegas 的FTP联机

set ftp0 [new Application/FTP]

$ftp0 attach-agent $tcp0

$ns at 0.0 "$ftp0 start"

$ns at 10.0 "$ftp0 stop"

 

#建立另一个 TCP/Vegas 的FTP联机

set ftp1 [new Application/FTP]

$ftp1 attach-agent $tcp1

 

$ns at 5.0 "$ftp1 start"

$ns at 10.0 "$ftp1 stop"

$ns at 0.0 "record"

$ns at $val(stop) "$ns nam-end-wireless $val(stop)"

$ns at $val(stop) "finish"

$ns at $val(stop) "puts \"done\" ; $ns halt"

#执行模拟

$ns run

3.      执行方法

[root@localhost tclfiles]# cd /home/ns

[root@localhost ns]# ns lab19.tcl

4.      执行结果

              

      

                                            图2  2.098s时，数据包传送情况

由代码可见，第一条Vegas从0s开始执行，10s结束。因此2.098s时，只有红色（代表tcp0）数据包在传输。下面，我们看一下8s左右数据包的传送情况。如图3所示：

       

                     

                                        图3  8.094s时，数据包传送情况

第二条Vegas从5s开始执行，10s结束。因此，8.09s时有红色和蓝色（代表tcp1）两种数据包在传输。

5. 使用gnuplot观察cwnd的变化值，如图4所示。其执行方法如下：

[root@localhost ns]# gnuplot

gnuplot> set title "Vegas"

gnuplot> set xlabel "time"

gnuplot> set ylabel "cwnd"

gnuplot> plot "cwnd0.tr" with linespoints 1,"cwnd1.tr" with linespoints 2

     

                            

                                          图4 TCP Vegas中cwnd变化图

      （备注：红色线条为tcp0的cwnd变化情况，绿色线条为tcp1的cwnd变化情况）

从图中可以看到，在慢开始（Slow-start）阶段，cwnd的值大约经过2个

RTT才会增加1倍。与Reno不同的是，当Diff的值介于α与β之间时，Vegas的cwnd值会维持在一个稳定的状态，我们可通过分析记录文件来观察队列的变化。值得注意的是，当有两条以上联机存在于网络时，Vegas还是能维持在稳定的状态而且不会因传送得太快而造成数据包丢失。因为，基本上Vegas的拥塞控制算法是一种“拥塞避免”方法。

6.      使用gnuplot观察queue length 的变化值，如图5所示。其执行方法如下：

[root@localhost ns]# gnuplot

gnuplot> set title "queue length"

gnuplot> set xlabel "time"

gnuplot> set ylabel "packets"

gnuplot> plot "queue_length-19.tr" with lines 2

 

                    

                                                    图5  TCP Vegas 队列长度变化情况

在0s到0.6s间，tcp0发送数据包，队列长度持续增长；0.6s到0.7s，网络发生拥塞，队列长度减小；0.7s到5s，网络稳定，队列长度维持基本不变。5s后，tcp1也开始发送数据包，使得队列中的数据包数突然激增，于5.8s时网络拥塞。随之，调整数据包的数目，于6s左右达到了新的平衡。

   实验结果显示，在同构型环境下，TCP Vegas 比TCP Reno 有更好的吞吐量，更小的丢包率。

 

【实验2：异构型环境下TCP Vegas 与TCP Reno的运行】

过上面的实验，我们证明了TCP Vegas能较好地预测网络带宽使用情况，其公平性、效率都较好。但是，为什么它没有在Internet上得到广泛应用呢？

我们提过，TCP Reno是目前应用最广泛的算法，因此在使用TCP Vegas时，势必需要考虑是否能与TCP Reno共存并正常运行。接下来，以一个简单是例子来说明，当网络中的传输协议不完全都是TCP Vegas 时（即在异构型的环境下），TCP Vegas的运行情况。

1.      仿真实验网络结构图（图6）

      

 

此结构图与图1基本相同，但有一点不同的在于tcp1为TCP Reno，在此就不赘述了。

2.      TCL程序代码（假设我将此文件保存于/home/ns/下的lab21.tcl中）

#产生一个仿真对象

set ns [new Simulator]

 

#定义NAM中数据流的颜色

$ns color 1 red

$ns color 2 blue

 

#打开一个trace文件记录数据包传送的过程

set nd [open out21.tr w]

$ns trace-all $nd

 

#打开一个NAM跟踪文件

set nf [open out.nam w]

$ns namtrace-all $nf

 

#打开两个文件记录cwnd变化情况

set f0 [open cwnd-vegas.tr w]

set f1 [open cwnd-reno.tr w]

 

#定义一个结束程序

proc finish { } {

    global ns nd f0 tcp0 f1 tcp1 nf 

#显示最后的平均吞吐量，吞吐量为链路中每秒传送的比特数=收到

#的应答（ACK）数（成功发送的数据包数）*每个数据包的大小（比特#数）/传输时间

    puts [format "Vegas-throughput: %.1f Kbps" \

       [expr [$tcp0 set ack_]*([$tcp0 set packetSize_])*8/1000.0/10]]

    puts [format "Reno-throughput: %.2f Kbps" \

       [expr [$tcp1 set ack_]*([$tcp1 set packetSize_])*8/1000.0/10]]

    $ns flush-trace

    close $nd

    close $f0

    close $f1

    close $nf

    #执行nam

    exec nam out.nam &

    exit 0

}

 

#定义一个记录文件，每隔0.01s记录当时的cwnd值

proc record { } {

 global ns tcp0 f0 tcp1 f1

 set now [$ns now]

 puts $f0 "$now [$tcp0 set cwnd_]"

 puts $f1 "$now [$tcp1 set cwnd_]"

 $ns at [expr $now+0.01] "record"

 

} 

 

#建立结点

set r0 [$ns node]

set r1 [$ns node]

set n0 [$ns node]

set n1 [$ns node]

set n2 [$ns node]

set n3 [$ns node]

 

#建立结点间的链接

$ns duplex-link $n0 $r0 10Mb 1ms DropTail

$ns duplex-link $n2 $r0 10Mb 1ms DropTail

$ns duplex-link $r0 $r1  1Mb 20ms DropTail

$ns duplex-link $r1 $n1 10Mb 1ms DropTail

$ns duplex-link $r1 $n3 10Mb 1ms DropTail

 

        #设置队列大小

set buffer_size 15

$ns queue-limit $r0 $r1 $buffer_size

 

#设置结点在NAM中的位置

$ns duplex-link-op $n0 $r0 orient right-down

$ns duplex-link-op $n2 $r0 orient right-up

$ns duplex-link-op $r1 $n1 orient right-up

$ns duplex-link-op $r1 $n3 orient right-down

$ns duplex-link-op $r0 $r1 orient right

           #建立一个TCP Vegas的FTP联机

set tcp0 [new Agent/TCP/Vegas]

$tcp0 set v_alpha_ 1

$tcp0 set v_beta_ 3

$tcp0 set window_ 24

$tcp0 set fid_ 1

$ns attach-agent $n0 $tcp0

set tcp0sink [new Agent/TCPSink]

$ns attach-agent $n1 $tcp0sink

$ns connect $tcp0 $tcp0sink

set ftp0 [new Application/FTP]

$ftp0 attach-agent $tcp0

 

#建立一个TCP Reno的FTP联机

set tcp1 [new Agent/TCP/Reno]

$tcp1 set window_ 24

$tcp1 set fid_ 2

$ns attach-agent $n2 $tcp1

set tcp1sink [new Agent/TCPSink]

$ns attach-agent $n3 $tcp1sink

$ns connect $tcp1 $tcp1sink

set ftp1 [new Application/FTP]

$ftp1 attach-agent $tcp1

 

#指定ftp0的执行时间

$ns at 0.0 "$ftp0 start"

$ns at 10.0 "$ftp0 stop"

 

#指定ftp1的执行时间

$ns at 0.0 "$ftp1 start"

$ns at 10.0 "$ftp1 stop"

 

$ns at 0.0 "record"

$ns at 10.0 "finish"

 

#执行模拟

$ns run

3.   执行方法

[root@localhost tclfiles]# cd /home/ns

[root@localhost ns]# ns lab21.tcl

 

4.   执行结果

Vegas-throughput: 303.2 Kbps

Reno-throughput: 636.00 Kbps

并随即出现NAM图形，其部分截图如下所示：

                    

            

                   图7  0.326s时，发生丢包

        

               图8  7.01s时发生丢包

 除此之外，在4.11s，5.58s，8.44s，9.91s等也分别出现了丢包现象。

 从得到的平均吞吐量来看，当TCP Vegas 与TCP Reno 在网络上同时运行时，TCP Reno的平均吞吐量远远高于TCP Vegas。

5.   使用gnuplot观察cwnd的变化值，如图9所示。其执行方法如下：

[root@localhost ns]# gnuplot

     gnuplot> set title "Vegas vs Reno"

     gnuplot> set xlabel "time"

    gnuplot> set ylabel "cwnd"

    gnuplot> plot "cwnd-vegas.tr" with linespoints 1,"cwnd-reno.tr" with linespoints 2

    

                                 图9  Vegas 与Reno的cwnd 变化图

  

       从图9可以看出，TCP Reno的窗口（window）总是在较高的地方振荡，而TCP Vegas的窗口（window）则总是维持在较低的位置。从前面的实验可以看到，当网络中的通信都用TCP Vegas时，整体的执行效果明显优于TCP Reno（TCP Vegas采取比较保守的方法避免数据包丢失，以此提高网络的执行效果）。但遗憾的是，当TCP Vegas与TCP Reno共存时，TCP Vegas并没有办法与TCP Reno公平地竞争频宽。

      产生这种现象的主要原因在于：TCP Reno使用了较具侵略性的拥塞控制算法，其传送端会持续不断地将数据包送到网络上知道拥塞发生。相比之下，TCP Vegas的传送端在网络开始拥塞时就将传送速率降低，以避免拥塞发生。

因此，当TCP Vegas与TCP Reno 共存时，Vegas在效果上的表现比较差。

【小结】

通过本实验，我们比较清晰地了解了TCP Vegas的相关知识，并看到了当TCP Vegas与TCP Reno同时在网络中运行时所出现的弊端。这说明在扩展一个新算法时，除了验证自身的优越性外，还应该将其放在不同的环境下进行多方面的验证（例如：能否稳定地与现行TCP/IP网络共存等）。

----------------------

原文地址：http://selab.whust.com/Display_Diary.aspx?DiaryID=52