DOCSLIB.ORG

Flowgrind

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Flowgrind Flowgrind A TCP Traffic Generator for Developers Arnd Hannemann <[email protected]> 05.10.2016 Arnd Hannemann credativ GmbH 1 / 29 Overview Introduction Flowgrind Architecture Example measurements Summary Arnd Hannemann credativ GmbH 2 / 29 Overview Introduction Motivation Flowgrind Architecture Example measurements Summary Arnd Hannemann credativ GmbH 3 / 29 Measuring network performance Wired Internet Tool requirements Backbone I Background: Wireless Mesh Networks Backbone Mesh Gateways I Creating load anywhere in the network I Measuring TCP performance between Backbone Mesh Routers any two nodes I Testing TCP variants Routing Non-routing Mesh Clients Mesh Clients Extensive list of TCP metrics Wired Wirless Mesh Wireless Access-Point I Connection Connection Connection I Separation of control and test traffic Arnd Hannemann credativ GmbH 4 / 29 Related works Feature Iperf Iperf3 Netperf Thrulay TTCP NUTTCP TCP XXXXXX UDP XXXXXX SCTP – XX ––– Other protocols – – X ––– Kernel statistics – ––– X Interval reports XXXX# – X Concurrent tests against same hosts XXXX – X Concurrent tests against different hosts – X –––– Distributed tests – – – – – Bidirectional test connections –––––# Test scheduling –# – – – – – Traffic generation – – ––– Control/test data separation – –# – – – X Arnd Hannemann credativ GmbH 5 / 29 Motivation for a new tool Shortcomings of existing tools I Client-server architecture ⇒ hard to generate cross-traffic I Separation of data/control traffic Arnd Hannemann credativ GmbH 6 / 29 Overview Introduction Flowgrind Architecture Architecture Client-server architecture RPC Example measurements Summary Arnd Hannemann credativ GmbH 7 / 29 Flowgrind Flowgrind I Is a distributed network performance measurement tool I Focuses on TCP testing/debugging I Knobs to test TCP variants against each other I Dump packet headers with libpcap I Gathers TCP statistics from kernel (Linux/FreeBSD) Arnd Hannemann credativ GmbH 8 / 29 Terminology in Flowgrind Flows Wired Internet I One data connection for each flow Backbone I Flows have a source and a Backbone destination endpoint Mesh Gateways Test data can be sent in either I Backbone direction Mesh Routers I Scheduling, flows can run Routing Non-routing Mesh Clients Mesh Clients sequentially, in parallel or can Wired Wirless Mesh Wireless Access-Point Connection Connection Connection overlap Test ConnectionRPCConnection Flowgrind Controller Flowgrind Daemon I Individual parameters for each flow Arnd Hannemann credativ GmbH 9 / 29 Problems with client-server architecture Wireless multi-hop network Arnd Hannemann credativ GmbH 10 / 29 Problems with client-server architecture Wireless multi-hop network Client Server Arnd Hannemann credativ GmbH 10 / 29 Problems with client-server architecture Wireless multi-hop network Client Server Arnd Hannemann credativ GmbH 10 / 29 Client-server architecture Overview I Tools like iperf: split into client and server I Flows can only be established between a client and a server, not between servers I Architecture implemented in older versions of Flowgrind Problems with client-server architecture I For multiple clients: external synchronization of test start is needed I Potential different data handling in client and server (e.g. Thrulay) Arnd Hannemann credativ GmbH 11 / 29 Distributed architecture Controller (flowgrind) Wired Internet Backbone I Parses the test parameters Configures all involved daemons I Backbone Mesh Gateways I Presents the results Backbone Mesh Routers Daemon (flowgrindd) Routing Non-routing Mesh Clients Mesh Clients Wired Wirless Mesh Wireless Access-Point I Started on every test node Connection Connection Connection Test ConnectionRPCConnection I Performs actual tests Flowgrind Controller Flowgrind Daemon I Measures performance metrics Arnd Hannemann credativ GmbH 12 / 29 Remote Procedure Calls (RPC) RPC in Flowgrind I Uses XML-RPC I All calls initiated by controller, no RPC between daemons I Can employ different IP address / interface to separate control and test traffic During a test I Controller periodically queries all daemons for interval results I Formats and prints results upon receiving them Arnd Hannemann credativ GmbH 13 / 29 Overview Introduction Flowgrind Architecture Example measurements Wireless Multi-Hop Network with Cross Traffic AWS example: congestion control algorithms Summary Arnd Hannemann credativ GmbH 14 / 29 Cross-Traffic in a Wireless Multihop Network Test scenario I Measurement performed on testbed I Two flows between two unique pairs of nodes I Routes overlap, one bottleneck link I Second flow started after a delay, stopping earlier Arnd Hannemann credativ GmbH 15 / 29 Topology A E C D Bottleneck link B F I Flow 1 between nodes A and E I Flow 2 between nodes B and F Arnd Hannemann credativ GmbH 16 / 29 Topology Arnd Hannemann credativ GmbH 17 / 29 WMN example: Flowgrind arguments flowgrind -n 2 -i 5 -O b=TCP_CONG_MODULE=reno -F 0 -H s=wlan0.mrouter16/mrouter16,d=wlan0.mrouter8/mrouter8 -T b=900 -F 1 -H s=wlan0.mrouter17/mrouter17,d=wlan0.mrouter9/mrouter9 -T b=300 -Y b=300 Arnd Hannemann credativ GmbH 18 / 29 WMN example: Output # ID begin end through RTT RTT RTT IAT IAT IAT # ID [s] [s] [Mbit] min avg max min avg max S 0 375.011 380.004 0.288782 12916.913 14135.647 15035.946 30.069 183.367 969.321 R 0 375.008 380.001 0.446299 5378.736 7304.811 8322.028 12.080 138.115 1206.780 S 1 375.008 380.009 0.157245 1284.537 2348.903 3978.513 70.058 418.893 2341.099 R 1 375.009 380.010 0.026211 11766.836 11766.836 11766.836 2919.213 2919.213 2919.213 S 0 380.004 385.000 0.288551 13335.203 14015.217 15029.046 63.087 269.419 1427.218 R 0 380.001 385.003 0.406170 7380.097 8201.946 9628.294 16.043 191.917 987.361 cwnd ssth uack sack lost retr fack reor rtt rttvar rto castate mss mtu status ###### 83.000 59 83 0 0 0 0 3 3276.500 50.000 4940.000 open 1448 1500 (n/n) 128.000 107 128 0 0 0 0 3 2879.000 6.000 4252.000 open 1448 1500 (n/n) 44.000 7 44 0 0 0 0 3 2880.500 256.000 4208.000 open 1448 1500 (n/n) 8.000 5 8 0 0 0 0 3 2832.500 149.000 3848.000 open 1448 1500 (n/n) 86.000 59 86 0 0 0 0 3 3654.500 190.000 5072.000 open 1448 1500 (n/n) 142.000 107 142 0 0 0 0 3 3388.500 65.000 4520.000 open 1448 1500 (n/n) Arnd Hannemann credativ GmbH 19 / 29 WMN example: Goodput 1:6 Flow 0 from node 16 to 8 Flow 1 from node 17 to 9 1:4 1:2 1 ] s = Mb 0:8 Goodput [ 0:6 0:4 0:2 0 0 100 200 300 400 500 600 700 800 900 Time [s] Arnd Hannemann credativ GmbH 20 / 29 WMN example: Congestion Window 400 Congestion Window Slowstart threshold 350 300 250 200 150 Window size [segments] 100 50 0 0 100 200 300 400 500 600 700 800 900 Time [s] Arnd Hannemann credativ GmbH 21 / 29 Test of congestion control algorithms in AWS Test scenario I Measurement performed in VPC I Four flows between a pair of nodes I Four different congestion control algorithms Arnd Hannemann credativ GmbH 22 / 29 AWS: Flowgrind arguments flowgrind -n 4 -H s=172.30.0.122,d=172.30.0.123 -T s=900 -F 0 -O s=TCP_CONGESTION=yeah -F 1 -O s=TCP_CONGESTION=cubic -F 2 -O s=TCP_CONGESTION=highspeed -F 3 -O s=TCP_CONGESTION=htcp Arnd Hannemann credativ GmbH 23 / 29 AWS example: Output # ID 0 S: 172.30.0.138 (Linux 4.6.0-1-amd64), random seed: 1611955119, sbuf = 12582912/0 [B] (real/req), rbuf = 12582912/0 [B] (real/req), SMSS = 8949 [B], PMTU = 9001 [B], Interface MTU = 9001 (unknown) [B], CC = yeah, duration = 900.003/900.000 [s] (real/req), through = 5.758049/0.000000 [Mbit/s] (out/in), request blocks = 79075/0 [#] (out/in) # ID 0 D: 172.30.0.139 (Linux 4.6.0-1-amd64), random seed: 1611955119, sbuf = 12582912/0 [B] (real/req), rbuf = 12582912/0 [B] (real/req), SMSS = 1448 [B], PMTU = 9001 [B], Interface MTU = 9001 (unknown) [B], through = 0.000000/5.684553 [Mbit/s] (out/in), request blocks = 0/78065 [#] (out/in), IAT = 0.004/11.529/281.197 [ms] (min/avg/max), delay = 18.708/11481.539/27539.894 [ms] (min/avg/max) ... Arnd Hannemann credativ GmbH 24 / 29 AWS example: Goodput 500 500 YeAH-TCP CUBIC TCP Highspeed TCP H-TCP 400 400 1 − 300 300 Mb s 200 200 Goodput in 100 100 0 0 0 100 200 300 400 500 600 700 800 900 Time in s Arnd Hannemann credativ GmbH 25 / 29 Overview Introduction Flowgrind Architecture Example measurements Summary Arnd Hannemann credativ GmbH 26 / 29 Summary Feature Iperf Iperf3 Netperf Thrulay TTCP NUTTCP Flowgrind TCP XXXXXXX UDP XXXXXX – SCTP – XX –––– Other protocols – – X –––– Kernel statistics – ––– XX Interval reports XXXX# – XX Conc. tests w. same hosts XXXX – XX Conc. tests w. different hosts – X –––– X Distributed tests – – – – – X Bidirectional traffic –––––# X Test scheduling –# – – – – – X Traffic generation – – ––– X Control/test data – –# – – – XX Arnd Hannemann credativ GmbH 27 / 29 Summary Flowgrind I Distributed architecture well suited for complex test scenarios I Extensive TCP metrics I Advanced traffic generation features I https://github.com/flowgrind/flowgrind Possible future improvements I Option for easier multi-core support, performance I support for TCP Fast Open I Add support for other procotols: UDP/DCCP/SCTP Arnd Hannemann credativ GmbH 28 / 29 Thanks for listening. Questions? Arnd Hannemann credativ GmbH 29 / 29.
Load more

Recommended publications
  • Packet Reordering in Mobile Networks
    This is an electronic reprint of the original article. This reprint may differ from the original in pagination and typographic detail. Schulte, Lennart; Zimmermann, Alexander; Nanjundaswamy, Puneeth; Eggert, Lars; Manner, Jukka I'll be a bit late - Packet reordering in mobile networks Published in: Journal of Communications and Networks DOI: 10.1109/JCN.2017.000108 Published: 01/12/2017 Document Version Peer reviewed version Please cite the original version: Schulte, L., Zimmermann, A., Nanjundaswamy, P., Eggert, L., & Manner, J. (2017). I'll be a bit late - Packet reordering in mobile networks. Journal of Communications and Networks, 19(6), 693-703. [8277337]. https://doi.org/10.1109/JCN.2017.000108 This material is protected by copyright and other intellectual property rights, and duplication or sale of all or part of any of the repository collections is not permitted, except that material may be duplicated by you for your research use or educational purposes in electronic or print form. You must obtain permission for any other use. Electronic or print copies may not be offered, whether for sale or otherwise to anyone who is not an authorised user. Powered by TCPDF (www.tcpdf.org) 1 I’ll be a bit late – Packet Reordering in Mobile Networks Lennart Schulte, Alexander Zimmermann, Puneeth Nanjundaswamy, Lars Eggert, Jukka Manner Abstract: Data transfer in mobile networks has increased signif- icantly over the past years, and the capacity of these networks has grown accordingly. Due to their different set of characteris- tics compared to wired networks, they have also received atten- tion from end-to-end developers on transport and application level.
    [Show full text]
  • End-To-End Lightpaths for Large File Transfers Over High Speed Long Distance Networks
    End-to-end lightpaths for large file transfers over high speed long distance networks Corrie Kost, Steve McDonald (TRIUMF) Bryan Caron (Alberta), Wade Hong (Carleton) CHEP03 1 CHEP03 Outline • TB data transfer from TRIUMF to CERN (iGrid 2002) • e2e Lightpaths • 10 GbE technology • Performance tuning (Disk I/O, TCP) • Throughput results • Future plans and activities 2 CHEP03 The Birth of a Demo • Suggestion from Canarie to the Canadian HEP community to participate at iGrid2002 • ATLAS Canada discussed the demo at a Vancouver meeting in late May • Initial meeting at TRIUMF by participants in mid July to plan the demo • Sudden realization that there was a very short time to get all elements in place! 3 CHEP03 did we So what -a--r--e--- -w----e--- -g---o--i--n---g-- --t-o-- do? • Demonstrate a manually provisioned “e2e” lightpath • Transfer 1TB of ATLAS MC data generated in Canada from TRIUMF to CERN • Test out 10GbE technology and channel bonding • Establish a new benchmark for high performance disk to disk throughput over a large distance 4 CHEP03 TRIUMF • TRI University Meson Facility • Operated as a joint venture by Alberta, UBC, Carleton, SFU and Victoria • Located on the UBC campus in Vancouver • Proposed location for Canadian ATLAS Tier 1.5 site 5 The iGrid2002 Network 6 CHEP03 e2e Lightpaths • Core design principle of CA*net 4 • Ultimately to give control of lightpath creation, teardown and routing to the end user • Users “own” their resources and can negotiate sharing with other parties – Hence, “Customer Empowered Networks” • Ideas evolved from initial work on OBGP • Provides a flexible infrastructure for emerging grid applications via Web Services 7 CHEP03 e2e Lightpaths • Grid services architecture for user control and management • NEs are distributed objects or agents whose methods can be invoked remotely • Use OGSA and Jini/JavaSpaces for e2e customer control • Alas, can only do things manually today 8 CHEP03 CA*net 4 Topology Edmonton Saskatoon Winnipeg Vancouver Calgary Halifax Kamloops Regina Thunder Bay St.
    [Show full text]
  • Evaluation and Tuning of Gigabit Ethernet Performance on Clusters
    EVALUATION AND TUNING OF GIGABIT ETHERNET PERFORMANCE ON CLUSTERS A thesis submitted to Kent State University in partial fulfillment of the requirements for the Degree of Master of Science by Harit Desai August, 2007 Thesis Written By Harit Desai B.E., Nagpur University, India, 2000 M.S., Kent State University, OH, 2007 Approved by Dr. Paul A. Farrell, Advisor Dr. Robert A. Walker, Chair, Dept. of Computer Science Dr Jerry Feezel, Dean, College of Arts and Sciences ii TABLE OF CONTENTS ACKNOWLEDGEMENTS …..………………………………………………………….vi CHAPTER 1 INTRODUCTION ....…………………………….…………………….. 1 1.1 Clusters for Scientific Computing ……………………………………….…….... 2 1.2 Thesis Organization .………………………………………………………........ 8 CHAPTER 2 OVERVIEW OF GIGABIT ETHERNET TECHNOLOGY ..............9 2.1 Operating Modes ………………………………………………………………... 9 2.2 Enhanced CSMA/CD…………………………………………………………… 12 2.3 Issues affecting Gigabit Ethernet performance…………………………………. 15 CHAPTER 3 VI ARCHITECTURE OVERVIEW ………………………………… 19 3.1 VI Architecture…………………………………………………………………..20 3.1.1. Virtual Interfaces……………………………………………………………….. 21 3.1.2. VI Provider …..…………………………………………………………...……. 23 3.1.3 VI Consumer……………………………………………………………………. 23 3.1.4. Completion Queues………………………………………………..……………. 24 3.2. Data Transfer Models………………………………………………..………….. 25 3.2.1 Send/Receive……………………………………………………………..………26 3.3. Managing VI Components……………………………………………….………27 iii 3.3.1 Accessing a VI NIC……………………………………………………………...27 3.3.2 Registering and De-registering Memory …..………………...…………………28 3.3.3 Creating and Destroying VIs …………………………………………………. 28 3.3.4 Creating and Destroying Completion Queue …...………………………….….39 3.4. VI Connection and Disconnection………………....…………………………..31 3.4.1. VI Connection…………………………………………………………………31 3.4.2. VI Disconnection……………………………………………………………...34 3.4.3. VI Address Format…………………………………………………………… 35 3.5. VI States…………………………………...…………………………………. 36 CHAPTER 4 NETPIPE……………………………………………………………. 37 4.1. Introduction……………………………………………………………………37 4.2. NetPIPE Design……………………………………………………………….38 4.3.
    [Show full text]
  • Institutionen För Datavetenskap Department of Computer and Information Science
    Institutionen för datavetenskap Department of Computer and Information Science Final thesis NetworkPerf – A tool for the investigation of TCP/IP network performance at Saab Transpondertech by Magnus Johansson LIU-IDA/LITH-EX-A--09/039--SE 2009-08-13 Linköpings universitet Linköpings universitet SE-581 83 Linköping, Sweden 581 83 Linköping Final thesis NetworkPerf - A tool for the investigation of TCP/IP network performance at Saab Transpondertech Version 1.0.2 by Magnus Johansson LIU-IDA/LITH-EX-A09/039SE 2009-08-13 Supervisor: Hannes Persson, Attentec AB Examiner: Dr Juha Takkinen, IDA, Linköpings universitet Abstract In order to detect network changes and network troubles, Saab Transpon- dertech needs a tool that can make network measurements. The purpose of this thesis has been to nd measurable network proper- ties that best reect the status of a network, to nd methods to measure these properties and to implement these methods in one single tool. The resulting tool is called NetworkPerf and can measure the following network properties: availability, round-trip delay, delay variation, number of hops, intermediate hosts, available bandwidth, available ports, and maximum al- lowed packet size. The thesis also presents the methods used for measuring these properties in the tool: ping, traceroute, port scanning, and bandwidth measurement. iii iv Acknowledgments This master's thesis would not be half as good as it is, if I had not received help and support from several people. Many thanks to my examiner Dr Juha Takkinen, without whose countin- uous feedback this report would not have been more than a few confusing pages.
    [Show full text]
  • Network Test and Monitoring Tools
    ajgillette.com Technical Note Network Test and Monitoring Tools Author: A.J.Gillette Date: December 6, 2012 Revision: 1.3 Table of Contents Network Test and Monitoring Tools................................................................................................................1 Introduction.............................................................................................................................................................3 Link Characterization ...........................................................................................................................................4 Summary.................................................................................................................................................................12 Appendix A: NUTTCP..........................................................................................................................................13 Installing NUTTCP ..........................................................................................................................................13 Using NUTTCP .................................................................................................................................................13 NUTTCP Examples..........................................................................................................................................14 Appendix B: IPERF................................................................................................................................................17
    [Show full text]
  • Cloudstate: End-To-End WAN Monitoring for Cloud-Based Applications
    CLOUD COMPUTING 2013 : The Fourth International Conference on Cloud Computing, GRIDs, and Virtualization CloudState: End-to-end WAN Monitoring for Cloud-based Applications Aaron McConnell, Gerard Parr, Sally McClean, Philip Morrow, Bryan Scotney School of Computing and Information Engineering University of Ulster Coleraine, Northern Ireland Email: [email protected], [email protected], [email protected], [email protected], [email protected] Abstract—Modern data centres are increasingly moving to- It is therefore necessary to have a periodic, automated wards more sophisticated cloud-based infrastructures, where means of measuring the state of the WAN link between servers are consolidated, backups are simplified and where any two addresses relevant to the successful delivery of an resources can be scaled up, across distributed cloud sites, if necessary. Placing applications and data stores across sites has application to end-users. This measurement should be taken a cost, in terms of the hosting at a given site, a cost in terms of periodically, with the time between polls being short enough the migration of application VMs and content across a network, that sudden changes in the quality of the WAN are observed, and a cost in terms of the quality of the end-to-end network but far enough part so as not to flood the network with link between the application and the end-user. This paper details monitoring traffic. Data collected from polls should also be a solution aimed at monitoring all relevant end-to-end network links between VMs, storage and end-users.
    [Show full text]
  • Measure Wireless Network Performance Using Testing Tool Iperf
    Measure wireless network performance using testing tool iPerf By Lisa Phifer, SearchNetworking.com Many companies are upgrading their wireless networks to 802.11n for better throughput, reach, and reliability, but getting a handle on your wireless LAN's ( WLAN 's) performance is important to ensure sufficient capacity and coverage. Here, we describe how to quantify network performance using iPerf, a simple, readily-available tool that measures TCP /UDP throughput, loss, and delay. Getting started iPerf was developed to simplify TCP performance tuning by making it easy to measure maximum throughput and bandwidth. When used with UDP, iPerf can also measure datagram loss and delay (aka jitter). iPerf can be run over any kind of IP network, including local Ethernet LANs, Internet access links, and Wi-Fi networks. To use iPerf, you must install two components: an iPerf server (which listens for incoming test requests) and an iPerf client (which launches test sessions). iPerf is available as open source or executable binaries for many operating systems, including Win32, Linux, FreeBSD, MacOS X, OpenBSD, and Solaris. A Win32 iPerf installer can be found at NLANR , while a Java GUI version (JPerf) is available from SourceForge . To measure Wi-Fi performance, you probably want to install iPerf on an Ethernet host upstream from the access point ( AP ) under test -- this will be your server. Next, install iPerf on one or more Wi-Fi laptops -- these will be your clients. This is representative of a typical application flow between Wi-Fi client and wired server. If your goal is to measure AP performance, place your iPerf server on the same LAN as the AP, connected by Fast or Gigabit Ethernet.
    [Show full text]
  • Performance Testing Tools Jan Bartoň 30/10/2003
    CESNET technical report number 18/2003 Performance Testing Tools Jan Bartoň 30/10/2003 1 Abstract The report describes properties and abilities of software tools for performance testing. It also shows the tools comparison according to requirements for testing tools described in RFC 2544 (Benchmarking Terminology for Network Intercon- nection Devices). 2 Introduction This report is intended as a basic documentation for auxiliary utilities or pro- grams that have been made for the purposes of evaluating transfer performance between one or more PCs in the role of traffic generators and another one on the receiving side. Section 3 3 describes requirements for software testing tools according to RFC 2544. Available tools for performance testing are catalogued by this document in section 4 4. This section also shows the testing tools com- patibility with RFC 2544 and the evaluation of IPv6 support. The summary of supported requirements for testing tools and IPv6 support can be seen in section 5 5. 3 Requirements for software performance testing tools according to RFC-2544 3.1 User defined frame format Testing tool should be able to use test frame formats defined in RFC 2544 - Appendix C: Test Frame Formats. These exact frame formats should be used for specific protocol/media combination (ex. IP/Ethernet) and for testing other media combinations as a template. The frame size should be variable, so that we can determine a full characterization of the DUT (Device Under Test) performance. It might be useful to know the DUT performance under a number of conditions, so we need to place some special frames into a normal test frames stream (ex.
    [Show full text]
  • How to Generate Realistic Network Traffic? Antoine VARET and Nicolas LARRIEU ENAC (French Civil Aviation University) - Telecom/Resco Laboratory
    How to generate realistic network traffic ? Antoine Varet, Nicolas Larrieu To cite this version: Antoine Varet, Nicolas Larrieu. How to generate realistic network traffic ?. IEEE COMPSAC 2014, 38th Annual International Computers, Software & Applications Conference, Jul 2014, Västerås, Swe- den. pp xxxx. hal-00973913 HAL Id: hal-00973913 https://hal-enac.archives-ouvertes.fr/hal-00973913 Submitted on 4 Oct 2014 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. How to generate realistic network traffic? Antoine VARET and Nicolas LARRIEU ENAC (French Civil Aviation University) - Telecom/Resco Laboratory ABSTRACT instance, an Internet Service Provider (ISP) providing access for Network engineers and designers need additional tools to generate software engineering companies manage a different profile of data network traffic in order to test and evaluate, for instance, communications than an ISP for private individuals [2]. However, application performances or network provisioning. In such a there are some common characteristics between both profiles. The context, traffic characteristics are the most important part of the goal of the tool we have developed is to handle most of Internet work. Indeed, it is quite easy to generate traffic, but it is more traffic profiles and to generate traffic flows by following these difficult to produce traffic which can exhibit real characteristics different Internet traffic properties.
    [Show full text]
  • Openss7 IPERF Utility Installation and Reference Manual Version 2.0 Edition 8 Updated 2008-10-31 Package Iperf-2.0.8
    OpenSS7 IPERF Utility Installation and Reference Manual Version 2.0 Edition 8 Updated 2008-10-31 Package iperf-2.0.8 Brian Bidulock <[email protected]> for The OpenSS7 Project <http://www.openss7.org/> Copyright c 2001-2006 OpenSS7 Corporation <http://www.openss7.com/> Copyright c 1997-2000 Brian F. G. Bidulock <[email protected]> All Rights Reserved. Published by OpenSS7 Corporation 1469 Jefferys Crescent Edmonton, Alberta T6L 6T1 Canada This is texinfo edition 8 of the OpenSS7 IPERF Utility documentation, and is consistent with Iperf 2.0. This manual was developed under the OpenSS7 Project and was funded in part by OpenSS7 Corporation. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the con- ditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another lan- guage, under the same conditions as for modified versions. i Short Contents Preface ::::::::::::::::::::::::::::::::::::::::::::::::: 1 Quick Start Guide :::::::::::::::::::::::::::::::::::::::: 9 1 Introduction :::::::::::::::::::::::::::::::::::::::: 15 2 Objective ::::::::::::::::::::::::::::::::::::::::::: 17 3 Reference ::::::::::::::::::::::::::::::::::::::::::: 19 4 Conformance ::::::::::::::::::::::::::::::::::::::::
    [Show full text]
  • Realistic Network Traffic Profile Generation: Theory and Practice
    Realistic Network Traffic Profile Generation : Theory and Practice Antoine Varet, Nicolas Larrieu To cite this version: Antoine Varet, Nicolas Larrieu. Realistic Network Traffic Profile Generation : Theory and Practice. Computer and Information Science, Canadian Center of Science and Education, 2014, 7 (2), pp 1-16. 10.5539/cis.v7n2p1. hal-00955420 HAL Id: hal-00955420 https://hal-enac.archives-ouvertes.fr/hal-00955420 Submitted on 4 Mar 2014 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Realistic network traffic profile generation: theory and practice Antoine Varet1 & Nicolas Larrieu1 1 ENAC Telecom/Resco Laboratory, Toulouse, France Correspondence: Nicolas Larrieu, ENAC, E-mail: [email protected] Abstract Network engineers and designers need additional tools to generate network traffic in order to test and evaluate application performances or network provisioning for instance. In such a context, traffic characteristics are the very important part of the work. Indeed, it is quite easy to generate traffic but it is more difficult to produce traffic which can exhibit real characteristics such as the ones you can observe in the Internet. With the lack of adequate tools to generate data flows with “realistic behaviors” at the network or transport level, we needed to develop our tool entitled “SourcesOnOff”.
    [Show full text]
  • A Tool for Evaluating Network Protocols
    XIOPerf : A Tool For Evaluating Network Protocols John Bresnahan, Rajkumar Kettimuthu and Ian Foster Mathematics and Computer Science Division Argonne National Laboratory Argonne, Illinois 60439 Email: {bresnaha,kettimut,foster}@mcs.anl.gov Abstract— The nature of Grid and distributed computing user typically has one simple question. What protocol is best implies network communication between heterogeneous systems for my needs? over a wide and ever-changing variety of network environments. Answering that question on paper can be a difficult task. Often times large amounts of data is stored in remote locations and must be transmitted in bulk. It is desirable to have the bulk Many factors must be identified and considered. Every proto- data transfers be as fast as possible, however due to the dynamic col has its strengths and could be a potential candidate. There networks involved it is often hard to predict what protocol will is no single fastest protocol for every situation. The best choice provide the fastest service for a given situation. In this paper most often depends on the environment in which the users we present XIOPerf, a network protocol testing and evaluation application exists. The user must consider at a minimum the tool. XIOPerf is a command line program written on top of GlobusXIO with a simple and well defined interface to many following parameters: different protocol implementations. XIOPerf was created to give Network type: Is it a dedicated link, or does some users a way to quickly and easily experiment with an open quality of service guarantee that a portion of the ended set of protocols over real networks to determine which will bandwidth is dedicated to the user? best suit their needs.
    [Show full text]