NetPerfMeter : A Network Performance Metering Tool Introduction

http://blog.multipath-tcp.org/blog/html/2015/09/07/netperfmeter.html


NetPerfMeter : A Network Performance Metering Tool

Introduction

A common problem for evaluating multiple transport protocols in a multi-platform environment is to have a test tool that is capable to run in all these environments, and – of course – to support all necessary protocols. Using different evaluation tools is not a good solution, since each tool may introduce its own – and possibly incompatible – parametrisation scheme. In order to overcome this problem, originally for the use case of evaluating the Stream Control Transmission Protocol (SCTP) and compare it to the Transmission Control Protocol (TCP), NetPerfMeter has been designed and developed.

What is NetPerfMeter?

NetPerfMeter [3][5] is an open source, multi-platform transport protocol performance evaluation software. It currently supports the Linux, FreeBSD and MacOS platforms (with possibility to easily extend it to further platforms), and the transport protocols SCTP, TCP including Multi-Path TCP (MPTCP, if supported by the operating system), UDP (User Datagram Protocol) and DCCP (Datagram Congestion Control Protocol, if supported by the operating system). The figure below presents the NetPerfMeter protocol stack.

../../../_images/EN-NetPerfMeter-ProtocolStack.png

In each direction, a data channel can be operated in saturated mode (send as much as possible; not available for UDP-based data channels) or non-saturated mode. In case of the non-saturated mode, the traffic is configured in form of frame rates and frame sizes. That is, frames of a given size are generated in given intervals. Both, frame rate and frame size can be randomised as well.

The performance of the data channels (bandwidth, delay, jitter, etc.) is evaluated and recorded at active and passive side. At the end of a measurement, all collected data is transferred over the control channel to the active side. That is, a user can just conveniently collect all results at the active side. Further details on NerPerfMeter can be found in [3]. [4], [3] also introduce an OMNeT++ simulation model for NetPerfMeter that can be used in simulations, in order to easily compare simulation results and real-world measurements. [1], [2] and [6] provide examples of NetPerfMeter usage for SCTP and MPTCP protocol performance analyses.

Testing MPTCP with NetPerfMeter

In the following, a short tutorial for using NetPerfMeter with MPTCP is provided. It explains the basic features to start experimenting. A more detailed overview of all possible options can be found in the manpage of NetPerfMeter.

Starting the Passive Side

First, the passive side of NetPerfMeter needs to be started:

netperfmeter 9000

This command starts NetPerfMeter in server mode, waiting for control channel connections on port 9000.

Starting the Active Side

One Non-Saturated TCP Flow

Let us start with just one TCP flow:

netperfmeter <passive side>:9000 -tcp const10:const1460:const0:const0

This command starts NetPerfMeter in client mode, connecting to the given peer (given by hostname or IP address), port 9000. A TCP data channel is established, sending 10 frames/s with 1460 bytes/frame from the active to the passive side. The second parameter block specifies 0 frames/s with 0 bytes/frame (that is, no data) in the opposite direction. The measurement ends when stopped by SIGINT (i.e. Ctrl+C).

One Saturated TCP Flow

Making the TCP flow saturated (that is, to send as much as possible) is as easy as setting the frame rate to 0 frames/s (meaning to send as much as possible). Each frame again has a size of 1460 bytes:

netperfmeter <passive side>:9000 -tcp const0:const1460:const0:const0

A Bidirectional TCP Flow

In order to also transmit data in the direction from passive side to active side, just update the parameters:

netperfmeter <passive side>:9000 -tcp const0:const1460:const10:const1460

A fixed frame size of 1460 bytes may not be useful in all scenarios. Therefore, NetPerfMeter provides random distributions as well:

  • exp<average>: Negative exponential distribution with given average. Example: exp1000.
  • uniform<lower>,<upper>: Uniform distribution from lower to upper bound. Example: uniform500,25000.

Random distributions can of course be used for the frame rate as well.

Multi-Path Transport

NetPerfMeter is also able to turn MPTCP on or off per socket (given that the implementation supports the TCP_MULTIPATH_ENABLE socket option). Then, MPTCP can be enabled by the “cmt=mptcp” option:

netperfmeter <passive side>:9000 -tcp const0:const1460:const0:const0:cmt=mptcp

MPTCP versus TCP

Of course, NetPerfMeter can use multiple data channels as well:

netperfmeter <passive side>:9000 \
    -tcp const0:const1460:const0:const0:cmt=mptcp \
    -tcp const0:const1460:const0:const0:cmt=off

In this case, NetPerfMeter starts one MPTCP flow and one concurrent TCP flow. “cmt=off” turns MPTCP off (the default; just not specifying the “cmt” option has the same effect).

Recording Statistics

One of the most important features for researchers is of course to easily get machine-readable results files. Two parameters provide the generation of such files:

  • -scalar=<prefix>.<suffix>
: Generates files named <prefix>-<active|passive>-<flow ID>-<stream ID>.<suffix> with aggregates over the whole measurement. The scalar file format is compatible to OMNeT++ scalar files.
  • -vector=<prefix>.<suffix> :

Generates files named <prefix>-<active|passive>-<flow ID>-<stream ID>.<suffix> with per-frame statistics. The vector files are text tables that could for example be processed by GNU R2 or GNU Plot3. For convenience, if the suffix ends with .bz>2, the results file is BZip2-compressed on the fly. To automate measurements, the -runtime=<seconds> option specifies a duration of the measurement. That is, the following example would run a 60s MPTCP versus TCP comparison, and record scalars as well as vectors:

netperfmeter <passive side>:9000 \
   -runtime=60 \
   -scalar=scalars.sca.bz2 \
   -vector=vectors.vec.bz2 \
   -tcp const0:const1460:const0:const0:cmt=mptcp \
   -tcp const0:const1460:const0:const0:cmt=off

Conclusion

NetPerfMeter is a convenient and flexible open source tool for transport protocol performance analysis. It particularly provides multi-platform support and works with TCP, SCTP, UDP as well as DCCP.

../../../_images/EN-Logo-NetPerfMeter.png

References

[1] Dreibholz, T.; Zhou, X. and Fa, F.: “Multi-Path TCP in Real-World Setups – An Evaluation in the NorNet Core Testbed”, in 5th International Workshop on Protocols and Applications with Multi-Homing Support (PAMS), pp. 617–622, Gwangju/South Korea, March 2015.

[2] Dreibholz, T.; Adhari, H.; Becke, M. and Rathgeb, E. P.: “Simulation and Experimental Evaluation of Multipath Congestion Control Strategies”, in Proceedings of the 2nd International Workshop on Protocols and Applications with Multi-Homing Support (PAMS), Fukuoka/Japan, March 2012.

[3] Dreibholz, T.: “Evaluation and Optimisation of Multi-Path Transport using the Stream Control Transmission Protocol”, Habilitation Treatise, University of Duisburg-Essen, Faculty of Economics, Institute for Computer Science and Business Information Systems, March 2012.

[4] Dreibholz, T.; Adhari, H.; Becke, M. and Rathgeb, E. P.: “NetPerfMeter – A Versatile Tool for Multi-Protocol Network Performance Evaluations”, OMNeT++ Code Contribution, University of Duisburg-Essen, Institute for Experimental Mathematics, February 2012.

[5] Dreibholz, T.; Becke, M.; Adhari, H. and Rathgeb, E. P.: “Evaluation of A New Multipath Congestion Control Scheme using the NetPerfMeter Tool-Chain”, inProceedings of the 19th IEEE International Conference on Software, Telecommunications and Computer Networks (SoftCOM), pp. 1–6, Hvar/Croatia, September 2011.

[6] Adhari, H.; Dreibholz, T.; Becke, M.; Rathgeb, E. P. and Tüxen, M.: “Evaluation of Concurrent Multipath Transfer over Dissimilar Paths”, in Proceedings of the 1st International Workshop on Protocols and Applications with Multi-Homing Support (PAMS), pp. 708–714, Singapore, March 2011.


以下是对提供的参考资料的总结,按照要求结构化多个要点分条输出: 4G/5G无线网络优化与网规案例分析: NSA站点下终端掉4G问题:部分用户反馈NSA终端频繁掉4G,主要因终端主动发起SCGfail导致。分析显示,在信号较好的环境下,终端可能因节能、过热保护等原因主动释放连接。解决方案建议终端侧进行分析处理,尝试关闭节电开关等。 RSSI算法识别天馈遮挡:通过计算RSSI平均值及差值识别天馈遮挡,差值大于3dB则认定有遮挡。不同设备分组规则不同,如64T和32T。此方法可有效帮助现场人员识别因环境变化引起的网络问题。 5G 160M组网小区CA不生效:某5G站点开启100M+60M CA功能后,测试发现UE无法正常使用CA功能。问题原因在于CA频点集标识配置错误,修正后测试正常。 5G网络优化与策略: CCE映射方式优化:针对诺基亚站点覆盖农村区域,通过优化CCE资源映射方式(交织、非交织),提升RRC连接建立成功率和无线接通率。非交织方式相比交织方式有显著提升。 5G AAU两扇区组网:与三扇区组网相比,AAU两扇区组网在RSRP、SINR、下载速率和上传速率上表现不同,需根据具体场景选择适合的组网方式。 5G语音解决方案:包括沿用4G语音解决方案、EPS Fallback方案和VoNR方案。不同方案适用于不同的5G组网策略,如NSA和SA,并影响语音连续性和网络覆盖。 4G网络优化与资源利用: 4G室分设备利旧:面对4G网络投资压减与资源需求矛盾,提出利旧多维度调优策略,包括资源整合、统筹调配既有资源,以满足新增需求和提质增效。 宏站RRU设备1托N射灯:针对5G深度覆盖需求,研究使用宏站AAU结合1托N射灯方案,快速便捷地开通5G站点,提升深度覆盖能力。 基站与流程管理: 爱立信LTE基站邻区添加流程:未提供具体内容,但通常涉及邻区规划、参数配置、测试验证等步骤,以确保基站间顺畅切换和覆盖连续性。 网络规划与策略: 新高铁跨海大桥覆盖方案试点:虽未提供详细内容,但可推测涉及高铁跨海大桥区域的4G/5G网络覆盖规划,需考虑信号穿透、移动性管理、网络容量等因素。 总结: 提供的参考资料涵盖了4G/5G无线网络优化、网规案例分析、网络优化策略、资源利用、基站管理等多个方面。 通过具体案例分析,展示了无线网络优化中的常见问题及解决方案,如NSA终端掉4G、RSSI识别天馈遮挡、CA不生效等。 强调了5G网络优化与策略的重要性,包括CCE映射方式优化、5G语音解决方案、AAU扇区组网选择等。 提出了4G网络优化与资源利用的策略,如室分设备利旧、宏站RRU设备1托N射灯等。 基站与流程管理方面,提到了爱立信LTE基站邻区添加流程,但未给出具体细节。 新高铁跨海大桥覆盖方案试点展示了特殊场景下的网络规划需求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值