【NS2】各种TCP版本 之 TCP Tahoe 和 TCP Reno(转载)

实验目的

学习TCP的拥塞控制机制,并了解TCP TahoeTCP Reno的运行方式。

基础知识回顾

TCP/IPTransmission Control Protocol/Internet Protocol)是目前使用最广泛的一组通信协议。TCP所负责的功能包括:将自应用程序收到的信息分成许多较小的数据区段、提供连接导向的服务、提供可靠性服务、提供应用程序与应用和式之间的流量控制,并依据网络的状况提供拥塞控制。

当应用程序有数据要传送到网上去时,为了希望能和网络上其他的TCP联机公平地共享频宽等资源并避免造成网络拥塞,TCP通过拥塞控制机制来控制允许传送到网络上的数据量。也就是说,TCP的拥塞控制机制直接影响到TCP的传输效率。按照拥塞控制方法的不同,现行使用的TCP分为几个版本:TahoeRenoNewRenoVegasSACK 等。在开始试验之前,我们先简单说明拥塞控制的基本方法,接着介绍各种TCP的版本,并比较之间的异同。

 

TCP 拥塞控制简介】

TCPTransmission Control Protocol)是目前Internet上使用最普遍的第四层通信协议。随着网络的盛行,TCP的作用也日益凸显。然而,TCP仍然有很多问题尚未解决,因此许多有关TCP的研究也陆续提出,以增进TCP的效果。

TCP早期的版本定义在RFC 393 中,它提供可靠性传输服务,并具有流量控制和拥塞控制机制。TCP使用拥塞控制窗口(Congestion Window,简称cwnd)来控制允许被传送到网络上的数据报数量。TCP拥塞控制方法在RFC 2001RFC 2581中已经标准化。在开始数据传送之前,TCP会先在传送端与接收端间建立一条网络联机,将要传送的信息分割成数个数据报,并按照封包编号通过网络层所提供的功能依次传送出去。当收到一个数据报时,TCP的接收端会返回一个ACKAckonwledgmentACK)给传送端,以表示这个数据报已被收到。在整个传送过程中,TCP进行拥塞控制,以避免因为传送过快而造成网络拥塞。

TCP拥塞控制的基本方法(Congestion Control Mechanisms of TCP)】

     一般而言,TCP拥塞控制机制方法主要分为如下5个阶段:Slow-startCongestion AvoidanceFast RetransmissionFast RecoveryTimeout Retransmission

TCP利用Ack检测网络状况并提供可靠性服务,在调整传送端的传送速度时,则以Slow-start threshold(简称ssthresh)与cwnd 的值来区分Slow-startCongestion-avoidance。如下式所示:

        之 TCP Tahoe 和 TCP Reno" title="[zz]各种TCP版本 之 TCP Tahoe 和 TCP Reno" border="0" height="221" width="565">

Slow-start/Congestion Avoidance

如上式所示:当cwnd的值小于ssthresh时,TCP处于slow-start阶段。在这个阶段,每收到一个ACKwindow的值便会加1,因此每经过一个RTT时间,window的值便会变成上个RTTwindow值的2倍。也就是说,在这个阶段,cwnd的值会以指数(2的倍数)的方式增加。当cwnd的值大于ssthreshTCP进入拥塞避免(Congestion Avoidance)阶段。在这个阶段,cwnd的值以线性方式增长。大约每经过一个RTTcwnd的值就会增加一个segment,以避免cwnd的值增加太快而发生数据报遗失。如果检测到封包遗失或超时(timeout),则TCP的传送端会将ssthresh值设为发生拥塞时的window值的一半,重设cwnd的值,接着使用Slow-start重传(重新传送)遗失的数据报。

Acknowledgment机制

TCP的传送端利用ACK来确认数据报是否被接收端收到。当一个封包达到接收端时,接收端会根据收到的数据报号返回一个ACKAcknowledge),表示这个数据报已经收到,并触发传送端再送出新的数据报,这个机制称为“self-clocking”。若收到非连续的数据报时,则返回号码相同的ACK,称为重复的ACKduplicate ACK)。TCP使用ACK及重传的方法提供可靠性的传输服务。

TCP Tahoe

TCP最早的版本称之为TahoeTCP Tahoe 主要有三个机制去控制数据流和拥塞窗口: slow start (SS), congestion avoidance (CA), and fast retransmit(FS)SS机制:connection 建立时,把congestion window 的大小初始化,并设为一个MSS(maximum segment size),同时把ssthresh (slow start threshold)设为 64 KBCA 机制: 为了在发生拥塞的情形下控制流量TCP Tahoe 使用Additive Increase Multiplicative Decrease (AIMD)机制。AIMD:只要有一个packet loss就认为网络发生拥塞,Tahoe会把ssthrsh 设为目前的congestion window 的一半。并且回到SS的状态,之后congestion window 继续以指数成长;当到达ssthreshcongestion window 会以线性成长来避免拥塞。FS 机制:当收到三个重复的ack 时,不必等到Retransmit Timeout(RTO),会认为包丢失,并且马上重传。

TCP Reno

     TCP Reno 是目前使用最广泛的TCP版本。 除了包含了Tahoe的三个机制(SS,CA,FS)Reno 多了另外一个机制: 快速恢复Fast Recovery(FR)FR机制:当收到三个重复的ack 或是超过了RTO 且尚未收到某个数据报的ackReno 会认为有数据报遗失了,并且认定网络发生拥塞。Reno 会把ssthresh 设为目前congestion window的一半,但并不会回到SS的状态,而是设定congestion windowssthresh,之后congestion window 则维持线性成长。以图1为说明,在round 8 的时候发生了封包遗失,因此Renossthresh 设为目前congestion window 的一半亦即是6Renocongestion window 并且从6 开始线性成长(1 黑线部分)

                               之 TCP Tahoe 和 TCP Reno" title="[zz]各种TCP版本 之 TCP Tahoe 和 TCP Reno" border="0" height="331" width="608">

                                                    图1  TCP Tahoe 与 TCP Reno 机制

实验步骤
【实验1:观察TCP Tahoe Congestion Window 的变化】

1.      仿真实验的网络结构图(图2

       之 TCP Tahoe 和 TCP Reno" title="[zz]各种TCP版本 之 TCP Tahoe 和 TCP Reno" border="0" height="102" width="486">

                   

                                     2 仿真实验的网络结构图

 如图2所示,这是一个由两个路由器组成的简单结构图,其中n0n1表示结点,r0r1表示网络上的路由器。FTP Source 通过r0 连接网络,并且假设有大量数据连续地传送给FTP Sink。路由器的队列管理机制使用DropTail,频宽为1Mbps,传递延迟时间为4ms。在这个例子中,我们只建立1TCP数据流。因为cwnd的值直接反应TCP的传输效果,所以我们选择以cwnd作为观察测量的参数。

 

2.      TCL程序代码(假设我将此代码保存于/home/ns下的tcpversion.tcl中)

if { $argc !=1 } {

       puts "Usage:ns tcpversion.tcl tcpversion"

       exit

}

 

set par1 [lindex $argv 0]

 

set ns [new Simulator]

#打开一个trace文件,用来记录数据报传送的过程

set nd [open $par1.tr w]

$ns trace-all $nd

#打开一个文件用来记录cwnd变化情况

set f0 [open cwnd-$par1.tr w]

 

#定义一个结束的程序

proc finish {} {

       global ns nd f0 tcp

puts [format "average throughput:%.1f Kbps" [expr [$tcp set ack_]*([$tcp set packetSize_])*8/1000/10]]

       $ns flush-trace

       close $nd

       close $f0

       exit 0

}

#定义一个记录的程序

proc record {} {

       global ns tcp f0

       set now [$ns now]

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

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

}

 

#产生传送结点,路由器r1r2和接收结点

set n0 [$ns node]

set r0 [$ns node]

set r1 [$ns node]

set n1 [$ns node]

#建立链路

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

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

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

 

#设置队列长度为18个封包大小

set queue 18

$ns queue-limit $r0 $r1 $queue

 

#根据用户的设置,指定TCP版本,并建立相应的Agent

 if { $par1 == "Tahoe" } {

       set tcp [new Agent/TCP]

       set tcpsink [new Agent/TCPSink]

} elseif { $par1 == "Reno" } {

       set tcp [new Agent/TCP/Reno]

       set tcpsink [new Agent/TCPSink]

}

 

$ns attach-agent $n0 $tcp

$ns attach-agent $n1 $tcpsink

$ns connect $tcp $tcpsink

 

#建立FTP应用程序

set ftp [new Application/FTP]

$ftp attach-agent $tcp

 

$ns at 0.0 "$ftp start"

$ns at 10.0 "$ftp stop"

#0.0s时调用record来记录TCPcwnd 变化情况

$ns at 0.0 "record"

$ns at 10.0 "finish"

$ns run

 

 

3.      执行方法

   之 TCP Tahoe 和 TCP Reno" title="[zz]各种TCP版本 之 TCP Tahoe 和 TCP Reno" border="0" height="38" width="311">

 

4.      结果分析

average throughput:948.0 Kbps

我们得到了平均吞吐率为:948.0Kbps

使用gnuplot观察cwnd的变化值。如图3所示。(gnuplot>是在gnuplot状态下的提示符)

[root@localhost ns]# gnuplot

gnuplot> set title "Tahoe"

gnuplot> set xlabel "time"

gnuplot> set ylabel "cwnd"

gnuplot> plot "cwnd-Tahoe.tr" with linespoints 1

可得到图3

之 TCP Tahoe 和 TCP Reno" title="[zz]各种TCP版本 之 TCP Tahoe 和 TCP Reno" border="0" height="401" width="554">

        

                                      3  Tahoecwnd变化图

             

从图3可以看到,TCPCongestion Window 值会呈现周期性重复变化。TCP Tahoe 开始执行时,先由slow-startSS)开始,cwnd超过ssthresh时进入拥塞避免(CA)阶段。由于传送到网络上的丢包不断增加,当超出允许能传送到网络上的个数时,路由器开始使用DropTail算法将数据报丢掉。当数据报遗失时,TCP Tahoe会将ssthresh设为发现数据报遗失时的一半,接着将Window的值设为1Tahoe重新进入slow-start阶段。

【实验2:观察TCP Reno congestion window 的变化】

1.      执行方法

[root@localhost ns]# ns tcpversion.tcl Reno

 

2.      结果分析

average throughput:949.0 Kbps

我们发现TCP Reno的平均吞吐量比TCP Tahoe 的平均吞吐量大一些。同样,用gnuplot观察cwnd的变化情况。

[root@localhost ns]# gnuplot

gnuplot> set title "Reno"

gnuplot> set xlabel "time"

gnuplot> set ylabel "cwnd"

gnuplot> plot "cwnd-Reno.tr" with linespoints 1

可得到图4

之 TCP Tahoe 和 TCP Reno" title="[zz]各种TCP版本 之 TCP Tahoe 和 TCP Reno" border="0" height="409" width="552">

        

                                           4  Renocwnd变化图

如图4所示,当检测到数据报遗失时,ssthreshcwnd的值会被设置为先前cwnd值的一半。因此重传遗失数据报后,TCP Reno 会由 Congestion AvoidancCA)开始。由于结束Fast recovery 后,TCP Renocwnd的值由先前cwnd值的1/2开始增加,所以得到的平均吞吐量比TCP Tahoe 大一些。

此外,当TCP的传送端观察到端点到端点的路径没有拥塞的情况下,会持续地以累加的方式增加传送速率。但是,当检测到路径拥塞情况发生时,则以倍数方式减少传送速率。基于上述原因,TCP的拥塞控制算法又常被称为累加递增倍数递减的算法(Additive-IncreaseMultiplicative-DecreaseAIMD)。

 

小结

在这个实验中,我们对TCP TahoeTCP Reno 进行了比较与分析,看到了它们两者的区别和联系。尤其是RenoTahoe基础上的改进。使大家对这两种TCP版本有了一个比较清晰的认识。

原文地址:https://www.cnblogs.com/helloWaston/p/4545886.html