paper e - uppsala melander/thesis/ ¢  2002. 12. 10.¢  paper e bob melander and...

Download Paper E - Uppsala melander/thesis/ ¢  2002. 12. 10.¢  Paper E Bob Melander and Mats Bj¢¨orkman

Post on 31-Jan-2021

0 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • Paper E

    Bob Melander and Mats Björkman. Trace-Driven Network Path Emulation. Technical Report 2002-037, Department of Information Technology, Uppsala University, Sweden, November 2002.

  • Trace-Driven Network Path Emulation¦

    Bob Melander Mats Björkman (Bob.Melander@docs.uu.se) (Mats.Bjorkman@docs.uu.se)

    Computer Systems, Dept. of Information Technology, Uppsala University, Box 337, SE-751 05 Uppsala, Sweden.

    Abstract

    This paper reports on on-going work where a trace-driven approach to network path emulation is investigated. Time stamped probe packets are sent along a network path whereby a probe packet trace can be generated. It basically contains the send times and the one-way delays/loss indica- tions of the probe packets. Inside the emulator, the probe packet trace is used by a loss model and a delay model. These determine if a packet should be dropped or what the delay of the packet should be. Three loss models and three delay models are evaluated. For non-responsive UDP-based flows, the trace-driven loss and delay models that are found to perform best are those that determine loss and delay based on loss rates and delay distribution parameters calculated across the probe packet trace using a small gliding window. For adaptive TCP flows, none of the evalu- ated trace-driven models performs well. Instead, the Bernoulli loss model and an independent average delay model performs best.

    1 Introduction

    Before a new network protocol or application is deployed and taken into op- eration, its behavior and performance should be evaluated to ensure that, for instance, it will not be malicious to the network. A very common way of per- forming the evaluation is by simulations. The benefits are (at least) two-fold; the experiments are reproducible and can be fully controlled.

    To be able to reproduce behavior is important since that makes it possible to subject alternative designs to identical network conditions whereby comparisons can be made. It is also useful in debugging an implementation since the condi- tions that trigger the incorrect behavior can be recreated whenever needed. To have a controllable environment is also important because it is then possible to study performance and effectiveness over a range of operating conditions (e.g., queue capacity in routers and end-points, amount and type of competing traffic, delay variations etc.).

    However, there are difficulties associated with simulations. A key problem is how to set up realistic simulation scenarios. Decisions have to be made regarding ¦ This work is partially supported by the SITI/Ericsson CONNECTED project.

  • 4 Paper E: Trace-Driven Network Path Emulation

    what network topology to use as well as what values to assign parameters of the components included in the simulations (e.g. buffer capacities in routers, intensities of generated traffic etc.). Another more practical problem is that event-driven simulators (which are the most common network simulators, e.g. ns [20] and OPNET [21]) are memory and CPU time intensive. Large network topologies where substantial volumes of network traffic is generated are therefore hard to simulate.

    D1 DnD2

    S D

    µ1 µ2 µn

    XX X

    P

    Figure 1: A network path modeled as a set of queueing elements with service rates µi and constant delay factors Di, Probe packets are sent from the source node S to the destination node D. The Xs correspond to cross traffic on the path.

    Trace-driven network emulation can be regarded as an evaluation framework that provides the reproducible behavior of simulations while simplifying the process of generating realistic network scenarios. The whole idea is illustrated by Figures 1 and 2. A host probes a network path by sending probe packets to a receiving host at the other end of the path. A probe packet contains its send time and a sequence number. The receiving host records the arrival time of the probe packets. Using those arrival times and the information in the probe packets, a probe packet trace with one-way delays1 and loss indications can be generated. That trace serves as input to the emulator where it is used to estimate parameters of a model of the network path and/or to control the emulation.

    In this work, the emulation is done entirely in the event-driven simulator ns so the emulator operates on simulated traffic. This is in contrast to, and should not be confused with, traditional emulators such as NISTNet [18], Dum- mynet [25], NetShaper [11] and others [1, 12, 14]. These emulators are inserted on the path (typically a single link) between two physical hosts and thus operate on real traffic. Another important difference is that these traditional emulators are not trace-driven, i.e. a probe packet trace is not used to control the emula- tion. Trace-driven emulation of a wireless LAN has, however, been investigated in [19]. The emulator there operates on real traffic and the network path only has one hop, the wireless LAN. The work presented in this paper is inspired by the ideas in [19].

    A benefit of doing trace-driven network emulation in an event-driven simu- lator is that simulation time and memory usage can be reduced. This is because

    1The time for a packet to travel from its source host to its destination host.

  • 2 Network Path Models 5

    S D

    Tracefile

    Network

    emulator path

    Figure 2: Emulation of a network path. The emulator replaces the network path and mimics its behavior. A trace file obtained by probing the network path serves as input to the emulator and is used to estimate model parameters and/or to control the emulation.

    the number of events (e.g. when a packet is enqueued, dequeued or dropped) will be fewer compared to when the network is not emulated in the simula- tion. These kinds of emulation-enabled simulations are also studied in [26]. As such, that work is very similar to the one presented here, not the least since the framework described in Section 3 is also used there. Basically, [26] differ in that loss and delay are modeled using a continuous-time hidden Markov model (CTHMM). Their evaluation of the CTHMM suggests that it works well for both non-responsive UDP-flows and adaptive TCP flows.

    The rest of the paper is organized as follows. The network path models are described in Section 2, followed by a description of the general emulation framework in Section 3. Different probing schemes are discussed and studied in Section 4.2. Three loss models and three delay models are then evaluated with respect to non-responsive flows in Sections 4.3 and 4.4. Two of the loss and delay models are found to perform well. The performance of the models is also studied with respect to TCP in Section 4.5. For these adaptive flows, the studied trace-driven models do not perform well. Section 5, finally, summarizes our conclusions.

    2 Network Path Models

    In this work, only the loss and delay characteristics of a network path are modeled. There are of course other aspects, such as packet reordering and packet payload corruption, that should be considered in order to provide a more complete emulation of a network path. However, it is probably not difficult to extend the emulation framework used here to also model such phenomena.

    Roughly, the loss and delay models presented below can be divided into two types; those that only use the packet trace off-line to estimate certain

  • 6 Paper E: Trace-Driven Network Path Emulation

    model parameters and those that use the packet trace during the emulation (but possibly also off-line for parameter estimation). We will refer to the latter category as the trace-driven models. The Bernoulli loss model belongs to the first category and loss models 1 and 2 belong the second category, i.e. they are trace-driven. Of the delay models, the independent average delay model belongs to the first category whereas delay models 1 and 2 are trace-driven and belong to the second category.

    In the description of the models, the following notation is used:

    • 1 ≤ i ≤ N where N is the length of the packet trace. • Four data series ti, si, di, and li describe the packet trace:

    – ti, send time of the i-th packet. tj ≥ ti when j > i. – si, size of the i-th packet.

    – di, one-way delay2 of the i-th packet. di ≥ 0. If packet i is lost, di is arbitrarily taken to be zero. The di data series is an observation of a sequence of random variables {Di}Ni=1. Each delay model make assumptions about the statistical properties of those variables.

    – li, loss indication for the i-th packet.

    li = {

    0 if packet i is delivered to the destination. 1 if packet i is lost.

    The li data series is an observation of a sequence of random variables {Li}Ni=1. Again, assumptions about the statistical properties of these variables vary among the loss models.

    • ltot, total number of lost packets. ltot = ∑N

    i=1 li.

    2.1 Loss Models

    Model 1

    The first loss model is depicted in Figure 3a. The Os and Xs show the send times of the probe packets. In this case, the packets are sent periodically with a fixed spacing. A O indicates that the packet reached its destination whereas an X indicates that the packet was lost.

    In this model, whether or not a packet is dropped is determined directly from the packet trace in the following way: Suppose that a packet arrives to the emulated path at some (emulation/simulation) time t. That packet is dropped with probability Pt being the value at t of the linear interpolation of the loss indications of the probe packets sent immediately before and after time t. The randomization is done by

Recommended

View more >