一个在ns3平台基于UDP协议实现的拥塞控制仿真框架

Soonyang Zhang

已于 2022-01-23 19:43:05 修改

阅读量5.4k

点赞数 26

CC 4.0 BY-SA版权

分类专栏：仿真拥塞控制计算机网络文章标签：算法

于 2020-06-15 14:48:03 首次发布

本文链接：https://blog.csdn.net/u010643777/article/details/106761440

仿真同时被 3 个专栏收录

50 篇文章

订阅专栏

拥塞控制

38 篇文章

订阅专栏

计算机网络

20 篇文章

订阅专栏

本来ns3中实现的TCP协议栈就实现了各种的拥塞控制算法，我在UDP协议也实现了一个拥塞控制评价模块。为什么这么干，当时觉得ns3中的TCP仿真模块不太灵活，比如怎么拿到数据包的单向传输时延，怎么统计丢包率。当时觉的这些都没法做，于是我就模仿quic协议实现了一个简单的传输协议。最近发现，这些需求在ns3中的TCP协议栈中都是可以实现的。这样就显得我的实现多此一举。但是，还是有所得：通过抄写谷歌的代码，我的编程能力有明显提升。
然后就有一些同学，询问我的代码，代码本身是开源的。但是，一般向我问询的人都是ns3的新手。看到我的一坨代码，就不知道如何安装了。我又是十分热心的人，知道现在的很多研究生的不容易。我也乐意帮助他们减少一些学习的困难。在网络研究领域，做事的人少，写手越来越多。试看今日之论文，伪造的点线图一个高过一个。毕竟，当前中国学术圈的主要矛盾是日益增长的论文需求同有限方法论之间的矛盾。但是一遍遍告诉别人怎么安装，每次都要浪费小半天时间。子在川上曰：逝者如斯夫，不舍昼夜。时间浪费的令我心痛。我是一个惜时的人：My time is not measured by the tick of a clock, but by the length of life.
遂有此篇，怎么在ns3中安装这坨代码[1]，并获取数据。

Step1 修改编译器标志

ns3中的有个编译标志需要修改，不然，定义的函数，没有被调用，编译当做错误处理。
Change the warning flags in the fille (waf-tools/cflags.py) which may lead compiling failure.
Original:

self.warnings_flags = [['-Wall'], ['-Werror'], ['-Wextra']]

Changed version:

self.warnings_flags = [['-Wall'], ['-Wno-unused-parameter'], ['-Wextra']]

enable c++14 build flag

if you run the code on ns-3.26:
Find CXXFLAGS in file named wscript under ns-3.26

env.append_value('CXXFLAGS', '-std=c++11')

Change it.

env.append_value('CXXFLAGS', '-std=c++14')

if you run the code on ns-3.30:
Find the following line in file named wscript under ns-3.30

    opt.add_option('--cxx-standard',
                   help=('Compile NS-3 with the given C++ standard'),
                   type='string', default='-std=c++11', dest='cxx_standard')

Make minor change.

    opt.add_option('--cxx-standard',
                   help=('Compile NS-3 with the given C++ standard'),
                   type='string', default='-std=c++14', dest='cxx_standard')

Step3 文件放置

把[1]中的整个dqc文件夹放进ns3的src文件夹下。
在这里插入图片描述

配置环境变量

sudo gedit /etc/profile

export DQC=/home/zsy/C_Test/ns-allinone-3.26/ns-3.26/src/dqc/model/thirdparty  
export CPLUS_INCLUDE_PATH=CPLUS_INCLUDE_PATH:$DQC/include/:$DQC/congestion/:$DQC/logging/

这里的DQC是我电脑中的路径，替换你的路径！
找不路径，可以在shell中进入dqc/model/thirdparty，键入$PWD命令，
把输出的绝对路径赋值给DQC。

create a folder named as traces to collect results.

在这里插入图片描述

Build

cd ns-allinone-3.xx/ns-3.xx/
source /etc/profile
./waf configure
./waf build

Test the samples

Put these sample files under scratch on github to the scratch file。
在这里插入图片描述
Run：

cd ns-allinone-3.xx/ns-3.xx/
source /etc/profile  
./waf --run "scratch/bbr-var-eva-3.30 --it=1 --cc=bbr"

Find the results in traces folder。The one way transmission delay is traced in the file testid_bbr_flowid_owd.txt.

//https://github.com/SoonyangZhang/DrainQueueCongestion/blob/master/dqc/model/dqc_trace.cc
void DqcTrace::OpenTraceOwdFile(std::string name){
	char buf[FILENAME_MAX];
	memset(buf,0,FILENAME_MAX);
	std::string path = std::string (getcwd(buf, FILENAME_MAX)) + "/traces/"
			+name+"_owd.txt";
	m_owd.open(path.c_str(), std::fstream::out);    
}
void DqcTrace::OnOwd(uint32_t seq,uint32_t owd,uint32_t size){
	if(m_owd.is_open()){
		float now=Simulator::Now().GetSeconds();
		m_owd<<now<<"\t"<<seq<<"\t"<<owd<<"\t"<<size<<std::endl;
		m_owd.flush();
	}    
}

m_owd<<now<<"\t"<<seq<<"\t"<<owd<<"\t"<<size<<std::endl;
traces文件夹下后缀为owd的日志文件，这是dqc_receiver收集的数据，每行代表的含义分别为：接收数据包的时刻（now），数据包序号（seq），单向传输时延（owd），
dqc/model/dqc_receiver.cc中的m_traceOwdCb收集的数据。

data processing

这个项目，有些同学用于测试或者毕业设计中的相关内容。项目里的script文件有一些画图脚本和使用python进行数据处理的文件。
画图脚本，使用的是gnuplot，先安装：

sudo apt-get install gnuplot

假设你使用ns3.30的版本，运行的是以下命令：

cd ns-allinone-3.30/ns-3.30/
source /etc/profile  
./waf --run "scratch/bbr-var-eva-3.30 --it=1 --cc=bbr"

进入trace文件夹下，将script中的bw_plot.sh复制到traces文件夹下。修改bw_plot.sh的第三行，algo=bbr。

chmod 777 bw_plot.sh
./bw_plot.sh

根据后缀为owd的日志文件，可以统计算法的丢包率，平均单向传输时延和链路带宽利用率，分别由pro-loss.py，pro-owd.py和pro-utilit.py处理。
根据owd的日志文件，丢包率的处理比较简单：收到数据包的个数÷最大的数据包序号。数据流个数需要同仿真文件一致，bbr-var-eva-3.30一共配置了5个数据流。修改pro-loss.py中的flows=5。

python pro-loss.py --algo=bbr

pro-utilit.py计算带宽利用率的原理，utility=all flows all received bytes÷（C×T）。C是瓶颈链路带宽，T是仿真中配置的时间。我的仿真程序，只有仿真接收才会停止发送数据，这种计算方式问题不大。数据流个数需要同仿真文件一致。针对bbr-var-eva-3.30的测试程序，修改pro-utilit.py中的仿真结束时间right=400，数据流个数flows=5.

python pro-utilit.py --algo=bbr

我实在疲于应付一个又一个同学，加我好友，询问一次又一次的安装问题和画图问题。每次都要浪费好几个小时。因此今天增加数据处理的说明。

一个更完善的版本

经过假期一周多的努力（2022-01-23），我把整个谷歌开发的quic协议代码在ns3中跑了起来，具体可以[3]给出的github连接。程序在ns3.33中测试。
需要使能c++17的编译标志（ns3.33/wscript）

    opt.add_option('--cxx-standard',  
                   help=('Compile NS-3 with the given C++ standard'),  
                   type='string', default='-std=c++17', dest='cxx_standard')

[1] evluation congestion control algorithm
[2] ns3安装教程
[3] quic-on-ns3