Ns3源码分析以及对于DcTcp性能的比较

1. 对于ns3模拟模型的认识:

1. 类图:

 

 

 

 

 

 

2. 模型关系:

 

 

 

 

3. 消息发送调用链 (基于first.cc)

 

 

 

 

4. 消息接收调用链 (基于first.cc)

 

 

 

 

2. 对于不同协议在dctcp_example.cc环境下性能差异的问题

1. 问题现象描述:

 为了解DcTcp和其他协议相比的性能优势, 在不改动 dctcp_example.cc 的其他代码环境下将 TcpDctcp 协议分别替换为 TcpCubic 和 TcpLinuxReno. 分别进行运行, 并比较输出的 example-t1-length.dat 发现以下现象.

 

 

 设计目的为控制拥塞的 DcTcp 反而拥有更高的队列长度.

2. 问题分析结果:

在DcTcp的论文中, 作者使用的队列时当超过某一限制之后全部标记CE. 而dctcp-example.cc中使用的ns3::RedQueueDisc类进行CE标记时遵循以下规则:(开启HardDrop时k = 1,反之k = 2)

1. n_enqueued < minTh 时, 不进行标记

2. minTh <= n_enqueued <= k*maxTh时, 进行某一概率p的随机标记

3. k*maxTh<= n_enqueued 时, 进行全部标记

但是当TCP协议未开启ECN时,或TCP协议包不支持ECN时, 采用以下规则: (开启HardDrop时k = 1,反之k = 2)

1. n_enqueued < minTh 时, 不进行丢包

2. minTh <= n_enqueued <= k*maxTh 时, 进行某一概率p的随机丢包

3. k*maxTh <= n_enqueued 时, 进行全部丢包

注: p的大小与n_enqueued的大小以及拥塞持续的时间相关

由于TcpCubic和TcpLinuxReno都是基于丢包的协议. 它们的收敛点被设计在丢包率为0附近. 而Dctcp由于在论文中使用的是 概率为0 或 概率为1 的标记. 其收敛点被设计在 P(CE) < 1 以下. 而因为需要避免过度响应导致交换机的性能浪费, 在Dctcp的设计中将标记率设置为 P(CE) > 0 的点. 因为收敛的极限不同, 导致协议表现出的队列长度相差较大.

3. 对于问题的解决:

对于ns3::RedQueueDisc的代码进行修改:

 

 

禁用生成概率p的函数, 将p替换成常量1. 使得队列长度大于minTh之后标记CE和丢包的概率都为1. 这样使得 TcpCubic, TcpLinuxReno, Dctcp有相近的收敛点.

修改函数之后的结果: