d-itg-manual.tex0000664000175000017500000030065712255016327013455 0ustar walterwalter\documentclass{article} % - Dependencies - % \usepackage[dvips]{epsfig,graphicx} \usepackage[dvipsnames,usenames]{color} \usepackage[colorlinks=true,linkcolor=blue,urlcolor=blue,citecolor=blue]{hyperref} \usepackage[affil-it]{authblk} \usepackage[english]{babel} \usepackage[utf8]{inputenc} \usepackage{charter} \usepackage{multirow} \usepackage{url} \usepackage[top=2cm, bottom=2cm, left=2cm, right=2cm]{geometry} \usepackage{fancyvrb} %\usepackage[pdftex]{graphicx} %\DeclareGraphicsExtensions{.pdf,.jpeg,.png} % - New commands - % \newcommand{\tr}[1]{\textcolor{Red}{#1}} \newcommand{\tg}[1]{\textcolor{Green}{#1}} \newcommand{\tb}[1]{\textcolor{Blue}{#1}} \newcommand{\ver}[0]{§VERSION§} \newcommand{\rev}[0]{§REVISION§} % - New environments - % % \makeatletter \newenvironment{lyxcode}{ \begin{list}{}{ \setlength{\rightmargin}{\leftmargin} \setlength{\listparindent}{0pt}% \raggedright \setlength{\itemsep}{0pt} \setlength{\parsep}{0pt} \normalfont\ttfamily}% \item[] }{\end{list}} % \makeatother % - Title and authors - % \title{D-ITG \ver{} Manual} \author{Alessio Botta, Walter de Donato, Alberto Dainotti, \hspace{10cm} Stefano Avallone, and Antonio Pescap\'e \\ COMICS (COMputer for Interaction and CommunicationS) Group \\ Department of Electrical Engineering and Information Technologies \\ University of Napoli Federico II \\ \vspace{1cm}\url{http://traffic.comics.unina.it/software/ITG}} % - Document Body - % \begin{document} \maketitle \newpage \tableofcontents \newpage %----------------------------------------------------------------------------- \section{Overview}\label{sec:overview} D-ITG (Distributed Internet Traffic Generator) is a platform capable to produce IPv4 and IPv6 traffic by accurately replicating the workload of current Internet applications~\cite{d-itg0000, d-itg1111, d-itg3333, d-itg2222}. At the same time D-ITG is also a network measurement tool able to measure the most common performance metrics (e.g. throughput, delay, jitter, packet loss) at packet level. D-ITG can generate traffic following \textit{stochastic models} for packet size (PS) and inter departure time (IDT) that mimic application-level protocol behavior. By specifying the distributions of IDT and PS random variables, it is possible to choose different renewal processes for packet generation: by using characterization and modeling results from literature, D-ITG is able to replicate statistical properties of traffic of different well-known applications (e.g Telnet, VoIP - G.711, G.723, G.729, Voice Activity Detection, Compressed RTP - DNS, network games). At the transport layer, D-ITG currently supports TCP (Transmission Control Protocol), UDP (User Datagram Protocol), SCTP\footnotemark[1] (Stream Control Transmission Protocol), and DCCP\footnote[1]{SCTP and DCCP are currently supported only under Linux.} (Datagram Congestion Control Protocol). It also supports ICMP (Internet Control Message Protocol). Among the several features described below, FTP-like passive mode is also supported to conduct experiments in presence of NATs, and it is possible to set the TOS (DS) and TTL IP header fields. %--------------------------------------- \subsection{Architecture}\label{sec:architecture} As reported in Fig.~\ref{fig:arch}, the architecture of D-ITG comprises different components. % The main important ones are ITGSend, ITGRecv, ITGDec, and ITGLog. % Other helpful tools, also distributed with D-ITG, are ITGManager and ITGPlot. \begin{figure}[htbp] \label{fig:arch} \centering \includegraphics[width=0.5\textwidth]{fig/arch.png} \caption{Architecture of D-ITG.} \end{figure} The core features of D-ITG are provided by ITGSend and ITGRecv. ITGSend is the component responsible for generating traffic toward ITGRecv. Exploiting a multithreaded design, ITGSend can send multiple parallel traffic flows toward multiple ITGRecv instances, and ITGRecv can receive multiple parallel traffic flows from multiple ITGSend instances. A signaling channel is created between each couple of ITGSend and ITGRecv components to control the generation of all the traffic flows between them. ITGSend and ITGRecv can optionally produce log files containing detailed information about every sent and received packet. Such logs can be saved locally or sent -- through the network -- to the ITGLog component (useful to collect all the measures at a single point or in the case of hosts with limited storage capabilities – e.g., sensors, embedded devices, smartphones, etc.). The ITGDec component is in charge of analyzing the log files in order to extract performance metrics related to the traffic flows. The experiments (even large-scale ones) can be controlled from a single vantage point: the ITGRecv components act as daemons and can be completely configured and controlled by the ITGSend components that want to send traffic to them. Also the ITGSend components can act as daemons and can be remotely controlled through the D-ITG API. The ITGManager component represents an example of how to use the D-ITG API to remotely control ITGSend. This way, the user can completely control a large-scale distributed experiment from a single vantage point. \subsubsection{ITGSend: Sender Component of the D-ITG Platform}\label{ITGSend} The ITGSend component is responsible for generating traffic flows and can work in three different modes: \begin{itemize} \item \textbf{Single-flow} - read the configuration of the single traffic flow to generate toward a single ITGRecv instance from the command line; \item \textbf{Multi-flow} - read the configuration of multiple traffic flows to generate toward one or more ITGRecv instances from a script file. The script is made of a line for each traffic flow, which includes a set of command-line options as in the single-flow mode; \item \textbf{Daemon} - run as a daemon listening on a UDP socket for instructions and can be remotely controlled using the D-ITG API. \end{itemize} Every traffic flow generated is described by two stochastic processes relating to Packet Size (PS) and Internet Departure Time (IDT), through which well defined traffic profiles can be generated, emulating application protocols such as VoIP, DNS, etc.. PS and IDT series can also be loaded from a file for each flow. ITGSend can log information about every sent or received packet, when running in \textit{One Way} or \textit{Round Trip} mode respectively (see below). In the first case, timestamps (and other information) of sent packets are stored, while in the second case, timestamps (and other information) of sent and received packets are stored. For each flow the source IP address can be specified, which is useful for multi-homed hosts. \subsubsection{ITGRecv: Receiver Component of the D-ITG Platform}\label{ITGRecv} The ITGRecv component is responsible for receiving multiple parallel traffic flows generated by one or more ITGSend instances. It normally runs as a multi-threaded daemon listening on a TCP socket for incoming traffic reception requests. Each time a request is received from the network, a new thread is created, which performs all the operations related to the new request (e.g. receiving the packets of the flow). The port numbers on which ITGRecv will receive each flow and any logging activity required on the receiver side can be remotely controlled by ITGSend. A specific signaling protocol, called TSP, allows ITGRecv and ITGSend to properly setup and manage the traffic generation process. \subsubsection{ITGLog: Logger Component of the D-ITG Platform}\label{ITGLog} The ITGLog component is responsible for receiving and storing log information possibly sent by ITGSend and ITGRecv. It runs as a multi-threaded daemon listening on a TCP socket for incoming log requests. Log information is received over TCP or UDP protocols on port numbers dynamically allocated in the range [9003--10003]. \subsubsection{ITGDec: Decoder Component of the D-ITG Platform}\label{ITGDec} The ITGDec component is responsible for decoding and analyzing the log files stored during the experiments conducted by using D-ITG. ITGDec parses the log files generated by ITGSend and ITGRecv and calculates the average values of bitrate, delay and jitter either on the whole duration of the experiment or on variable-sized time intervals. ITGDec analyzes the log files produced by ITGSend, ITGRecv, and ITGLog in order to produce the following results about each flow and about the whole set of flows: \begin{itemize} \item Syntethic reports: \begin{itemize} \item Experiment duration \item Packets transferred \item Payload bytes transferred \item One-way/round-trip delay (minimum, maximum, average, standard deviation) \item Average bitrate \item Average packet rate \item Dropped packets \item Duplicate packets \item Loss events \item Average loss-burst size \item First/last sequence number \end{itemize} \item Sampled QoS metrics timeseries: \begin{itemize} \item Bitrate [Kbps] (i.e. goodput) \item One-way/round-trip delay [ms] \item Jitter [ms] (i.e. delay variation) \item Packet loss [pps] (i.e. packets lost per second) \end{itemize} \end{itemize} %--------------------------------------- \subsection{Features}\label{sec:features} D-ITG is able to generate multiple unidirectional flows from many senders toward many receivers, each of them having the following features. \begin{itemize} \item Customizable flow-level properties \begin{itemize} \item duration \item start delay \item total number of packets \item total number of KBytes \end{itemize} \item Supported Layer-3 features \begin{itemize} \item protocols: IPv4, IPv6 \item customizable header fields: \begin{itemize} \item source and destination IP addresses \item source interface binding (for multi-homed devices) \item initial TTL value \item DS byte \end{itemize} \item NAT traversal: FTP-like passive mode \end{itemize} \item Supported Layer-4 features \begin{itemize} \item protocols: TCP, UDP, ICMP, DCCP, SCTP \item customizable header fields: \begin{itemize} \item source and destination port numbers \end{itemize} \end{itemize} \item Supported Layer-7 features \begin{itemize} \item Predefined stochastic PS (Packet Size) and IDT (Inter Departure Time) profiles: \begin{itemize} \item Telnet \item DNS \item Quake3 \item CounterStrike (active and inactive) \item VoIP (G.711, G.729, G.723) \end{itemize} \item Payload content: random or read from file \item Stochastic processes supported for both PS and IDT: \begin{itemize} \item Supported distributions are Uniform, Constant, Exponential, Pareto, Cauchy, Normal, Poisson, Gamma, Weibull \item Explicit random seed selection for replicating the same stochastic process \item Loading of PS and IDT series from file \end{itemize} \end{itemize} \item Packet-level QoS metrics \begin{itemize} \item Bitrate \item Packet rate \item One way delay (requires clocks synchronization) \item Round Trip Time \item Jitter \item Packet loss \end{itemize} \end{itemize} %--------------------------------------- \section{Compiling D-ITG}\label{sec:buildingopts} \subsection{Requirements} D-ITG currently supports the following operating systems: \begin{itemize} \item Linux\footnotemark[1] (Ubuntu, Debian, Fedora, CentOS, OpenWRT, Snapgear, Montavista, uClinux) \item Windows (XP, Vista, 7) \item OSX (Leopard) \item FreeBSD\footnotemark[1] \end{itemize} \footnotetext[1]{D-ITG has been tested with the latest releases available on March 2013.} % In order to compile D-ITG you need GNU Make and gcc. Depending on the operating system, some limitations or additional requirements may apply (see \ref{par:instr}). \subsection{Building steps} \label{par:instr} Independently on the operating system, these are the high-level steps to follow: \begin{enumerate} \item download and unpack the "D-ITG-\ver{}-r\rev{}-src.zip" package somewhere on your filesystem; \item from the command line, enter the "D-ITG-\ver{}-r\rev{}/src" directory; \item type "make" to build the binaries. \end{enumerate} Once done, the binaries will be copied into the "D-ITG-\ver{}-r\rev{}/bin" directory. \vspace{14pt}\hspace{-0.6cm} In order to show the list of compile-time options available for the current operating system run: \begin{verbatim} $ make help \end{verbatim} please note that not all the options are available on all operating systems and the previous command will only show the options available for the current target operating system. For instance, to enable DEBUG mode using a specific verbosity level the "debug=$<$level$>$" option can be specified on the make command line: \begin{verbatim} $ make clean all debug= \end{verbatim} where $<$level$>$ is a positive integer value (bigger value $=>$ more verbose) and if set to 0 enables only debugging symbols without increasing the verbosity level. \subsection{OS-Specific notes} We report in the following some guidelines specific for each operating system. \vspace{14pt}\hspace{-0.6cm} \textbf{All Unix-like OSes (Linux, FreeBSD, OSX)} \begin{itemize} \item The D-ITG binaries can be installed on the system by using the root account: \begin{verbatim} # make install PREFIX=/usr/local \end{verbatim} or as normal user by using the sudo utility: \begin{verbatim} $ sudo make install PREFIX=/usr/local \end{verbatim} The same way the binaries can be removed by the system: \begin{verbatim} # make uninstall PREFIX=/usr/local \end{verbatim} or: \begin{verbatim} $ sudo make uninstall PREFIX=/usr/local \end{verbatim} If not specified, the PREFIX variable takes "/usr/local" as default value. \item The "multiport" and "bursty" options are enabled by default. They are still optional since no extensive testing has been conducted on them. Both options can be disabled at compile time respectively using the "multiport=off" and "bursty=off" options. \end{itemize} \vspace{14pt}\hspace{-0.6cm} \textbf{Linux} \begin{itemize} \item In order to enable the SCTP protocol (sctp=on option), libsctp should be installed first. This feature is supported with kernel version starting from 2.5.15. \item The DCCP protocol (dccp=on option) is supported with kernel version starting from 2.6.14-rc1. \item Windows binaries can also be built under Linux using Mingw: \begin{verbatim} $ make T=win \end{verbatim} If MinGW is installed in a standard location (e.g. /usr/i686-w64-mingw32 on Ubuntu 12.10) it will be automatically detected, otherwise it is necessary to set the MINGW variable to point to the Mingw toolchain path: \begin{verbatim} $ export MINGW=/usr/local/i686-w64-mingw32 \end{verbatim} In order to show the options available in this case do: \begin{verbatim} $ make T=win help \end{verbatim} \end{itemize} \vspace{14pt}\hspace{-0.6cm} \textbf{Windows} \begin{itemize} \item Since with Windows XP/2000 listening on both IPv4 and IPv6 sockets is not supported, we provide an "ipv4only=on" option to disable IPv6 support. Which means that normally ITGRecv under Windows XP/2000 will only be able to accept connections using IPv6. Using more recent Windows versions this option is not necessary and ITGRecv will be able to work with IPv4 and IPv6 simultaneously. \item The compilation under Windows has been tested using Dev-Cpp 4.9.9.2, which includes the Mingw 32-bit toolchain based on GCC 3.4.2. It can be compiled both using the IDE environment and Mingw from the command-line: \begin{itemize} \item Using Dev-Cpp IDE: \begin{enumerate} \item Open the "src/D-ITG.dev" project \item Uncomment the first lines of the "win-mingw.mk" file to set compile-time options, if needed \item Verify that the DEVDIR variable points to the right path of your Dev-Cpp installation \item Type CTRL + F11 to compile \end{enumerate} \item Using Mingw from the command-line: \begin{enumerate} \item Add the bin folder of Dev-Cpp to the execution path: \begin{verbatim} C:\> set PATH=\bin:%PATH% \end{verbatim} \item If you installed Dev-Cpp in the default path just do: \begin{verbatim} C:\D-ITG-VER-rREV\src> make \end{verbatim} otherwise you have to specify the right path setting the DEVDIR variable: \begin{verbatim} C:\D-ITG-VER-rREV\src> make DEVDIR= \end{verbatim} Compile-time options are supported also in this case. To list them do: \begin{verbatim} C:\D-ITG-VER-rREV\src> make help \end{verbatim} \end{enumerate} \end{itemize} \item The "multiport" option is set to "off" by default because it currently adds a delay of several seconds when starting ITGRecv.exe. \end{itemize} \vspace{14pt}\hspace{-0.6cm} \textbf{FreeBSD} \begin{itemize} \item In order to build D-ITG you have to use the GNU version of make: \begin{verbatim} $ gmake \end{verbatim} \item IPv6, DCCP and SCTP are currently not supported under FreeBSD. \end{itemize} \vspace{14pt}\hspace{-0.6cm} \textbf{OSX} \begin{itemize} \item IPv6, DCCP and SCTP are currently not supported under OSX. \end{itemize} %----------------------------------------------------------------------------- \section{Using D-ITG}\label{sec:components} In order to use D-ITG, you have to run at least ITGRecv instance to receive the traffic and one ITGSend instance to send the traffic. They simplest way to try it is to run both instances on the same host, as shown in the quickstart example. %--------------------------------------------------------------------------- \subsection{Quick start} Once obtained the D-ITG binaries, following the instructions reported in section \ref{sec:buildingopts}, you are ready to start using D-ITG. % Here we show a quickstart example in which all the components are executed on the same host and communicate using the loopback interface: \begin{itemize} \item Open a console, enter the folder containing the D-ITG binaries, and run the ITGRecv component: \begin{verbatim} $ ./ITGRecv \end{verbatim} \item Open a second console and, from the same folder, run the ITGSend component: \begin{verbatim} $ ./ITGSend -T UDP -a 127.0.0.1 -c 100 -C 10 -t 15000 \ -l sender.log -x receiver.log \end{verbatim} This way ITGSend will generate one UDP flow with constant payload size (100 bytes) and constant packet rate (10 pps) for 15 seconds (15000 ms) and two packet-level log files will be generated both on sender (-l option) and receiver (-x option) side. \item Now to analyze the logs, from the same folder, run the ITGDec component on both logs in turn: \begin{verbatim} $ ./ITGDec sender.log ... $ ./ITGDec receiver.log ... \end{verbatim} The result in both cases should be similar to the following one: {\footnotesize \begin{verbatim} ---------------------------------------------------------- Flow number: 1 From 127.0.0.1:44225 To 127.0.0.1:8999 ---------------------------------------------------------- Total time = 14.944263 s Total packets = 150 Minimum delay = 0.000000 s Maximum delay = 0.000000 s Average delay = 0.000000 s Average jitter = 0.000000 s Delay standard deviation = 0.000000 s Bytes received = 15000 Average bitrate = 8.029837 Kbit/s Average packet rate = 10.037297 pkt/s Packets dropped = 0 (0.00 %) Average loss-burst size = 0.000000 pkt ---------------------------------------------------------- __________________________________________________________ **************** TOTAL RESULTS ****************** __________________________________________________________ Number of flows = 1 Total time = 14.944263 s Total packets = 150 Minimum delay = 0.000000 s Maximum delay = 0.000000 s Average delay = 0.000000 s Average jitter = 0.000000 s Delay standard deviation = 0.000000 s Bytes received = 15000 Average bitrate = 8.029837 Kbit/s Average packet rate = 10.037297 pkt/s Packets dropped = 0 (0.00 %) Average loss-burst size = 0 pkt Error lines = 0 ---------------------------------------------------------- \end{verbatim} } \end{itemize} %--------------------------------------- \subsection{ITGSend}\label{qs:ITGSend} \subsubsection{Synopsis} ITGSend can be launched in three different modes. \begin{itemize} \item \textbf{Single-flow mode}: reads the single traffic flow to generate from the command line \begin{verbatim} $ ./ITGSend [log_opts] [sig_opts] [flow_opts] [misc_opts] [ [idt_opts] [ps_opts] | [app_opts] ] \end{verbatim} \item \textbf{Multi-flow mode}: reads the traffic flows to generate from a script file \begin{verbatim} $ ./ITGSend [log_opts] \end{verbatim} \item \textbf{Daemon mode}: runs as a daemon to be remotely controlled using the ITGapi \begin{verbatim} $ ./ITGSend -Q [log_opts] \end{verbatim} \end{itemize} \vspace{14pt}\hspace{-0.6cm} \textbf{NOTE}: launching ITGSend in background requires to redirect stdin to /dev/null. \subsubsection{Modes} \begin{description} \item[Single-flow mode] \hfill \\\\ The single-flow mode enables ITGSend to generate one traffic flow according to the specified command-line options. The flow is managed by a dedicated thread, while a separate thread is responsible for setting up and coordinating the generation process by communicating with the ITGRecv component on a separate channel. \item[Multi-flow mode] \hfill \\\\ The multi-flow mode enables ITGSend to simultaneously generate several flows. Each flow is managed by a single thread, with a single, separate thread acting as a master and coordinating the others. To generate $n$ flows, the script file has to contain $n$ lines, each of them used to specify the characteristics of one flow. Each line can contain all the options illustrated in Section~\ref{sec:ITGSendoption}, with the exception of those regarding the logging process. When using this mode, the logging options have to be specified on the command line and refer to all the flows. \item[Daemon mode] \hfill \\\\ The daemon mode allows ITGSend to be remotely controlled by using the ITGapi. When working in this mode ITGSend acts as a daemon listening on a UDP port for traffic generation requests. \end{description} \subsubsection{Options}\label{sec:ITGSendoption} {\small \begin{Verbatim}[commandchars=\\\{\}] Log options (log_opts): -l [logfile] Generate sender-side log file (default: /tmp/ITGSend.log). Generates a log file containing timing, ordering and size information about every packet sent by ITGSend. Under Windows the default log file name is "ITGSend.log". -L [log_server_address] Generate sender-side log file on a remote ITGLog instance. [logging_protocol] The first parameter sets the log server IP address (default: 127.0.0.1). The second parameter sets the transport protocol used to establish the communication between ITGSend and ITGLog: UDP or TCP (default: UDP). The name of the log file is specified by the -l option. -x [receiver_logfile] Ask ITGRecv to generate receiver-side log file (default: /tmp/ITGRecv.log). Generates a log file containing timing, ordering and size information about every packet received by ITGRecv. Under Windows the default log file name is "ITGRecv.log". -X [log_server_address] Ask ITGRecv to generate receiver-side log file on a remote ITGLog instance. [logging_protocol] The first parameter sets the log server IP address (default: 127.0.0.1). The second parameter sets the transport protocol used to establish the communication between ITGRecv and ITGLog: UDP or TCP (default: UDP). The name of the log file is specified by the -x option. -q Number of packets to push to the log at once (default: 50). Sets how many packets have to be buffered before writing them to the log file. Since the buffer is flushed (on disk or through the network towards ITGLog) after this number of packets, using a small value has impact on the generation performance. This parameter has effect also when -L and -X options are specified. Signaling options (sig_opts): -Sda Set the destination address for the signaling channel (default: equal to -a ). -Sdp Set the destination port for the signaling channel (default: 9000). -Ssa Set the source address for the signaling channel (default: Set by O.S.). -Ssp Set the source port for the signaling channel (default: Set by O.S.). -Si Set the network interface for the signaling channel (available only on Linux). Flow options (flow_opts): -H Enable NAT traversal: FTP-like passive mode As for FTP, such mode allows NAT traversal by opening every (TCP and UDP) connection (for signaling and for traffic generation) in the opposite direction (i.e. from ITGRecv towards ITGSend). When the option is enabled ITGSend waits to be contacted by ITGRecv before starting the genearation. This option is necessary when ITGRecv is behind a NAT, and it requires the -H option also at reciver side (see ITGRecv help). -m Set the type of meter (default: owdm): - owdm (one-way delay meter) - rttm (round-trip time meter) D-ITG does not provide any sort of synchronization among senders and receivers. In order to correctly measure packet One Way Delay (OWD), the clocks of sender and receiver must be synchronized by other means. Otherwise, we suggest to use the Round Trip Time (RTT) meter. -t Set the generation duration in ms (default: 10000 ms). When -t, -z, and/or -k are specified, the most restrictive applies. -z <#_of_packets> Set the number of packets to generate. When -t, -z, and/or -k are specified, the most restrictive applies. -k <#_of_KBytes> Set the number of KBytes to generate. When -t, -z, and/or -k are specified, the most restrictive applies. -d Start the generation after the specified delay in ms (default: 0 ms). -b Set the DS byte for QoS tests (default: 0). The value is interpreted as a decimal number (allowed range [0, 255]), or as an hexadecimal number using the "0x" prefix (allowed range [0, ff]). \underline{OS specific notes}: - the option is disabled under Windows 2000 and XP, according to the "Microsoft Knowledge Base Article - 248611". - Under Linux you need root priviledges to set the DS byte to a value larger than 160. -f Set the IP Time To Live (default: 64). The value is interpreted as a decimal number (allowed range [0, 255]), or as an hexadecimal number using the "0x" prefix (allowed range [0, ff]). -a Set the destination address (default: 127.0.0.1). This option applies to both traffic flow and signaling channel unless -Sda option is also specified. -sa Set the source address (default: Set by O.S.). -rp Set the destination port (default: 8999). This option applies only to traffic flows (i.e. not to signaling channel). See above for signaling channel. -sp Set the source port (default: Set by O.S.). This option applies only to traffic flow. See above for signaling channel. -i Bind to the given interface (default: don't bind to any interface). -p Select the metadata sent in the payload of each packet (default: 0). Sets the type of information sent into the payload of each packet. Valid values are: - 0 standard information is sent in the packet payload; - 1 only the sequence numbers are sent in the packet payload; - 2 no information is sent in the packet payload. -T Layer 4 protocol (default: UDP): - UDP (User Datagram Protocol) - TCP (Transport Control Protocol) Being TCP a stream-oriented protocol, the enforcement of payload sizes is not guaranteed, especially when imposing high packet rates. In this case the payload of subsequent packets could be merged and then splitted again according to the MSS value. The "-D" option may help in avoiding this phenomenon, but many pre-compiled kernels have this feature disabled and would just ignore it. - ICMP [type] (Internet Control Messaging Protocol) The default type is 8 (i.e. ECHO request). \underline{Note}: To use ICMP under Linux you need root priviledges for both ITGSend and ITGRecv. - SCTP (Session Control Transport Protocol) SCTP protocol is currently supported only under Linux. Not all the features of this protocol are supported yet. Multi-streaming is partially supported but currently disabled. The sub-option identifies the SCTP session, while the sub-option defines how many streams will be part of the session. The streams part of the same SCTP session have to be specified as separate flows with the same values for both sub-options. To enable this option D-ITG has to be compiled with "sctp" option enabled (i.e. make sctp=on). - DCCP (Datagram Congestion Control Protocol) DCCP protocol is currently supported only under Linux. DCCP is a message-oriented protocol like UDP with some new features. It implements not only congestion control and congestion control negotiation, but also reliable connection setup, teardown, and feature negotiation. DCCP is supported only under Linux. To enable this option D-ITG has to be compiled with "dccp" option enabled (i.e. make dccp=on). -D Disable TCP Nagle algorithm. This option has effect only when using the TCP protocol and should allow to better enforce the imposed payload size for each packet. \underline{Note}: many pre-compiled kernels have this feature disabled and would just ignore it. Inter-departure time options (idt_opts): -C Constant (default: 1000 pkts/s). -U Uniform distribution. -E Exponential distribution. -N Normal distribution. -O Poisson distribution. -V Pareto distribution. -Y Cauchy distribution. -G Gamma distribution. -W Weibull distribution. -Ft Read IDTs from file (in ms). The input file provided has to contain each value on a different line. -B Generate bursty traffic: Sets the duration of both ON and OFF periods according to a supported random distribution (e.g. -B C 1000 C 1000). Using this option the flow generates traffic in bursts, where the duration of ON and OFF periods can be set according to all the supported distributions. \underline{Notes}: This option has to be the last one on the command line. To enable this option D-ITG has to be compiled with "bursty" option enabled (i.e. make bursty=on). \underline{Note}: - The IDT random variable provides the inter-departure time expressed in milliseconds. - For the sake of simplicity, in case of Constant, Uniform, Exponential and Poisson variables, each parameter, say it x, is considered as a packet rate value in packets per second. It is then internally converted to a IDT in milliseconds (y -> 1000/x). Packet size options (ps_opts): -c Constant (default: 512 bytes). -u Uniform distribution. -e Exponential distribution. -n Normal distribution. -o Poisson distribution. -v Pareto distribution. -y Cauchy distribution. -g Gamma distribution. -w Weibull distribution. -Fs Read payload sizes from file. The input file provided has to contain each value on a different line, in agreement with the format of the output generated when using ITGDec with the -P option. Application layer options (app_opts): -Fp Read payload content from file. Telnet Emulate Telnet traffic. Generates traffic with Telnet characteristics. It works with TCP transport layer protocol. Different settings will be ignored. DNS Emulate DNS traffic. Generates traffic with DNS characteristics. It works with both UDP and TCP transport layer protocols. Quake3 Emulate Quake 3 traffic \cite{2}. Generates traffic with Quake III Arena characteristics. No option is required. It only works with UDP Transport Layer protocol. Different settings will be ignored. CSa Emulate Counterstrike traffic - active player \cite{1}. Generates traffic with Counter Strike characteristics related to the active phase of the game. No option is required. It only works with UDP Transport Layer protocol. Different settings will be ignored. CSi Emulate Counterstrike traffic - idle player \cite{1}. Generates traffic with Counter Strike characteristics related to the inactive phase of the game. No option is required. It only works with UDP Transport Layer protocol. Different settings will be ignored. VoIP Emulate Voice-over-IP traffic. -x VoIP sub-option: audio codec (default: G.711.1): - G.711.<1 or 2> (samples per pkt) - G.729.<2 or 3> (samples per pkt) - G.723.1 -h VoIP sub-option: audio transfer protocol (default: RTP): - RTP: Real Time Protocol (default) - CRTP: Real Time Protocol with header compression -VAD VoIP sub-option: enable voice activity detection. Generate traffic with VoIP characteristics. It only works with UDP transport layer protocol. Different settings will be ignored. The emulation of the following codecs is supported: - G.711.1: for G.711 codec with 1 sample per pkt (default) - G.711.2: for G.711 codec with 2 samples per pkt - G.723.1: for G.723.1 codec - G.729.2: for G.729 codec with 2 samples per pkt - G.729.3: for G.729 codec with 3 samples per pkt \underline{Note}: - Emulation is obtained by properly replicating packet sizes and IDTs. The payload of the application is not reproduced (i.e. bytes above transport layer have no real meaning). - Application layer options have to be specified as the last option. - If you specify an application layer protocol you cannot specify any inter-departure time, or packet size option. Misc options (misc_opts): -h | --help Display this help and exit. -s Set the seed used for generating distributions (default: random). Sets the seed for the random number generator (allowed range [0,1]). -poll Use busy-wait loop for IDTs shorter than 1 msec. This option is necessary in order to obtain better performance. By enabling it, one or more CPU cores will run at 100\% during the generation as long as IDTs shorter than 1 msec are required. -j <0|1> Guarantee the mean packet rate (default: 1): - 0 (disable) - 1 (enable) Normally, depending on the selected IDT distribution, ITGSend sleeps some time before sending each packet. It can happen that the thread responible for generating the packets wakes up in late, thus causing an average packet rate smaller than the expected one. If enabled, all the packets ITGSend was unable to send in the previous interval are sent in late in the next one in order to guarantee the expected mean bitrate. -sk Raise a signal on the serial interface when sending packets. Instructs ITGSend to raise a signal on the specified serial interface every time a packet is sent. \underline{OS specific notes}: - Typical values under Windows are COM1, COM2, etc. - Typicsl values under Linux are ttys0, ttys1, etc. -rk Ask ITGRecv to raise a signal on the serial interface when receiving packets. Instructs ITGRecv to raise a signal on the specified serial interface every time a packet is received. \underline{OS specific notes}: - Typical values under Windows are COM1, COM2, etc. - Typicsl values under Linux are ttys0, ttys1, etc. -P Enable thread high priority (available only on Windows platform). \end{Verbatim} } %--------------------------------------- \subsection{ITGRecv}\label{qs:ITGRecv} \vspace{-6pt} \subsubsection{Synopsis} \begin{verbatim} ./ITGRecv [options] \end{verbatim} \vspace{14pt}\hspace{-0.6cm} \textbf{NOTE}: launching ITGRecv in background requires to redirect stdin to /dev/null \subsubsection{Options} {\small \begin{verbatim} -h | --help Display this help and exit -P Enable thread high priority (available only on Windows platform). -a Bind data channels to a specific address. Sets the address ITGRecv has to bind to for receiving traffic flows. If the -a option is not specified, each socket is bound to the address specified by ITGSend with the -a option. -i Bind data channels to a specific network interface. Sets the interface ITGRecv has to bind to for receiving traffic flows (only available on Linux platforms). If the -i option is not specified, each socket is bound to the interface owning the address specified by ITGSend with the -a option. -Si Bind signaling channels to a specific network interface. Sets the interface ITGRecv has to bind to when listening for signaling connections (only Linux platforms). If the -Si option is not specified, ITGRecv listens on all the interfaces. -Sp Signaling channel port number (default: 9000). Sets the TCP port number on which ITGRecv listens for signaling channels. -l [logfile] Enable logging to file (default filename: /tmp/ITGRecv.log). Generates a log file containing timing, ordering and size information about every received packet. Under Windows the default log file name is "ITGRecv.log". If the -l option is specified at the ITGRecv side and the -x option is set at the ITGSend side (with different log file names), the latter option is ignored. If the -l option is not specified, each ITGSend instance may specify a different log filename by means of the -x option. -L [a:
] Enable remote logging to a remote ITGLog. [p:] [P:] The "a" sub-option sets the ITGLog server IP address (default: 127.0.0.1). The "p" sub-option sets the ITGLog server signaling port (default: 9001). The "P" sub-option sets the transport protocol used to establish the communication with ITGLog: UDP or TCP (default: UDP). The name of the log file is specified by the -l option. If the -L option is specified at the ITGRecv side and the -X option is set at the ITGSend side, then the latter is ignored. If the -L option is not specified, each ITGSend instance may specify a different log server by means of the -X option. -q Number of packets to push to the log at once (default: 50). Sets how many packets have to be buffered before writing them to the log file. Since the buffer is flushed after every this number of packets, using a small value has impact on the generation performance. This parameter has effect also when the -L option is specified. -H Enable "Passive Mode" toward the specified ITGSend instance. This mode allows to receive traffic flows from an ITGSend instance when ITGRecv is behind a NAT. When enabled, ITGRecv does not run as a daemon. Instead it tries to establish a signaling channel towards the specified ITGSend. The related data flows are also initiated by ITGRecv in order to correctly setup the NAT to receive the incoming traffic. Note that this option allows to send and received only one set of flows. ITGRecv exits after receiving the last flow of the set. -n Number of outgoing packets for UDP NAT traversal When in passive mode, this option sets the number of UDP packets to send from ITGRecv towards ITGSend to instruct the NAT before receiving the UDP traffic flow from ITGSend. This option does not apply to TCP traffic flows, as the three-way handshake of TCP is sufficient for instructing the NAT. \end{verbatim} } %--------------------------------------- \subsection{ITGLog}\label{qs:ITGLog} \subsubsection{Synopsis} \begin{verbatim} ./ITGLog [options] \end{verbatim} \vspace{14pt}\hspace{-0.6cm} \textbf{NOTE}: launching ITGLog in background requires to redirect stdin to /dev/null \subsubsection{Options} {\small \begin{verbatim} -h | --help Display this help and exit -q Number of packets to push to the log at once (default: 50) Sets how many packets have to be buffered before writing them to the log file. Since the buffer is flushed every this number of packets, using a small value has impact on the generation performance. This parameter has effect also when the -L option is specified. \end{verbatim} } %--------------------------------------- \subsection{ITGDec}\label{qs:ITGDec} \subsubsection{Synopsis} \begin{verbatim} ./ITGDec [options] \end{verbatim} \subsubsection{Options}\label{sec:DecOpt} {\small \begin{verbatim} -v Print standard summary to stdout (default). Prints to stdout a summary comprising a set of statistics about each flow and the whole set of flows. -l Print to the decoded log in text format. Generates the output log file in text format. For each packet the log file contains a line with the following fields: - Flow: the flow number - Seq: the sequence number of the packet - Src: the source IP address and port number (e.g. 127.0.0.1/44225) - Dest: the destination IP address and port number (e.g. 127.0.0.1/8999) - txTime: the transmission time (e.g. 8:23:52.874105) - rxTime: the reception time (e.g. 8:23:52.874105) - Size: the size of the packet payload in bytes -t Interpret as in text format. The input log file is considered to be in text format as generated by using the -l option. If not specified the input log file is considered to be in binary format. -o Print to the decoded log for Octave/Matlab import. Generates the output log file in a format that can be directly imported from Octave/Matlab for further analysis. The output log content is the same as the one generated by the -l option. -r Generate combined log file starting from receiver- and sender-side log files [combined_log] (default filename: 'combined.dat'). Generates the binary log file starting from a receiver-side log file, given as parameter, and the corresponding sender-side log file. This is useful when ITGSend is launched with the "-p" option having a value different from 2, because it does not insert into each packet the transmission timestamp. Using this option, this timestamp is recovered from the log file generated by ITGSend. -d
[filename] Print average delay to file every
milliseconds (default filename: 'delay.dat'). Dumps to file the average packet transmission delay in milliseconds as sampled every
milliseconds. The first line of the output file represents the table header. The following lines represent the table rows and comprise the follwing columns: - the "Time" column contains a time reference; - the following columns, labelled as "--", contain the average value for each flow; - the "Aggregate-Flow" column contains the aggregate average delay. -j [filename] Print average jitter to file every milliseconds (default filename: 'jitter.dat'). Dumps to file the average packet jitter in milliseconds as sampled every milliseconds. The file format is the same as the one produced with the "-d" option. -b [filename] Print average bitrate to file every milliseconds (default filename: 'bitrate.dat'). Dumps to file the average bitrate in Kbit/sec as sampled every milliseconds. The file format is the same as the one produced with the "-d" option. -p [filename] Print average packet loss to file every milliseconds (default filename: 'packetloss.dat'). Dumps to file the average packet loss in packets/sec as sampled every milliseconds. The file format is the same as the one produced with the "-d" option. -c [filename] Print all average metrics to file every milliseconds (default filename: 'combined_stats.dat'). Dumps to file all the average metrics as sampled every milliseconds. Each line of the output file respectively contains the follwing fields: - "Time", "Bitrate", "Delay", "Jitter", "Packet loss" -s [suffix] Generate a separate log file for each flow adding a suffix to its name (default suffix: log). The input log file is split in N separate log files, where N is the number of flows detected in the log file. Each resulting log file will have the following filename format: "--..dat". If not provided, the default value for suffix is "log". -f Consider only flows with number <= . Setting to 't' all packets are considered as part of the same flow. If is a number, only the flows with flow number less or equal than will be considered. If is set to "t" all the packets will be considered as belonging to the same flow. -P Print to stdout the size of each packet. -I Print to stdout the inter departure time between each packet pair. -h | --help Display this help and exit. \end{verbatim} } \subsubsection{Notes} D-ITG log files consist of a set of records (one for each packet) including the following fields: \begin{itemize} \item \texttt{Flow}: the flow number \item \texttt{Seq}: the sequence number of the packet \item \texttt{SrcIP}: the source IP address \item \texttt{SrcPort}: the source port number \item \texttt{DestIP}: the destination IP address \item \texttt{DestPort}: the destination port number \item \texttt{txTime}: the transmission timestamp \item \texttt{rxTime}: the reception timestamp \item \texttt{Size}: the size of the packet payload in bytes \end{itemize} \vspace{14pt}\hspace{-0.6cm} The values reported in the standard summary are computed according to the log records as follows: \begin{itemize} \item the \textit{Total time} is computed as the difference between the \texttt{rxTime} of the last and the first packet. \item the \textit{Delay} is computed as the difference between rxTime and txTime of each packet. \item the \textit{Delay standard deviation} ($\sigma$) is computed according to equation \ref{eq:stddev}: \begin{equation} \sigma=\sqrt{\frac{1}{N}\sum^{N}_{i=1}\left(d_i-\hat{d}\right)^2} \label{eq:stddev} \end{equation} where $N$ is the number of considered packets, $d_i$ is the delay of packet $i$, and $\hat{d}$ is the average delay of packets. \item the \textit{Jitter} is computed according to Figure~\ref{fig:jitter}, where S$_i$ and R$_i$ respectively correspond to \texttt{txTime} and \texttt{rxTime}. \begin{figure}[htbp] \centering \includegraphics[width=0.5\textwidth]{fig/jitter.png} \caption{Jitter calculation formula.} \label{fig:jitter} \end{figure} \end{itemize} \vspace{14pt}\hspace{-0.6cm} The physical meaning of the metrics reported by analyzing the log files varies depending on the metric selected (One-Way or Round-Trip) when conducting the experiment and on the component that generated the log file (ITGSend or ITGRecv): \begin{itemize} \item A log file generated (locally or remotely) by ITGSend by using the One Way Delay Meter ("-m owdm" option) has for each packet the txTime and rxTime values both set to the transmission time. Hence, \textit{delay} and \textit{jitter} should always have null value. \textit{Packets dropped} should also be normally null, except for special cases or errors (e.g.~socket buffer full, lost log packets, etc.). \item In a log file generated (locally or remotely) by ITGSend by using the Round Trip Delay Meter ("-m rttm" option), the txTime and rxTime are both set by ITGSend, when transmitting the packet and when receiving the reply from ITGRecv respectively. Hence, the \textit{delay} value represents the \textit{round-trip delay} and the \textit{jitter} value represents the \textit{round-trip delay variation}. In this case, \textit{Packets dropped} refers to all the packets lost on the round-trip path (i.e.~accounts both lost packets and replies). \item A log file generated (locally or remotely) by ITGRecv has the txTime set by ITGSend when transmitting the packet and rxTime set by ITGRecv when receiving the packet. Hence, the \textit{delay} value represents the \textit{one-way delay} and the \textit{jitter} value represents the \textit{one-way delay variation}. In this case, \textit{Packets dropped} refers to packets lost only on the one-way path (i.e. from ITGSend to ITGRecv). \end{itemize} \vspace{14pt}\hspace{-0.6cm} \textbf{IMPORTANT!} D-ITG does not provide any sort of synchronization among its components. In order to correctly measure the One Way Delay (OWD), the clocks of the host running ITGSend and ITGRecv must be synchronized by some means. Depending on the required accuracy, NTP, GPS, or other means can be used. In the case of synchronization issues we suggest to use the Round Trip Time (RTT) meter. %--------------------------------------- \subsection{ITGplot}\label{qs:ITGplot} ITGplot is an Octave (\textit{http://www.octave.org}) script that enables to draw plots using data contained in delay.dat, bitrate.dat, jitter.dat or packetloss.dat (see Section~\ref{sec:DecOpt}). The plot is saved (in the EPS format) in a file having the same name as the input file and the .eps extension. It is possible to save the plots in other formats by changing the \texttt{graphicformat} string in ITGplot. The available formats are those provided by gnuplot (run gnuplot and type `set term' to see the list of the available terminal types). It is also possible to give a title to the plot by setting the environment variable DITG\_PLOT\_TITLE. \subsubsection{Synopsis} \begin{verbatim} octave ITGplot [flow_set] \end{verbatim} \subsubsection{Options} {\small \begin{verbatim} The .dat file containing the data to be plotted. It might be one of the .dat files produced by ITGDec. [flow_set] The subset of flows to be plotted, expressed in the Octave notation. Thus, "2:4" allows to plot the second, the third and the fourth flows, while "[1 3 5]" allows to plot the first, the third and the fifth flows (remember: double quotes are needed to enclose values containing blanks). If not specified, all the flows are plotted. \end{verbatim} } \subsubsection{Notes} \paragraph{Unix-like operating systems.} It is possible to make ITGplot an executable Octave program by following these steps: \begin{enumerate} \item add execution permissions to ITGplot (\texttt{chmod +x ITGplot}) \item locate your Octave interpreter (\texttt{which octave}) \item write such location in the first line of ITGplot (e.g. \texttt{\#! /usr/bin/octave -qf}) \end{enumerate} Then, you can directly execute ITGplot (e.g. \texttt{./ITGplot bitrate.dat 1:4}). \vspace{14pt}\hspace{-0.6cm} If you want to set a title for the plot, you can use the \texttt{env} command: \begin{verbatim} env DITG_PLOT_TITLE="A wonderful plot" ITGplot bitrate.dat "[1 4 6]" \end{verbatim} \paragraph{Windows operating system.} First, since ITGplot uses gnuplot to draw plots it is necessary to specify the path to the gnuplot executable (pgnuplot.exe), which should be ``C:$\backslash$Program Files$\backslash$GNU Octave \textit{version}$\backslash$bin''. The path Octave will search for programs to run can be specified in three different ways: \begin{enumerate} \item using the \texttt{--exec-path} command line option: \begin{verbatim} octave --exec-path "C:\Program Files\GNU Octave VERSION\bin" ITGplot bitrate.dat \end{verbatim} \item setting the OCTAVE\_EXEC\_PATH environment variable: \begin{verbatim} set OCTAVE_EXEC_PATH="C:\Program Files\GNU Octave VERSION\bin" \end{verbatim} \item defining the EXEC\_PATH variable in the \texttt{octaverc} startup file: \begin{verbatim} edit "C:\Program Files\GNU Octave VERSION\opt\octave\share\octave\site\m\startup\octaverc" EXEC_PATH="C:\\Program Files\\GNU Octave VERSION\\bin" \end{verbatim} \end{enumerate} % Clearly, after applying methods 2 or 3 there is no need to use the \texttt{--exec-path} command line option. \vspace{14pt}\hspace{-0.6cm} If you want to set a title for the plot, you can type: \begin{verbatim} set DITG_PLOT_TITLE="A wonderful plot" \end{verbatim} % before executing ITGplot. %--------------------------------------- \subsection{ITGapi}\label{qs:ITGapi} ITGapi is a C++ API that enables to remotely control traffic generation. For this purpose, after having launched ITGSend in daemon mode (ITGSend --Q) on one or more traffic source nodes, it is possible to use the following function to remotely coordinate the traffic generation for each ITGSend instance: \begin{verbatim} int DITGsend(char *sender, char *message); \end{verbatim} % where: \begin{itemize} \item \texttt{sender} is the IP address of ITGSend. \item \texttt{message} is a string containing the set of options you would pass to ITGSend on the command line. \end{itemize} % The function may return one of the following values: \begin{itemize} \item \textbf{0} in case of success; \item \textbf{-1} otherwise; \end{itemize} \vspace{14pt}\hspace{-0.6cm} ITGSend, when used in daemon mode, sends messages back to the application that issued the generation of the traffic flow. Two types of messages are used, one to acknowledge the start of the generation process and the other to notify its end. The following functions allows to catch these messages: % \begin{verbatim} int catchManagerMsg(char **senderIP, char **msg); \end{verbatim} % where: \begin{itemize} \item \texttt{senderIP} is a pointer to a string containing the IP address of the sender that sent the message. \item \texttt{msg} is a pointer to a string containing the command that the sender received. \end{itemize} % The function may return one of the following values: \begin{itemize} \item \textbf{1} to indicate the start of the generation; \item \textbf{2} to indicate the end of the generation; \item \textbf{-1} in case no message has been received (the function is non blocking). \end{itemize} \vspace{14pt}\hspace{-0.6cm} The above mentioned prototypes are declared in the \texttt{ITGapi.h} header file. D-ITG includes ITGManager.cpp, which is just a simple example of application based on ITGapi to remotely control traffic generation. %------------------------------------------------------------------- \newpage \section{Examples} \label{Example} All the usage examples reported in this section assume that the binaries are being executed from the folder containing the D-ITG binaries. %--------------------------------------- \subsection{Example \#1} Single UDP flow with constant inter-departure time between packets and constant packets size: \begin{enumerate} \item start the receiver on the destination host (10.0.0.3): \begin{verbatim} $ ./ITGRecv \end{verbatim} \item start the sender on the source host (10.0.0.4): \begin{verbatim} $ ./ITGSend -a 10.0.0.3 -sp 9400 -rp 9500 -C 100 -c 500 -t 20000 -x recv_log_file \end{verbatim} \item The resulting flow from 10.0.0.4 to 10.0.0.3 has the following characteristics: \begin{itemize} \item the sender port is 9400 \item the destination port is 9500 \item 100 packets per second are sent (with constant inter-departure time between packets) \item the size of each packet is equal to 500 bytes \item the duration of the generation experiment is 20 seconds (20000 milliseconds) \item at receiver side ITGRecv creates a log file named recv\_log\_file \end{itemize} \end{enumerate} %--------------------------------------- \subsection{Example \#2} Single UDP flow in passive mode with constant inter-departure time between packets and constant packets size: \begin{enumerate} \item start the sender on the source host (192.168.0.4): \begin{verbatim} $ ./ITGSend -H -C 10 -c 50 -t 10000 -l send_log_file \end{verbatim} \item start the receiver on the destination host (10.0.0.3), potentially sitting behind a NAT: \begin{verbatim} $ ./ITGRecv -H 192.168.0.4 \end{verbatim} \item The resulting flow from 192.168.0.4 to 10.0.0.3 has the following characteristics: \begin{itemize} \item both source and destination ports are automatically selected \item 10 packets per second are sent (with constant inter-departure time between packets) \item the size of each packet is equal to 50 bytes \item the duration of the generation experiment is 10 seconds (10000 milliseconds) \item at sender side ITGSend creates a log file named send\_log\_file \end{itemize} \end{enumerate} %--------------------------------------- \subsection{Example \#3} Single TCP flow with constant inter-departure time between packets and uniformly distributed packet size between 500 and 1000 bytes with local sender/receiver log \begin{enumerate} \item start receiver on the destination host (10.0.0.3): \begin{verbatim} $ ./ITGRecv -l recv_log_file \end{verbatim} \item start the sender on the source host: \begin{verbatim} $ ./ITGSend -a 10.0.0.3 -rp 9501 -C 1000 -u 500 1000 -l send_log_file \end{verbatim} \item terminate ITGRecv by pressing Ctrl-C \item decode the receiver log file on the destination host: \begin{verbatim} $ ./ITGDec recv_log_file \end{verbatim} {\footnotesize \begin{verbatim} ---------------------------------------------------------- Flow number: 1 From 10.0.0.4:34771 To 10.0.0.3:9501 ---------------------------------------------------------- Total time = 10.001837 s Total packets = 10000 Minimum delay = 3633.445701 s Maximum delay = 3633.464808 s Average delay = 3633.449749 s Average jitter = 0.000706 s Delay standard deviation = 0.001364 s Bytes received = 7498028 Average bitrate = 5997.320692 Kbit/s Average packet rate = 999.816334 pkt/s Packets dropped = 0 (0.00 %) ---------------------------------------------------------- **************** TOTAL RESULTS ****************** Number of flows = 1 Total time = 10.001837 s Total packets = 10000 Minimum delay = 3633.445701 s Maximum delay = 3633.464808 s Average delay = 3633.449749 s Average jitter = 0.000706 s Delay standard deviation = 0.036939 s Bytes received = 7498028 Average bitrate = 5997.320692 Kbit/s Average packet rate = 999.816334 pkt/s Packets dropped = 0 (0.00 %) Error lines = 0 \end{verbatim} } Note: see the very large delay values caused by absence of clock synchronization! \item decode the sender log file on the source host: \begin{verbatim} $ ./ITGDec send_log_file \end{verbatim} {\footnotesize \begin{verbatim} ---------------------------------------------------------- Flow number: 1 From 10.0.0.4:34771 To 10.0.0.3:9501 ---------------------------------------------------------- Total time = 9.999002 s Total packets = 10000 Minimum delay = 0.000000 s Maximum delay = 0.000000 s Average delay = 0.000000 s Average jitter = 0.000000 s Delay standard deviation = 0.000000 s Bytes received = 7498028 Average bitrate = 5999.021102 Kbit/s Average packet rate = 1000.099810 pkt/s Packets dropped = 0 (0.00 %) ---------------------------------------------------------- **************** TOTAL RESULTS ****************** Number of flows = 1 Total time = 9.999002 s Total packets = 10000 Minimum delay = 0.000000 s Maximum delay = 0.000000 s Average delay = 0.000000 s Average jitter = 0.000000 s Delay standard deviation = 0.000000 s Bytes received = 7498028 Average bitrate = 5999.021102 Kbit/s Average packet rate = 1000.099810 pkt/s Packets dropped = 0 (0.00 %) Error lines = 0 ---------------------------------------------------------- \end{verbatim} } \end{enumerate} %--------------------------------------- \subsection{Example \#4} Single TCP flow with constant inter-departure time between packets and uniformly distributed packet size between 500 and 1000 bytes with remote sender/receiver log: \begin{enumerate} \item start the log server on the log host: \begin{verbatim} $ ./ITGLog \end{verbatim} \item start the receiver on the destination host: \begin{verbatim} $ ./ITGRecv \end{verbatim} \item start the sender on the source host: \begin{verbatim} $ ITGSend -a 10.0.0.3 -rp 9501 -C 1000 -u 500 1000 \ -l send_log_file -L 10.0.0.3 UDP -X 10.0.0.3 UDP -x recv_log_file \end{verbatim} \item close the receiver by pressing Ctrl+C \item close the log server by pressing Ctrl+C \item decode the receiver log file on the log host: \begin{verbatim} $ ITGDec recv_log_file \end{verbatim} {\footnotesize \begin{verbatim} ---------------------------------------------------------- Flow number: 1 From 10.0.0.4:34772 To 10.0.0.3:9501 ---------------------------------------------------------- Total time = 9.993970 s Total packets = 9997 Minimum delay = 3633.432089 s Maximum delay = 3633.504881 s Average delay = 3633.436616 s Average jitter = 0.000795 s Delay standard deviation = 0.004083 s Bytes received = 7495843 Average bitrate = 6000.292576 Kbit/s Average packet rate = 1000.303183 pkt/s Packets dropped = 2 (0.00 %) ---------------------------------------------------------- **************** TOTAL RESULTS ****************** Number of flows = 1 Total time = 9.993970 s Total packets = 9997 Minimum delay = 3633.432089 s Maximum delay = 3633.504881 s Average delay = 3633.436616 s Average jitter = 0.000795 s Delay standard deviation = 0.063898 s Bytes received = 7495843 Average bitrate = 6000.292576 Kbit/s Average packet rate = 1000.303183 pkt/s Packets dropped = 2 (0.00 %) Error lines = 0 ---------------------------------------------------------- \end{verbatim} } \item decode the sender log file on the log host: \begin{verbatim} $ ITGDec send_log_file \end{verbatim} {\footnotesize \begin{verbatim} ---------------------------------------------------------- Flow number: 1 From 10.0.0.4:34772 To 10.0.0.3:9501 ---------------------------------------------------------- Total time = 9.999001 s Total packets = 10000 Minimum delay = 0.000000 s Maximum delay = 0.000000 s Average delay = 0.000000 s Average jitter = 0.000000 s Delay standard deviation = 0.000000 s Bytes received = 7498028 Average bitrate = 5999.021702 Kbit/s Average packet rate = 1000.099910 pkt/s Packets dropped = 0 (0.00 %) ---------------------------------------------------------- **************** TOTAL RESULTS ****************** Number of flows = 1 Total time = 9.999001 s Total packets = 10000 Minimum delay = 0.000000 s Maximum delay = 0.000000 s Average delay = 0.000000 s Average jitter = 0.000000 s Delay standard deviation = 0.000000 s Bytes received = 7498028 Average bitrate = 5999.021702 Kbit/s Average packet rate = 1000.099910 pkt/s Packets dropped = 0 (0.00 %) Error lines = 0 \end{verbatim} } \end{enumerate} %--------------------------------------- \subsection{Example \#5} If you want to simultaneously generate more than one flow, you have to prepare a script file like those shown in the following examples. Three UDP flows with different constant bit rate and remote log: \begin{enumerate} \item start the log server on the log host: \begin{verbatim} $ ./ITGLog \end{verbatim} \item start the receiver on the destination host: \begin{verbatim} $ ./ITGRecv \end{verbatim} \item create the script file: \begin{verbatim} $ cat > script_file < script_file <4AbKGDH pHYsHHFk>nIDATx#םǣLB2 HK2Ld1g.3#όݨPSXaPeٻ[#h,K>eٝMfޕʉdK>r/wTիBxUޫ, ff,1;G'\YZxur/=&r"c* Bp+[>(U e6V\7㵦Qx3? adr/,\ ʲ< uYx ,!\k.77af}F7n-UrcFy.,,xA ~ ѢrYr2#&8{ɰd,ňuyE|=mn8M{䚌~ T%1"q cn,zN3jȫUUHB-[ nO9fizT A\2S+.ݜ\nph5V.Ǽ w^Qͤvt=pDhV犘9 #)sُjdNZx3"YâYXt 1F~T &\T0wP0Bω9Efvyoy _2|Xr|ׂ_NP,OmE#xeD9l?s d]kiWU, Kn0)(k-Llܣ_2uסYf.ýÍ^pEb:dVl7=YB #i旡C$KW\/,yWˆf\b`)̹ͪBl.*)@ |Jg:}N"\7an.^u3 8'z 4ƹ(2\Fޘ*ԁܳWD8SMԯÏV=!-1͟ن9E&ph2p-A6_ z F2{E#TNY"Ēskӽh%UI]a@YZ5bd '5;|@oО*~Eia։, nd~b:x0EWJ?fpR̠F/K7d%6 5BV'|=yN+ϥ ҃YHQܐ'¹?g%0ú.kI N.6 xXN 5`2$Q`\@]4fU`N,F=O`hhNCnA ,-_R채>]Z߿+S% \Uo{bH&ׯ)T w^(܈YЪtZT9gztq rOq\O?cvQS:WТ'^\[ι%.NQ ]թ{ f:7efϓ#NYs9g2FYܢ-\tV]8U\rٞ)9D:U}1 N~p÷h⸃|˷a?N~stAB. 9t92dt^%Q̜!)ނ14ƢŊ_qO|P7:^֋РtJ02g,{ q;/U lD[Q״V0bNU7%WЀYڊM.YfB:f.4Or1Ĩ:n(z!1H>eFN_ϸA ZwБyfi{i A=hWLovWu%Dl{G!t0/Dr]@÷&x{\ Bpo2''LXE-/D 1+;7X=_ Ȧ^Sh dS8bIu0m9lʀ@npf|+K.$|!Qe9CKL7ځWy LZ^,߂:,p?DF[7W!#s c%-@:d$P}@@6t34-JsI,8MXn> ?|Vn F%dtGe9>懇t3b,5!C}@7I A@6ytÍ H+t~/$mVVs_,.P2ӇneV 膏+On^ŝߜ{n$ߏf*OY= M|Po8T}L"MmߡWtSWݚ ABǔ Cn΃n$uS/ȗHw\FO%_7hl8L,Į &7/`M2@sJ:$5-'|h˴tSȆ6Rkc$Ph˴t)ِM&ЍXpo?OOU7М Ȝ ]S&nMtkߪ!x88KWt7ܺy@Gy:}_xE1bD(;LgQ\P\kB&(|ѳEI*,N\ͪPth`ws{Y3"Fo#rg^# do웴U.[_;èa, jn&nk X2(y֟<qRdx3G;%V8U>F:77<im\@7z^7x!M%vQF㧽?Ç>x-9N9Λ qtZe;'\DEt9ug&/3þ"tT]Xhloy($sj$7<;(Mj<FO/?^7T8› [Q#t$ ћԺaU>>lÇgIYn$ o|Cq?,\3t7u9/t/< !ƉPvR7{G4)Kb0/rЍޤ S6G ݅3Ϣgúws߻aE'9sB݌ эX SpFXլ6 uY̾hozZ@7!|5Z7uuC~:q..{ٷYLH7&Bu }fy:;-G]FxTz>0n9 % x~ {FH"nP|rU=ݘz5!{Ь #6q3íbz׫ziz8F髊/d1>^̃ég< Gew^E'«!#tC-%m^T7=q)\j>y:ݎp6rdžWKұ nZX6ܠC8kLiUv3́M2~֠xt4&|1_\|ct+2-C)G"0SӬ" lAx;KtqT ǥaA`{@!#pd[,' G7k&MX77E 4}󭛡ރ4^tK7j`DZN<]R>V oCwFnҵ}tMiteG4/%rcUW R.V}l P|[VC$si5BwcdF >t#`f!3Uq. (_Bs#})ϺO %n^wP[]=rT T.OBw4%:*ՍcZIEqiV;)$8E4覛۸5u jDXBnPG}ksa7CMInNqn q#FAM:nzCTwb%gbG7a8:C;]eD&t7VE'ꮈD@7 ?/cJ?uGt]3KK?[7]WX])Z7s|w` -kꋢO7c N$uЛ"`0=S= c11I}(V/Z7mnP泟G>%-[usƛbIuK8,nPax n̪!݄ unhX7loo)<ésKJpYUhJۘBI #s ":U妠n@76m )p/.8.n%@v.bV5݄ؿ-V @7`vBw[xx(Y[f J Z0jnp]p`eբu]г4f:DuàT7d|aLS 7e-k̩6;3PSe~p&twϟY @7Y6d3 Mդ*h ЅlZuA5uMKkSLA荦Y1KeN9Ot3AHbMvzwwhc;E"@7zn8''Kz\8WD;D ݈g`$ wt7sʗF rI5+cAn.iPiѱM@7C{)[;X8y]JuC׭K#IfW7{]IuMNBnd~@7zn~|~^պz jIUCu3xqq3i;*OYy(֍xP&t3Ez]Q8 m)ЍR7~R|7$@7*/kb-B.uю &Ion.2rS7y#3tP^Ɠ8S7͙!&~o8bdG׍M>ubU_j@7JzXr&YQtᘊN FsfsY7e?TKrS7"aocvP(;iT|Bdn@7IpM!r1sCpo2GuMv!@ -&>qGrt$ wBsd-$ ΢oeNS(TY)Fûn0*c5'ws'sbfE_|ɔofwL0+I{óC!MꋯK],k'+O&%>s 1D'sXs1哙Mt,i7.>@KVFVݞr{-ƹvqq-,07_' Y P9z ZwrlSmdd> F17/ O_\O3)pNlD]Ϡ ӳa4=gO FL:I:I !QrIo&/. (9?Q矍;(wBq5oIQ\,WTIӁաsE.ʟqT[)GwgMf>'VvGS? %k/O6mէ7";6YGLgi_xny}9g~~OTLX(V-<78K}'e7X|g;Qm<ﮙIY\<{c*YY~Qf-ΞϬ*ZS0NU\<@ٌVec9`c5}_T7g@k/OU\;٬q_9@fm5q |9M֡t)կa$YMlgBˋ/o+.Ӹf9sEőQe6=;j78ysJꛬo1㠽H#uMSr훥Tc5ɚn;uQEuRyZ̧oR,0laXw=S}FɺquX,;(dtc57Kvgx )ugUWؤid>X}{z^9׾I9VG]lZT199r'3vߋdOɧ/ٝ8A6y Y<Ns*cG1 O_9Mɻ~'7m{}S)jli9yqVuB3`BQ3WEp1׾I7VXQݸhkLqBpf5CUԹMo*m~ Cdu-q IlJ|X\&7Nx]wxLx\z}ra~ܼY월Shf6u%n_(E;;v 7S.Iݜ)[%C=Q_T}z&QݲřP}IYkt}é54go6d7 ᒫKF!I7~ .M0w25\2M.mr&QM(qYLBkSK9MʙDgO7 0.4FNm9[x1<> 8aA"k"Us eTtnM&{Ҝ{k"]s~)BE . 0jNmꕽɘn q ۊ:)N+j-osjNvI , kIelf:ִTS›f6$nxyu|OxyMVMwsN@'9&Ǝ iSZ7]8Y.^=[-X κvԞF 0 4 ]qZķP@7T@~@{rx4o3uIϦ\fj+$Y['MsJ2߽3jʇEu #9 lcS5*.&JׂlTSå„o wI3QqYdE7003K{Ʊ>qԜztNeB7t<}sRRB1[4&{#2<.3w`A(r+u+Hvkitp݌ܝ >?qDܵmgࢢ{ 79lhށϐnj`"fiN]Q}dB"E֖NadX%>oT0X5k$}rSbhdKBN3mت}nBrrδ`f,r4qqٶ IԔ>&L[Kot^e6X).țoL[I2l۶us5q}usJb -ƃ0>ܐ3$ˠmuql!U#|,>h\V94CW>qs^覤 囄2T*ZG&ޏ̍ ̖m+:Uպ.i >5\t${HbDo;tN ˧Eov #(M832ŜضmE (^"|c 7sZE-^]5'X7Ř~~;w8:{rŊu^) icoԡ\bݜc XNoNl~NK\ǻܝQ${(qXA:snN)V7tʊr;owT9k ]B>:utWQrjuCk2q^;<562;n3ngc&;)_r:p~:q_lK1;ՠv< yZ$|Tw0rymf)5|85\&;|TyDǭ,N_>.ɋJ7Y *OueB/*U0אַd6 kd#뭩8ӞbafnB#L6B` dk o=)or̿yqo7'ۑY`Tkd{C_Lq7EPE6Kv9w_y%owk-uo!fI6#.eD{02Y]o<&|6`kّوs[ ;8nٚJSPauUq{ԐsVL0`-˭Y}2)nfֳ"2p:͌4ʰF gE6$4KN{'sS͵+3*ͺˆ1VNX.1_h->iިI.fC6duWf:*f"-0v/qJJU+de]AT!C2ښ⛶biyU o 0O7'?\jp7*+5U[J[?Yk ol{{gfBv*q꾾@ oT0v)Y(XzZtj,jA=8=MFZ@a7TZf)PHbL# h;vV@@7wگ>M%8}2SS>Ox:3a)Ѝ^5@6ހnlX7\~("ЍNlDLj!a dͮ!('5ې0ye 9A?$L4abЍ>l]u c ,^\\s7F[W!!݇c@fǏ7~7b cRffWnj-4zx|GŵnO7(EnbS7jnRn{ LW'G7ϿLyЍ2n^y1nƍdTM%Ѝ2@7$͸R?Ѝ*@7pD7oT_1S>@7pH7s'-?"tFNHnTQ膓d>r\8F)pe`4_#_dY&7F)}1xLt3seTe-rLQ&tssTeqɶw|LQ&t32Y >%nbR7 QA7t5V\QK畗IQvqq]G.莚Ken8,N Ѝ:@7It '"tZSˉЍ:@7Mdkj| j셷@7MdkJt7>@787Yo:"0oݠ40 KxMݜ >Ɖ#cd+Mr"nO`q' t1n8MWpsn tASoުLK7H6Ɖ+5lp`Nq%]/ds V(N^4莚KtCeD6Όp"^7L膏8~!^AiH@7|fcf2Lxah 'ts%<*||PIin #nD 'C I71:>d{p2fUau} n-`6Dn‹*p£l7#.~8_ ny2g0֣7D3dD tÉ̄K7u(膏ɺ G ]gc.>&X7`.Yэqn8аmfn&^CCvἈސ3݄5n8P_Nn 'tv*pA7Cc@7LC71^7'\Qtۏ a!Άln8BA7|LnV]:f-;^s3JwVaN4Uu:{@\YDn@7 o+43vTM Yin?5¿ e~?I6ndf&T5Š^B&6Q6n;jj߶w|ܠ>81sT?Q6nfak˶|ܠ>hf498I7b tK (|@x3 ܜLqn8tC@7Ě^xrtÍ|ة0nx77 Ʋ! 7u6S $n\h>bVxdFnfA7 7p"]7i3ŠN ›n8d>J tSp"ضJtGBp"C77Cm{;G #و~4n8W[]JQnȖnWVO#OV3+ '2tî6S $;YY3rSG:aڀn8[Lx'eM1膗LfcmYwnZtÉݰVlNQn_7kw&r꓍ g&K]Es qiuMUo=R tÉx,]eR7Ƕ}nBi0Ztn mX6N nn-l~ʏtÇƺYa5eǽUTp"\7(YvH_uE[0Sz]ҽTjϝ 'uȮ~>uDSݜ߉L6gE$nf6ݸ`W=%=uM,5A-ѿE$nfo my5TS3^ԍe'+ҟ\@7$"qYvb" iBnQ7tN亙%ݬ=eǏ^ Ηы/m*_x$܂#k!۠nR>I4ѡIc'呩ɂs\oNDYFa#,͇l3s:u#K7oTx5W·^6_}^};eJO7N+Q2HI],² 45l1H _ o}W?W?Y=" J7$oKgEEn%!yErwΡ^/qu4Oe n#\\oMH4*RPݜۤaK}#_7|K5|kgUrևx!! fE[? r} ki'> ܔW2P缐Z{M㾉? |ƍ2(ȹ5TO._Jd^`X2(ΫSI^g)npS!YO) nvrTet=1MP2.û_sHz,]`n1^*)/n4~#~޻o/8/쥗 JEV7X/'Hhv7p-7i獢 Sc;04muuuEV_fn܏qC>Z()%'nM/?8#:іni>r+7H-0PA sA%7FNYC`JջΊt _f~* p1%UnQFnշ^yyu`t:PmP7ХwƉI;9w<~G3A sL}Iݐ-$7O *.t*~N_7n1!z^ tw#|]psM8L|]AnPXosCYo:N1V[*M:>jH{vz5LB[ G7ʽqi=_4?zhdzq*F@ QQ( 7LSdiN@8!٬(Hk=|~`þ:7 <\)Ie M~iY9a/o#luAۿ+ Y9ZV]y5S ZcÛCHHxUMz~/{?쭐E Un7v#3:L# =oQ3 M˼"kúy5RM_#RGb$Fq˫Mׇu:͂ OmD4ʹMouTjtS}EnP7k$*{ꑎE{[}$;mݰy^ &R\FuX71 EnnV)" μ>a"b+V65~I':tS֖n/Q|-~[$*,h~ t  0=Lb˔󄉐?>J HL"+I7cyv. hӫoC'" ty;>%<|/=1tyS;n8qM?IPXZM'1t YK27mFOn8򖈉n(>l#-zg}6C$qc1Mn8m{"k #nP扨C5ŝwnX+pƔ}Wc8NdfK>mPAj"KCSMo@mbeYS I }F'p@7͑ 71t'O&`spzN@z;\!qS4jތ3p"A7&)Ă[74m\6d9<ʏ;=L]7ר  &q6iRk&T .4q':ag wLGStg_7եm/g=4Ur?c#A 'tmé7mLO lyc6$caXxlumAuw:;U&O (§O>aH4_6> Z4N'hq8fiJzLD]Z-zZejDmNn8n@7q I֖:?{'uXR}R.PMiS# lm`!۴ɢ7gc^xJn8mDtdݰiāaΨg@O!^zߝEtcł ,#3Ee}y|  'u#fepM\&OBv Vb6fTא.q_Q3uF=5ܗ%W7\o޺PtÉh 7t2s;z UOՆ dPkݥ3UXL5͘n8O> eѺ) Nnxti%Zmzt/Pk?4uekh(Mٺ]S(2V7'tAmp* sZe-v,gUb@G7$Y7HvctwIn8=k 't'c ]OvT9:Ԡ^'Gf5Jz/]7([}gnf"C?DnP/.F cOnmRD P.k:(n=Kk}7 rzL'ܑKfn"޶x  f|淞JqM8¸ӪEZfUnh|l]c&p"T7ۢ{A7LLbݬ3`-rbl`5 PM*źz>žiNPp)M &^1[?[d(#Le?5v׹v?D]aˊ,nw1T`D '!1%͎y@7;ƯLUU)M4iMBa-%~~ºapDc #l<3'Gm@7q%~~8thD!8MB06)~M$nO p"P7J@7&|77dAOx[zjx '!b=]'Ї};a<3HIC53+DdA7ht&&6 ǜ7-կM:F39ȅA7nnİ")ьn'>=aM^MuVʢ7v6AnE#nS|("ܖԘ &ײ+U@7 5b ד񫄻.p"J7{gnK7n&Ë́Eɲ/p"H72f"nh'U݌nȢvO}b̻$u)1A^p;6y4+Aq#6N%p~g> 6͘n8inHzΫm73zjRt M\uW|ݏMZnUV_n*1 <'cޡL~A7(%0tWwT|)pY̲I;q2j1oftÍ;3^$Lxŗp#q"4}@7ЍĚY+)Y\7f,m@7ЍĚY.I4qRMqtb^DO7D 00`V;Z]sh8T6itIz n@7HͽYto6 ZtPݴ"S8mwUfploU3 AV/6^f-3p"M7gr|Dt64_Ңh0ݡ]Kؽ,N zaX_I<H%^T*2.*z%` ܽ1E3hkͲJ޾٬w5MOh" U]2"$ k ##7 MnPh$I"Mɼ 8 *41ثNkӠ#wӋQt|dpu4r7ڮOdo[C"wp/~uCL<M,RR]Wp1| 7'zmX JnTM>[u{.ċDZ} + >;ٞ vذcn{Zܺ/vDj : OO7O79V7^;wɭjK"Pđm>`lhI#uvI(t({C7^sT%g^@GVڛ8| _Fe{[~Hu|uEqZg}C{ $`s۶˪Okx͎4K#R7^\5tbZڹ}OA rOk}'1H6&m{[z gc-oӪZnaz_"܌jLj1.|IqRtA#th{z@/UGPCvr1SZ&u Wբ!fݸdc>R}tYtI[4jVx$M1M:]hot5F8d`9f-"'F* hf00i{eh#{/Jx Q !5v/6)mLOэ'7DXdS^:Q]8S}Ř[>nɗdC{]ul2fT!7J- q'k,DBt vpԍ/$o~N！nO2zs͞QPb.}ܓ:V1%^~Jч2[.̲+W8&EYOx7B7l&NIA*A 1;B2i2j}\ݐԏIW!CR֨V[.(Cx,ҳ7] )ܔmb呺 &YdY78 Qh;btއ݀p+$YQuun.bDpxq_|&QtnJBQl?aC0,Q Ƥ*aucɇwCtQn-t5p!3ץ2wgbwTۜ(zMX6agFoN/[m &j>^klhLtn.q~&;}’3?ĉQv]`:o8~z4}BMϨ7EWuun.́G2:X[/F8Zwَ,/l$\E21}| G enouOņ8|5/ZLӐn"qlHxn-E;*;/&+&x]A뎋͆4AC3#2x%N<݌ 3ꛦELFi:瀲0"֔jvY˯['qBR.8 (3U(ȱ(gЫ]([@tL*Wi7Y23dFü 3lMfv3vT#!OK~n.LF߀06gyz?xԭn2z γޛ }+Qu7!4-^ |7^nZFsb1bwh>*g eLM69ߧ6ƈD8:n[amppZRK'n6wwE{7~mG޺1eS˵2j+M d㢝n^FNML*[Y=Z6tlt 'vxxnƪVČs[BX?OT_ߚn6-?1n~WVh(+ O7ɟrp4;m JvOInl o<hݤa?j\yܠ&pWmFĜ'30.c^Fc@7SC7T6 o/6fyBpP7{"7Nn=]Fnl;R^LqeW8 `ZFmt 9& 䇷3_6 Ǡ~ac]fb&Hva0 p\859J6{i'9vx̾ݰ{ S@O-qjnܰdtӮ<9.^ަN WEstCmC?2w)tOx;?z/;}lv%C"t!~'Ï!#4uF16S@7=euA QYƠzj;GD25n4S70{Oۧ.wS<ۼ7}oxpf8%#H^џeMF0!X zF ǽDtSp=|Zڬʡn5QEX7xO"]Lj{zF9 %2Lϔs;HTw:u5tct3F7ML nuHD7mtJMqMz.+u9P3ИGs7xi] rb#ݼn~x/(^7y]ٗ6t vp:B=Xmth~'_7wfG=N7Blif$35V8]G' uPyZFn 4ZswƮ݆o:z,ifĀo``67[fVn>enҳg{]w3,? S6n"f*{Npf6:U2^Uqoe\55yElWCi=%%̍ftsT)Mj8QUCinbͶյ,:ݴjo'=@1ǹ?vLխBO9W IQ=f*$?PpS͖m>enZ%Ǎ 'Nx)਩G$3uݔ0a'1CO0W4F+6m8q<7?h c0sLxc)ۥ= Yt#c)F<+1 o~aT7kIPݨ.JtlSIhupxÛl4M.| lm;OwM,' Ѝ&nҿ`;k; o~ ah&G_7H8±OA6M0QDf8Ak*G7@tn @7Nx!T)`U}4l+.nP[(́ـn䣭nLi}Et#mu`LSdTpx3,#GpKHF6bj&FpS!$9,3F[dܔPLԡlϞȡu諛QL%2Iv$ndф"ꆕTJ;Ӎidt M@6|_ys,}1F6:fTdqt|R\tt#usPզ >K|4* @7X73;I JtjNmFgݔCu3F6:|+ObZ$~Ͻݻ·Xnԇ7u6;X+Gg+Oaj$;J~/#/\0{/Vbrݘ1JnhݼCw`$Rd^7#2_ F ]o㽃;Io'Qހn@Ѝ =!?ǒйỞ[_bŝ Guxn:/s(P Lm nf꭛͢o#/V_x~̿s}0+l~p7Zf0 F6[me5g%EwuG/ut#nfjfAG^N ggxUл4CC^v99I*nԌ^$L˨:gڴj"&_7zjgԭC7GT֍]{]`״5%}I%LD'vyii&bMnaQ Z7hO ۮaFQ/4m}vL2&n8c햧qt Hexg0e꭛7tS7_:a͇U?},F&&nL*tӧ[h6c:% -a#*|zffO/8'z#}sg>d_2M&nh؉lBrz%R8Fn-#*|RFRt3V78!DZ[&pjyCa3T$?,{D/Ps%{FW@Ѝ6q3-MgixqWtdžv sX _AMV3'_I77BHR3 n 9,{Du/Pwݠy(+OB:Bu;>pR(ЍrݴꄁiԚYǁMhufrZSνivY3f^GTQA*F!pc_ l~f!Up1qa=oi4-ǴqC6|%9%V7b%r78 'tPcˉ{>JwS7 /gMvNT{Ζ_]mνjՐԾꓐXд/C _0ϻWp^c){?DZt_~D8.unR~&Ʉn6lHIHFn4/C~? q'yQt#Vwu5kQ̪}Aқ!Tr].ub tCUx3ZVM|Au A=9.t}tc yi[8lz!B!*A CnArէ!浀nnjm_3 @EFGyʥn.[^.4 8ڨ5WCo!r7M1<ȵQt#4*\F t1NCjҠK߮:٣EzmA5v@ϔXʨj;?cݨGnjF4QmMSY&e8-ܘB1Z46 >٪nR)oN[TMW7p\2c.8vkmDx%а"jnDӑIQr8t|Wt6eqM^[ys(]ȅnf6qޫ>nԣnM>t㴨Pnx׫CE733L g!Ԙnd8W쎝N*Ѝz@7ɓnܜNQF6ҍ3Πp*M F69Mt#N$MuCSQ}@&qs9j8T}t#ꆰegx"{(Z7(i,QI8mU, F6Ns{H{;\O@7ɷnffvKa+vY97sd8@7ɻn(aeVL:-ܽ"ȦIe,6q=QeY+ C7/o92 uIndS 8?Tƶc}DЍl'$$+IӇi)Ѝl !m7Û=I^7R\tv݇.Ϛ^0l-[2›d+uc;KdvNK733=!Ύ8/kAg͈Ǐ ns|T7z=ln鯯xq#NT&Fjj;] VL7&b:hI8-͝@9nL z} d1n)Gr<,&d t3hE3&Zb.ZAlzKg ݂q7G$+sx/ɯq'{kTuބ&`z\$/uMf0p$aZw9ӦE5ѝѫV=nu-="M7=t#7V}&8'][2yÛn_;qa^ѯ;(Q)Okmq\71Q  a"l^'1P\&8#|oÝ P%2z2*nhعvq[KdCpݰ[XG @nVFҧ:`/HV4uG>8-I唝Xt5ú gԛߩI ^ȁ-W3n\*Gug78qnVT ul0Nq3-Mg1puna>I+n8g|㘩JŽu N2~#.:NTn<٤ n$`wq*gAI]ya;:gxذn٤ nݤVnmNm\FWs\zC.Tº9#މ}t[vm&yTuy$$5NF  IeW6Je i!fS1i>=y(]1g-š͸TKEսy Y ,L EaeasT*P;|0~IV bNx&$V& f3ހ㚎n.E&N2n^nh6tn@cD̠# Wp4um;4Ba6p䮻mY޻mv]٩Ce|DbCNp6whRc2#+'tTpSN9+-Rn WX+PNO5Obk$#3, ~ r{A& Ѝl@7@h87!A|4J uXЖC6wwRȕ?i_"8rt`ot g\ЭJLWA"ʙt# 0 C7GM|i€ndxMhRi\>HЍl@7@Ip Ǎ]nd F6nd F6ndVHt+/"E]%tEXtdate:create2013-06-07T12:39:29+02:004:%tEXtdate:modify2013-06-07T12:39:29+02:00i*!tEXtpdf:HiResBoundingBox1134x682+0+0VttEXtpdf:VersionPDF-1.4 G:xIENDB`fig/jitter.png0000664000175000017500000004761612163305115013225 0ustar walterwalterPNG  IHDRq-gAMA asRGB cHRMz&u0`:pQ<bKGD̿ pHYsodN>IDATx= hWwv7/5j4Zk_mSj>[bҊXEE"("" DBB!,aYea`眻٘M,:> x/6(4:= `܏aJ}(6 nJct rxQuId@.pbbhZw >8+B#/VH#BPkM HC[J@Gt4CCX "Ӄ!$ U򄁌_7v2+ݦYwzzsih)"Gی&过[dfet@O#'4XbI1#s飄DY$ݑࡄnmE:egL#7WL{"=<y5iGػ"**6`}T(ʾ yB7g˰,Q~m2y'sXhOd2dqY@M,  =&&GO)CHPRȕt$W0 mgz>iz ڍh+,uFsNKF|%COߝax MAobM%'ӅQ  ~/M$v{ş^geRR[>1(W\hi{_ݭ][K7'͖ pPQ RO{_-? AʑZ\R fB*T 'boPOنV*$WgC2 hD޺D \w@v(TXF(NqGx__O_&mӷBO7(wl3|,EIS0eɔ;ybDgεݡuQ  YhjK QRR\x >a5y0Cě/oȐgZ.*(*ʈ^& mVS  {,<+~ț,#^8NFo%v+23z2XR4BxƯE!:Б%}1z)-H5<`Zi<)6Q›׈S8biӓ6TӜ՗{]f(,ѢMoM ה峷ѥ*㾅˃%M.@u#H7W;]z&/$W޷ч8ZiXZ#M\JgƲ*E:N'?)%eK?oBhw)dz=/tړ3*Jk-nz_qw3B ߎ?g\6h*ix;کO>9sMM}B҆&<}{t劵z<>)[xwW2XwQԉuo Չƕ#$-IsyϒEĈ.>|gLd^ceݔuT}'+f=rG| _gP1H'<$ƨŦ63. ]E>A 3YȍTÄe'AB;yX员#YdORCO^*e;<Ӆğ)GjQ&9ȹ^1_[{!Εh}<"yWՏV|!ą⟊FxvTk\a7Ǣ.Xn89⎤#l,51*\6܁T{XqIo-fiL*^2 fi~@Q$`;{jƛSy]b9WxksPE?62ᑟ7`elQ 9q~SM  `xobx/e\8[ZVL!j2 N=`ݙ_Sv{ xtRлSiQ~ol(̮H-b/x[3qggqѥc~XS! KtJ_7<<,rR 6 wj;L_wCrTzL})$EMR`-V}G>iĚ{#ѥH rynw[TrKXTuhƸ}vQ#JV^9@6lK#Ō |'7 } XZS3[IyG~ iYV_OnKCRDu~Ӑ.^D9t>sG0ڨ Cؙg>;gN˛\RУˇɨ#b"f8!E˜3ݝJnaqhxlieP)""#M:xy`[aLE+PD͈ oq;B]w(dJ/<?ǔBKٸrnQ-B_W?=~fe'PquB. t|ţds ,AcxPA|w؄7אw6~' {]޳cQ Io2jq#%wqiJcƕn Z[$,c5P[ [Rn<s` sSYY'ilmy/x5n>L$S>MƋHYB^ҩ%bB(;Uq"t7rh:>(dyn>r^یX < };I1%CsGC&|DݮOb7'2iU JZq*yO9'?5,%BLA6KF,ND[elF$v:K?Ԯ- QT Q.ۨh)'NݘE䛚$>Ln⢦˧v" t:@m+۾=i'^&\tﳒ|]oZ^fwOoДloN _y)ܡ>9XL:,eV:UЅ#s:ͯ-DEɬ,|OK@>/W9l1)_6nL);hLq#dU5?w&Tz:<"h᯿yV-6-号AJU4?kys O).i+^xHhxckOC61sM-R)ΏV~:Ql^CW.mw[&A*-GnOdžN7羽ŏB)-/޾t >y9>@ թ]-nq%8p恐jKᨇQ\:)G+z>Tl x2ܑ!ozNqu+#e6gݭKZTqy|Cl9^*N4^[3#XBH4[?G߾p{.鏪&͕w.a%#Z9CW5/ĉGsƸxsg{n/^/\IKj-1Lut[(bZuoA>UR ~=ApT!Z}"rb= $!|f ϐqύA,V2,!;n sKNt(=EI;z˛ 3$7)xl%K3P7|m V͇t;Ay\py *a,5I,]|̻R!#sLKOc)T6H'Tx+69m!%v.G>[F'0rM)@\P Y`(Z4؞O;f7?[ʔB`$m崐NgZĹ^KthOˡU6!\@I,{o%\uN6ܙգ. @ԍva~Uo,}Zz2>q9WL'=4EhNz|!FH;;r*XpI&<;;> :3}* mq}eeo 32CJpa"); &Y' f yivν C1]p2 \8Ec7:ng,Yz>PϐmP&Tރb92HQ~Xa*vB6x54r",(ZA;y 3N,&'Grr1Æ^zHӲiU@_}=k[.?rP:^zVly,=C{]Ojg`6VOJkB]X 9V`b Mh\hfCYsEqnkw. ȹWϛXAo~zMU+^o-߷LO<2 ?7I(J>L뀜CfpE3o0'zK0Ն]F J tVp6n10ƎWE[mR7)Pw7\H*:Sğ٤{ ̻J!+4(~dُ:1>4L-#g#%>3?9X;cOM&IjxⓏVi9EHDs'SW?~¨xHy/lg>suJ[<5b.X"V.e(mn$*˳ZsX؉ n/ b nj1N& 6~#ƣuG CdKEh^dʆ1Rc*𵊓Mtv qG54M.<*n/+^Ly쵆~_HQ&" ?6j.߬Fd-c[jw׈f;gUW ^ƹ/T<ɗ)oo;]GvK;Y=Fi=MfeS?8i1 ^ ; o̕ &bύU75*j28nRωw C thb|?62غ6(z>B֘nU`hRmOY(l+xQ58Z9FY? K7Bd"AXڑ:) ?o`kɤ \SϏ2SxW"l* jQ!ʖB+:ΐ%JvvNq"o"k2ͺ 1n&sZD[I$$h9!\0JŴ4tgCLxK Hǭ':6s0{$G*>`u,$@_J狗xke[Ժ"aX&A=i1{eq}TE %wFJ!y=56rS;SAF ٙVI 2w_QBj͖{s(G>V oM<˼Y'bcE` Q5ܘ|]q9[98P"&z\VUg:~k!2t̢q3,)I6˫dUH/ W$ZCA:r{cN/֎'Q0Ez{KNP@ M3ֹ Uԩu^ IGZɷQχ& _ nkEGm&/5bt۵!\s}uĻ$?' ^~cΦmqz_87 n*ʎ;n }vLU6h] 1UzX\>@Ck퇿#NMĖGN~귛Hh>BnfFE[k#@^7rC㢫,iݶ}72_D y2KEi`D~ Y8d|B=۵KƧL~`}Y4ܺmcϷ.Řs:?8Օa)mDc^Fʺs 6aq;YĽ B`tФW}HLm~wx`Jdphn--;/Xk7w^"WvO 𻑇փoS 5nÞ;3o?y5IG|x' sCZX}4B`F֕xg!~v+@.R\Ѕo!DTpe7.'.I>r8&M@Ap& ;ByvPklT+ZΉjwEcmi$7dJw]c$xHBuu贠agfȝB"# 5.NdTv'HqYc[h: Vo-_.\HY!Si(MV*U85#mr,/T:1åEy p=?$=?aŬax!Ϋ+j*Pςrx *Ww ;)-_Qwy#È<"_yNv6[zyAfhg:p)&\egn#<;r{a$< t:E"#2EͲH2+d5k!O.x̡(zexڇfO{n2ƨ|c?VPE[#o yVZѨ:k˜5Y k50̳8ۤp'Yt~,2|,Qyu!&LQZraZz}:I}/1e*7Ѳ&"3B` W>0?PSAsm3GB蠨EQ05Gu>EaА (KWoPa0$:)Q ʜ24aPޙS.īwtzڍy ڡNg0xsQY|ׅ8x7poV@ cX yJ 7 n(3Ęi-{|묊ΏS^6SͿy 6C'F̞4WHŇ\ $)A* -T<َ%R΀-.sod +apxiw}o] ,L" UaQ:OZFRaOAM|u Lz< 3fSkDCBƷ9(>ȝ@ Ww}r>{P z#/E=nO"2k+XNANj < d%򮖿gn~Xr<M8WP'ѵ%ޏԒn%Qb9釸7-e~өM>_dhկ4_Mk["mBpl-NL06rFy̩,j^8x t(R~ 99I:E_fIqPwp~1$U8|'6EG;`n/ޓa*`[B{cnnX , ;9u~6jDk^Ϯf#,wygcob_]F_P56C[SV|.Rj_7'bc??cO͵76bԜhj PFB̎9뜈~q4Bc'}٧Fy1dWm1 00Tdoɨ!J^>4}ٹ4ԤwL5 !lK35.qhf(Nw@UғBT<4=uD잓c)vwՉ!PŇxC푋*w1g _DQ:v3VPvs޻Om#x-y^!04;}iK?p$S]1;dPso o'~"%ijFIAT(Q8BiED;?Z88xQ]{`Q ?ގ cNi**W05$W-p\2 آ9QT}=x^)&sn6g~\~ ):x}G7G$cP(rAk)ܴ%q#3hz,jԉRawc17ˍ >)[6Xt~uzpZTCE&ǍMajDzgIP蘔y~]y՛)1"5K~4Gvǩ,VkZY&No顭(]Vrڗ ܗ2RV1Wgkr `EoOA{ɘ:3q79ME+>{?yaG==I""7gۄ? ,*T"#usQ/}~@y*MIՁ'cX@2coSHwWKZY2<'Df"/Lq軾WƩs Y{3Ȝ>Bgwpi~ =*e?LMAY{@(yk&ν~ i'KX"R)f$e$@fBXgBԬp-\=đ7!S^_hgҨXmMoY\v[[xfzG"r֦8S@JNntY:Oy凝j(*'}R}/DQuCbW "rܭƌScԥLf< o 1Z|FxaqaKwDDdw [)W˷QQ׼@x!,VcSAF/vTA@JB1XOvD9HnhEK+>μbCCUOƋ/J."6)ot mt13DUkIo+}D)M˷u%YRrԦloajpC  3A6Ξ5c s6R5.C"{0C,4pxŁE@kTA$v5Zl---Ɠ0F[G>|˯l;fMO/M] U,6Ct1\4v|""J_PmpsL90f7AۺP4r~T_ w]O0)\+2(1Cˌ"ʛۧIFg42ibDLXŒYӧ̙Y l#JQPX|աddZƔ.XS,q ڶ+u]2v45*7=X(%ixJx \ÔX px3Q1hqXllϋ^K,r&W?HyvA`DNʹ$2f:7d^`{oʝ*4h]L!Yu7ҩK"@zri K KBLkk+3UmDb%%QQA4z…qTD޽V9Ha5VEM6vfak͍[_ڽ],_/ "=ӓkд1ybnk;`M|vﮧ~LR"5S+E4U+ĬNPk/__lݿoJ[62bcj<غѨb]&#sٲXdɖd`nJ)Ԉdj*cyU^.  -B7m鱖 RY!>OusaOz}oE4c)u+ƈw0޿5b=ty2%bQXZaյXD" %&/;Mm; 8p=JNLxK-E]V7bl;FMxTI(JAP[~)-ru53y en^]gM] ̼p㍊I-Mϔϐеhi=d3o)*{du0{_-]gBBr0kx"#P%[xYOHB~N:^d*cW5os= ƯP9;yQTtZ3 F+}Myw z^=zrc^Nψ9C'[$z<(<?$({n]+MlI=z ?]MY4b|e.{}LN3`i*[ xR87_x`k~S$57ZSz xe'DIշ|+}]g@yJ4H7p @YnCZBeTO]9$^ uA?&ٔYlN|+mBB<֘'d~ wi־q %u- 7YKs@[mS~[_7QܛZX*\#WaEY[ɿI;Gyc?x"[ !_zW]I[v %ܙYQt~& _gT;Eo '!Jr |_=)QD"۸_0%Y;Td⧒ʹ/4\5bH_B yhv$7١*<Ч?wx7iU~ӘZ1kH롑fg=!}t(: %sM;BĴx:Z yrM?*5(JRjӶ/+1Q:q%9Se"-?[=-Z==_Nc6k)WDsVliC~l rvՈ!B^ꢑl]Go{kر X.6,fKޤ/!F g6]1MmV8m;:Va+͇ yl@v)v(51巿v>Tn`wBpXfzv3ʄ[R;R3GEtС7}A ֳW/-$~a[n,FA/Q$Xb-)ǮY|8!%R`q'Br̔>q.aͮ3J izqe3O)z!OR͉y`XqLK*@BNR+7'׵zEmoD*ēIi]ȍ]3e&cA zEJ"PTpD^Uhw p8u"A2sۇyxGGְM^!$5OUXF5IGTaGC|q(c_?# M TNN.E6_1х"F:d.gƯźbVi$1G}!N6olʼ3g-x'wPmpsagV%lkYՇ:ȆYH J5g|uhYˆXMӇ.6biՔMi tFDNs(A#+=[)S^J3n$MJsy'A>ue D^2n <ׂ&OD?NH6T+9g{۹B }R\N*^ICOJ%t":<ɔhCt"ץ2D4<QNd#O*[lx}A$*Y YVgv`&}c#8p I\}8 )C^!@c=4O|4LCprmʢrGt( 1AV2B0-n{t?ZYiǼ![:.=*or!bC./162*{PU\Lq_}y缈xaWMd'>+Ȁ{Ռl `tNG#7=M'*rhǖԠ*kru`yC<Ѥighx(<7;#*ikڡt-eʮN=0S9Cά2Z*O|tD]FDs[ZA;N?p?0 t@&u͟QiDW6Z<ޗm#J++OsI0 K6)&alpL thYvfIEf|jӘqkDTDjC/ !A'?Ck@#.}R}=Zz5x'= lJ90|~A'a-X^ r=PflLv ʣf7C/F>> ! P@n>,}(#B #^n09ecHQGyJO>z Γ+7|C^v@'=.Ӟ?L0RPw#zQA=( ;Ozy !|G !Jb2q8k%tEXtdate:create2013-01-24T17:08:16+01:00p[%tEXtdate:modify2013-01-24T17:08:16+01:000tEXtjpeg:colorspace2,uU tEXtjpeg:sampling-factor2x2,1x1,1x1IIENDB`