acn_exp1/report.md

Datacenter Network Simulation using ns3实验报告

陈翊辉

SA19011116

[toc]

网络结构和参数

网络结构和参数如图1

图1 网络结构及参数图

inter-cluster

图2 inter-cluster连接示意图

many-to-one

图2 many-to-one连接示意图

目录组织说明

• img：网络结构图，trace结果统计图
• pcap：抓包文件
• src：源码

• report：报告

  ├── img
  │   ├── 1_2-3_2_rtt.png
  │   │   ...
  │   ├── many-to-one_trace.png
  │   └── opt
  │       ├── 2_2-4_2_rtt.png
  │       │   ...
  │       └── 3_3-1_2_th.png
  ├── pcap
  │   ├── inter-cluster
  │   │   ├── inter-cluster_merged.pcap
  │   │   ├── inter-cluster-10-0.pcap
  │   │   ├── inter-cluster-11-0.pcap
  │   │   ├── inter-cluster-13-0.pcap
  │   │   └── inter-cluster-8-0.pcap
  │   ├── many-to-one
  │   │   └── Many-to-one-7-0.pcap
  │   └── opt
  │       ├── inter-cluster
  │       │   ├── inter-cluster-11-0.pcap
  │       │   ├── inter-cluster-12-0.pcap
  │       │   ├── inter-cluster-14-0.pcap
  │       │   └── inter-cluster-9-0.pcap
  │       └── many-to-one
  │           └── inter-cluster-8-0.pcap
  ├── report.pdf
  └── src
  ├── inter-cluster.cc
  ├── inter-cluster-opt.cc
  ├── many-to-one.cc
  └── many-to-one-opt.cc
  
  

源码说明

基本参照课上slidesns3-Tutorial.pptx的几个ppp和ethernets及tcp例子组合即可。

代码使用Google Code Format规范，需要支持gnu std c++14编译器编译

完整代码见src/

首先定义各类节点数量，添加节点

const int CORE_SWITCH_NUM = 1;
const int AGGREGATION_NUM = 2;
const int TOR_NUM = 4;
const int SERVER_NUM = 8;
// ......

// core_switch | aggregation_switch | tor_switch | server
// 0           | 1 - 2              | 3 - 6      | 7 - 14
all_nodes.Create(CORE_SWITCH_NUM + AGGREGATION_NUM + TOR_NUM + SERVER_NUM);

根据网络结构，将要用p2p连接的节点加入p2p_nodes

// p2p link
p2p_nodes[i][j].Add(all_nodes.Get(i + CORE_THRESHOLD));
p2p_nodes[i][j].Add(all_nodes.Get(j + AGGREGATION_THRESHOLD));

使用PointToPointHelper增加p2p网络

netdev_core_aggr[i * AGGREGATION_NUM + j] = p2p_helper[i][j].Install(p2p_nodes[i][j]);

（csma节点类似，略）

用Ipv4InterfaceContainer分配3种ip地址

std::stringstream ss;
ss << "10.0." << i + 1 << ".0";
std::string base_addr;
ss >> base_addr;
addr.SetBase(base_addr.data(), "255.255.255.0");

安装网络应用sink和client，这里，使用sink-client对规定传输pattern

pattern1: inter-cluster

  // sink - client settings idx: 1 - 8
  // sink app nodes:   2, 4, 5, 7
  //                   |  |  |  |
  // client app nodes: 6, 8, 1, 3
  const std::vector<std::pair<int, int>> sink_client_pairs = {
      {2, 6}, {4, 8}, {5, 1}, {7, 3}};

pattern2: many-to-one

  // sink - client settings idx: 1 - 8
  // sink app nodes:   1, 1, 1, 1, 1, 1, 1
  //                   |  |  |  |  |  |  |
  // client app nodes: 2, 3, 4, 5, 6, 7, 8
  const std::vector<std::pair<int, int>> sink_client_pairs = {
      {1, 2}, {1, 3}, {1, 4}, {1, 5}, {1, 6}, {1, 7}, {1, 8}};

这样两种pattern代码基本可以复用，只需修改sink-client对

PacketSinkHelper packetSinkHelper(
  "ns3::TcpSocketFactory",
  InetSocketAddress(Ipv4Address::GetAny(), 8080));
OnOffHelper onOffHelper(
  "ns3::TcpSocketFactory",
  InetSocketAddress(
  tor_server[sink_idx / 2].GetAddress(sink_idx % 2 + 1), 8080));

最后在sink端启用trace，csma混杂模式为false

仿真结果及分析

inter-cluster

trace结果

图 2-6 节点 tcp抓包结果

以2-6的抓包为例，开始几个即ARP包用以确定对方mac地址，其后即两方来回tcp包，每个分包的长度有606，70等。

往返时间

图 2-6 节点间往返时间图

2-6之间的往返时间(rtt)很不稳定，较多序列(sequence)的往返时间很小(<10ms)，但也有许多往返时间达到50多ms，100多ms，甚至少量达到了200多ms。

吞吐量与窗口大小

图 2-6节点间吞吐量及分片长度图

2-6之间的吞吐量也非常不稳定，在50kbits/s到500kbits/s之间上下振荡。

总体结果

测量	已捕获	已显示
分组	4400	4400 (100.0%)
时间跨度,s	61.285	61.285
平均 pps	71.8	71.8
平均分组大小,B	413	413
字节	1819396	1819396 (100.0%)
平均 字节/秒	29 k	29 k
平均 比特/秒	237 k	237 k

表 2-6节点间抓包结果

总体上说，2-6之间达到的平均速率为237kbtits，而从rtt和吞吐来看，比较不稳定。

4-8，5-1，7-3之间的trace结果与2-6类似，往返时间和吞吐图见img/，总体结果如表

	平均分组大小，字节	字节	平均 比特/秒
2-6	413	1819396	237 k
4-8	414	1873482	244 k
5-1	414	1858744	242 k
7-3	414	1893156	247 k

表 inter-cluster抓包总体结果

网络瓶颈分析

从理论上分析，在cluster间通信，如图2 many-to-one连接示意图，在core switch的链路上，每条链路平均分到1.5mbps的$\frac{1}{4}$，即大约375kbps；在aggregation switch到tor switch的链路上，每条链路平均分到1.0mbps的$\frac{1}{4}$，即大约250kbps，因而要full bisection使每台server达到1mpbs，瓶颈在aggregation switch到tor switch的链路上和core switch的链路上。从仿真结果来看，平均每对节点间的速率为243kbps左右，由此计算出a1和a2链路上速率为970kbps左右，以达到线路带宽上限，与理论符合较好。即aggregation switch链路上确实存在瓶颈。

many-to-one

trace结果

和inter-cluster类似，还是先arp找mac地址，之后tcp通信。

测量	已捕获	已显示
分组	20136	20136 (100.0%)
时间跨度,s	67.446	67.446
平均 pps	298.5	298.5
平均分组大小,B	408	408
字节	8215218	8215218 (100.0%)
平均 字节/秒	121 k	121 k
平均 比特/秒	974 k	974 k

表 many-to-one trace结果统计表

从节点n1来看，速率基本达到了n1链路的1mbps。

n2

n2(10.0.1.3)和n1接在同一tor上，其往返时间和吞吐及窗口大小如下

图 2-1 节点间往返时间图

图 2-1 节点间吞吐量和分片大小图

从上图可以看出，2-1节点间吞吐量相对稳定，在300-500kbps间；而往返时间开始时非常低(<20ms)，之后逐渐升高，达到2000ms左右，仿真结束前回落到1200ms左右。

n3 n4

n3（10.0.2.2）和n4（10.0.2.3）和n1在同一cluster，以n3为例其往返时间和吞吐及窗口大小如下

图 3-1 节点间往返时间图

图 3-1 节点间吞吐量和分片大小图

从上图来看，3-1节点间吞吐量非常不稳定，在0和400000bps之前，而往返时间在开始是极低，之后增长到2000ms以上，在仿真结束前又回到极低。4-1节点与3-1节点类似，见img，不在报告中包含。

n5 n6 n7 n8

n5 n6 n7 n8节点在另一个cluster，以n5（10.0.3.2）为例其往返时间和吞吐及窗口大小如下

图 5-1 节点间往返时间图

图 5-1 节点间吞吐量和分片大小图

从上图来看，5-1节点间连接，在60s前几乎分不到带宽，往返时间在2000ms左右，在60s之后（n2 n3 n4都传输完了），分到几百kbps带宽，6，7，8节点结果见img，不在报告中包含。

总体结果

Address A	Address B	Packets	Bytes	Bytes B → A	Duration
10.0.1.2	10.0.1.3	8984	3692696	3482972	61.99544
10.0.1.2	10.0.2.3	2979	1236634	1166700	64.38073
10.0.1.2	10.0.2.2	3267	1355098	1278444	64.37938
10.0.1.2	10.0.4.2	3086	1235140	1165906	65.94691
10.0.1.2	10.0.4.3	625	240002	226554	67.40779
10.0.1.2	10.0.3.2	640	245136	231338	67.41691
10.0.1.2	10.0.3.3	547	210000	198236	62.92476

表 many-to-one trace结果统计表

从上表来看，离n1越近的吞吐越多。而5，6，7，8本来应该结果接近的，但其中7却获取了较多吞吐，这表明了网络可预测性不好，有较大波动和随机性。

网络瓶颈分析

从理论上分析，若2-7节点都要达到1mbps速率，则n1节点需要7mbps，t1需要6mbps，t2需要2mbps，c1，a2需要4mbps，t3，t4需要2mbps。总的来说，瓶颈主要还是在core到aggregation之间。从仿真结果来看，cluster2总的吞吐都不高，也是受限于core到aggregation之间。

优化方法

从上面分析上看，网络瓶颈主要在core到aggregation及aggregation到tor之间。因而考虑增加一个core switch；并且参考胖树结构，增加连通度，增加aggregation到其他tor的连接；并且使用ecmp路由。

优化源码说明

在之前代码基础上，只需做少量修改，具体见src/

另外需要说明的是，需要注释掉ns-3里一个和ecmp有关的assert（或者编release版本）

ns-allinone-3.27/ns-3.27/src/internet/model/global-route-manager-impl.cc +316

// NS_ASSERT_MSG (m_ecmpRootExits.size () <= 1, "Assumed there is at most one exit from the root to this vertex");

首先修改core switch 的数量

const int CORE_SWITCH_NUM = 2;
const int AGGREGATION_NUM = 2;
const int TOR_NUM = 4;
const int SERVER_NUM = 8;

aggregation到tor的csma连接增加

for (int i = 0; i < AGGREGATION_NUM; ++i) {
  csma_aggregation_nodes[i * 2].Add(all_nodes.Get(AGGREGATION_THRESHOLD + i));
  csma_aggregation_nodes[i * 2].Add(all_nodes.Get(TOR_THRESHOLD));
  csma_aggregation_nodes[i * 2].Add(all_nodes.Get(TOR_THRESHOLD + 1));

  csma_aggregation_nodes[i * 2 + 1].Add(all_nodes.Get(AGGREGATION_THRESHOLD + i));
  csma_aggregation_nodes[i * 2 + 1].Add(all_nodes.Get(TOR_THRESHOLD + 2));
  csma_aggregation_nodes[i * 2 + 1].Add(all_nodes.Get(TOR_THRESHOLD + 3));
}

使用ecmp路由

// Enable ECMP routing
Config::SetDefault("ns3::Ipv4GlobalRouting::RandomEcmpRouting", BooleanValue(true));

优化结果

优化的度量主要考虑往返时间，吞吐的大小和稳定性及各节点获得带宽的差距。

inter-cluster

总体比较

	字节 - 优化前	平均 比特/秒 - 优化前	字节 - 优化后	平均 比特/秒 - 优化后
2-6	1819396	237 k	3911322	496 k
4-8	1873482	244 k	3425396	435 k
5-1	1858744	242 k	3135438	401 k
7-3	1893156	247 k	3551942	452 k

表 inter-cluster优化前后吞吐对比

从上表可见，优化后吞吐明显提升，瓶颈变为tor到server链路带宽。

往返时间

图 优化后inter-cluster往返时间图

从上图来看，往返时间也有很大改善，大多数往返时间极端，最大也不超过100ms，极少数超过60ms。

吞吐及分片大小

图 优化后inter-cluster吞吐和分片长度图

从上图来看，分片长度非常稳定，而吞吐除了大幅提高外也较优化前稳定。其他几对连接结果也类似。

many-to-one

总体比较

Address A	Address B	Bytes	Bytes-opt	Duration	Duration-opt	Bytes B → A	Bits/s B → A - opt
10.0.1.2	10.0.1.3	3692696	3302192	61.99544	62.09534	3482972	401292.3
10.0.1.2	10.0.2.2	1355098	1048420	64.37938	66.19298	1278444	119081.9
10.0.1.2	10.0.2.3	1236634	360872	64.38073	68.13514	1166700	39450.31
10.0.1.2	10.0.3.2	245136	905990	67.41691	64.15984	231338	105996.8
10.0.1.2	10.0.3.3	210000	842802	62.92476	66.88895	198236	93787.21
10.0.1.2	10.0.4.2	1235140	938414	65.94691	66.20609	1165906	106482.3
10.0.1.2	10.0.4.3	240002	893610	67.40779	64.16249	226554	104477.5

表 many-to-one优化前后总部比较

从上表来看，优化后，总的带宽没有变化，大约为1mbps（因为节点的连接是1mbps），但相对于优化前，另一个cluster的4个节点传输的字节数非常均匀，每个节点的传输过程时尝也比较均匀。较原来有较大提升。

往返时间

从上图来看，在资源争夺阶段往返时间比优化前提高了，但也有较低的情况，原因是可以多条链路，有些链路通畅，而有些链路拥塞。而各个节点之前的差距比优化前减少了，也即提升了网络公平性。

吞吐

图 many-to-one优化后吞吐和分片长度

从上图来看，优化后整个过程中吞吐都比较均匀，虽然有某些时刻降到0，但没有出现长时间获取不到资源，也没有出现优化前前期几乎争不到资源的情况，只能等别的节点传完再开始的情况。而分片大小也非常稳定。

总结

使用了core switch和ecmp routing后，网络性能提升，特别是many-to-one这种情况，减少了网络的波动，增加了网络的公平性和可预测性。这比单纯提高带宽的效果要更好。并且增加core switch和链路数量后，网络的鲁棒性也提升了，即使某个核心或聚合交换机故障，网络也能连通。