实验目的
学习TCP的拥塞控制机制,并了解TCP Tahoe 和 TCP Reno的运行方式。
基础知识回顾
TCP/IP (Transmission Control Protocol/Internet Protocol)是目前使用最广泛的一组通信协议。TCP所负责的功能包括:将自应用程序收到的信息分成许多较小的数据区段、提供连接导向的服务、提供可靠性服务、提供应用程序与应用和式之间的流量控制,并依据网络的状况提供拥塞控制。
当应用程序有数据要传送到网上去时,为了希望能和网络上其他的TCP联机公平地共享频宽等资源并避免造成网络拥塞,TCP通过拥塞控制机制来控制允许传送到网络上的数据量。也就是说,TCP的拥塞控制机制直接影响到TCP的传输效率。按照拥塞控制方法的不同,现行使用的TCP分为几个版本:Tahoe,Reno,NewReno,Vegas,SACK 等。在开始试验之前,我们先简单说明拥塞控制的基本方法,接着介绍各种TCP的版本,并比较之间的异同。
【TCP 拥塞控制简介】
TCP(Transmission Control Protocol)是目前Internet上使用最普遍的第四层通信协议。随着网络的盛行,TCP的作用也日益凸显。然而,TCP仍然有很多问题尚未解决,因此许多有关TCP的研究也陆续提出,以增进TCP的效果。
TCP早期的版本定义在RFC 393 中,它提供可靠性传输服务,并具有流量控制和拥塞控制机制。TCP使用拥塞控制窗口(Congestion Window,简称cwnd)来控制允许被传送到网络上的数据报数量。TCP拥塞控制方法在RFC 2001及RFC 2581中已经标准化。在开始数据传送之前,TCP会先在传送端与接收端间建立一条网络联机,将要传送的信息分割成数个数据报,并按照封包编号通过网络层所提供的功能依次传送出去。当收到一个数据报时,TCP的接收端会返回一个ACK(Ackonwledgment,ACK)给传送端,以表示这个数据报已被收到。在整个传送过程中,TCP进行拥塞控制,以避免因为传送过快而造成网络拥塞。
【TCP拥塞控制的基本方法(Congestion Control Mechanisms of TCP)】
一般而言,TCP拥塞控制机制方法主要分为如下5个阶段:Slow-start,Congestion Avoidance、Fast Retransmission、Fast Recovery ,Timeout Retransmission。
TCP利用Ack检测网络状况并提供可靠性服务,在调整传送端的传送速度时,则以Slow-start threshold(简称ssthresh)与cwnd 的值来区分Slow-start或Congestion-avoidance。如下式所示:
Slow-start/Congestion Avoidance
如上式所示:当cwnd的值小于ssthresh时,TCP处于slow-start阶段。在这个阶段,每收到一个ACK,window的值便会加1,因此每经过一个RTT时间,window的值便会变成上个RTT时window值的2倍。也就是说,在这个阶段,cwnd的值会以指数(2的倍数)的方式增加。当cwnd的值大于ssthresh,TCP进入拥塞避免(Congestion Avoidance)阶段。在这个阶段,cwnd的值以线性方式增长。大约每经过一个RTT,cwnd的值就会增加一个segment,以避免cwnd的值增加太快而发生数据报遗失。如果检测到封包遗失或超时(timeout),则TCP的传送端会将ssthresh值设为发生拥塞时的window值的一半,重设cwnd的值,接着使用Slow-start重传(重新传送)遗失的数据报。
Acknowledgment机制
TCP的传送端利用ACK来确认数据报是否被接收端收到。当一个封包达到接收端时,接收端会根据收到的数据报号返回一个ACK(Acknowledge),表示这个数据报已经收到,并触发传送端再送出新的数据报,这个机制称为“self-clocking”。若收到非连续的数据报时,则返回号码相同的ACK,称为重复的ACK(duplicate ACK)。TCP使用ACK及重传的方法提供可靠性的传输服务。
【TCP Tahoe】
TCP最早的版本称之为Tahoe。TCP Tahoe 主要有三个机制去控制数据流和拥塞窗口: slow start (SS), congestion avoidance (CA), and fast retransmit(FS)。SS机制:当connection 建立时,把congestion window 的大小初始化,并设为一个MSS(maximum segment size),同时把ssthresh (slow start threshold)设为 64 KB。CA 机制: 为了在发生拥塞的情形下控制流量TCP Tahoe 使用Additive Increase Multiplicative Decrease (AIMD)机制。AIMD:只要有一个packet loss就认为网络发生拥塞,Tahoe会把ssthrsh 设为目前的congestion window 的一半。并且回到SS的状态,之后congestion window 继续以指数成长;当到达ssthresh 时congestion window 会以线性成长来避免拥塞。FS 机制:当收到三个重复的ack 时,不必等到Retransmit Timeout(RTO),会认为包丢失,并且马上重传。
【TCP Reno】
TCP Reno 是目前使用最广泛的TCP版本。 除了包含了Tahoe的三个机制(SS,CA,FS),Reno 多了另外一个机制: 快速恢复Fast Recovery(FR);FR机制:当收到三个重复的ack 或是超过了RTO 且尚未收到某个数据报的ack,Reno 会认为有数据报遗失了,并且认定网络发生拥塞。Reno 会把ssthresh 设为目前congestion window的一半,但并不会回到SS的状态,而是设定congestion window 为ssthresh,之后congestion window 则维持线性成长。以图1为说明,在round 8 的时候发生了封包遗失,因此Reno 把ssthresh 设为目前congestion window 的一半亦即是6,Reno 的congestion window 并且从6 开始线性成长(图1 黑线部分)。
图1 TCP Tahoe 与 TCP Reno 机制
实验步骤
【实验1:观察TCP Tahoe Congestion Window 的变化】
1. 仿真实验的网络结构图(图2)
图2 仿真实验的网络结构图
如图2所示,这是一个由两个路由器组成的简单结构图,其中n0和n1表示结点,r0和r1表示网络上的路由器。FTP Source 通过r0 连接网络,并且假设有大量数据连续地传送给FTP Sink。路由器的队列管理机制使用DropTail,频宽为1Mbps,传递延迟时间为4ms。在这个例子中,我们只建立1条TCP数据流。因为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"
}
#产生传送结点,路由器r1和r2和接收结点
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来记录TCP的cwnd 变化情况
$ns at 0.0 "record"
$ns at 10.0 "finish"
$ns run
3. 执行方法
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:
图3 Tahoe的cwnd变化图
从图3可以看到,TCP的Congestion Window 值会呈现周期性重复变化。TCP Tahoe 开始执行时,先由slow-start(SS)开始,cwnd超过ssthresh时进入拥塞避免(CA)阶段。由于传送到网络上的丢包不断增加,当超出允许能传送到网络上的个数时,路由器开始使用DropTail算法将数据报丢掉。当数据报遗失时,TCP Tahoe会将ssthresh设为发现数据报遗失时的一半,接着将Window的值设为1。Tahoe重新进入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:
图4 Reno的cwnd变化图
如图4所示,当检测到数据报遗失时,ssthresh和cwnd的值会被设置为先前cwnd值的一半。因此重传遗失数据报后,TCP Reno 会由 Congestion Avoidanc(CA)开始。由于结束Fast recovery 后,TCP Reno中cwnd的值由先前cwnd值的1/2开始增加,所以得到的平均吞吐量比TCP Tahoe 大一些。
此外,当TCP的传送端观察到端点到端点的路径没有拥塞的情况下,会持续地以累加的方式增加传送速率。但是,当检测到路径拥塞情况发生时,则以倍数方式减少传送速率。基于上述原因,TCP的拥塞控制算法又常被称为累加递增—倍数递减的算法(Additive-Increase,Multiplicative-Decrease,AIMD)。
小结
在这个实验中,我们对TCP Tahoe 和 TCP Reno 进行了比较与分析,看到了它们两者的区别和联系。尤其是Reno在Tahoe基础上的改进。使大家对这两种TCP版本有了一个比较清晰的认识。