ad hoc network emulation - 1 1999 m. satyanarayanandarpa review 4/23/99 emulation of ad hoc...

Ad Hoc Network Emulation - 11999 M. Satyanarayanan Darpa Review 4/23/99

Emulation of Ad Hoc Networks

M. Satyanarayanan

School of Computer Science

Carnegie Mellon University


The ProblemEvaluating mobile systems in ad hoc networks is difficult

· experimental control· reproducibility

Wireless communication· media isolation rarely feasible· cross-traffic from stray hosts· unlicensed spectrum shared by many devices

Physical motion· impossible to precisely duplicate· wireless propagation very sensitive to path· routing in ad hoc networks critically dependent on motion

These shortcomings make it hard to· interpret results and verify them through repetition· compare alternative designs· tune system parameters


Solution SpaceSimulation

+ perfect experimental control & logging; easy sensitivity analysis

– requires simulation model of applicationtypically requires source codeat the very least, requires deep understanding of application internalsreverse engineering sometimes illegal (e.g. Microsoft Outlook, Explorer, etc.)

– hard to create realistic user experience– speed typically slower than real time

Emulation+ live OS and applications; no modelling or approximations+ realistic user experience– requires network-layer OS mods– limited to real workloads; more restricted sensitivity analysis

Direct+1-step simulation of network+high fidelity packet experience+full modelling of cross-traffic–scale limited by simulation speed–exported entity is simulation code

Trace-based(aka “Trace Modulation”)

–2-step collection-distillation of trace–low fidelity packet experience–limited modelling of cross-traffic+replay not limited by simulation speed+exported entity is compact trace


Direct Emulation


Run ns2 Simulator in Router

Fate of every packet identical to live execution

ns2 simulation must run faster than real time; limits scale of system


Implementation Layering


Trace Modulation


OverviewThree phases

· collection: subject network to probing workload during traversal

· distillation: reduce collection to time-varying parameters of model

· replay: use trace to drive emulation of wireless network

· analogous to impulse-response analysis of circuits

Combines realism with reproducibility· trace provides realism· emulation on isolated LAN offers reproducibility· coverage can be broadened with multiple traces

Traces create synthetic environment · transparent to application and system software· modulation at network layer; no changes at transport and above· fakes effects of mobility without real motion· differs from other trace-based approaches

e.g. trace-driven simulation and trace replay

· those approaches create synthetic workloads


Simple Network ModelNetwork model determines

· workload in collection phase· transformation(s) in distillation phase· replay algorithm in modulation phase

“As simple as possible, but no simpler”

Conjecture about end-to-end wireless performance· temporal variation source of much complexity· short-term, microscopic variations irrelevant

Implications· simple linear model adequate for short intervals· model parameters vary across intervals· compose to approximate observed behavior· like drawing curve with short line segments

Model constraints· measurements at one endpoint suffice· workload perturbs network minimally· cheap to use during modulation phase


One queue’s delay on packet of size s is f + sv· fixed costs (f) (per-bit latency, can be overlapped)

· variable costs (v) (bandwidth-limited, must be serialized)

· f & v affected by cross-traffic & change over time

Bottleneck queue· largest value of v, referred to as Vb

· all packets serialized through this queue· fully determines end-to-end bandwidth

Total delay = fi + vi = F + s(Vb + Vr)

· three unknowns, F, Vb and Vr

· measured by workload during trace collection

Chain of service queues

· each queue represents a network element

· total packet delay = sum of each queue’s delay

Instantaneous Model


Collection PhaseMobile client generates variant of ping workload

· reply sent by static host

· each “ping” consists of three packetsfirst: small size, s1

second: large size s2, sent after replythird: size s2, sent back-to-back

· F, Vr, Vb computable from rtts of these packets

Trace format

· all incoming and outgoing packets recorded

· timestamps plus device-specific data

· carefully designed for extensibilityflexible format for addition of new devicesscaling for wide range of network speeds

· published as informational RFC

Implementation

· in-kernel implementation

· kernel trace buffer emptied by user-level agent

· low-overhead, portable, overruns detected


Distillation Phase

Postprocessing step after trace collection

Transforms collected trace into replay trace

· each entry is a 5-tupleinterval width, F, Vb, Vr, and loss probability

· drives modulation phase

Smoothing to reduce impact of measurement errors

· sliding window of width five seconds

· average of estimates in current window

Implicit assumptions

· network is symmetricforced by lack of low-drift clocks

· network unchanged during ping tripletgross violations detected & compensated for


Modulation Phase

Two components

· in-kernel queue to delay or drop packets

· variation of queue parameters per replay trace

Queue located between transport and network layers

· in- and outbound packets interfere, as in real life

· scheduling limited by kernel software clockfor realism, chose not to turn up interrupt rate

User-level daemon controls queue parameters

· reads replay trace from file

· sends trace entries to kernel via pseudo-device

As simple as conducting isolated LAN experiment!


Example: Flagstaff Traces (4 trials)


Example: Wean Traces (4 trials)


Summary of Previous ResultsModulated results match live in 10 cases out of 12

Web benchmark

· close match for all 4 scenarios

Andrew benchmark

· close match on Wean, Porter, Chatterbox

· emulation clock granularity hurts Flagstaff

FTP benchmark

· close match on Wean and Chatterbox

· Flagstaff acceptable, but exposes asymmetry

· only match on Porter scenario is troublingsend off by 1.05 sum of std. deviationsreceive off by 1.56 sum of std. deviations

Refinements suggested by results

· fine granularity clock for modulation

· low-drift, synchronized clocks for collection


Will It Work on Ad Hoc Networks?

Modifications necessary

· trace format needs to be enhanced

· collection workload may have to change

· replay needs to accommodate per-host-pair queues


Comparison Using FTP Workload

Ad-hockey

NSwith

FTP model

FTPSource

FTPSink

RouterwithNS

Time-Seq PlotTime-Seq Plot

Scenario File

FTPSource

TM

Re

pla

y

FTPSink

NSwith NTRworkload

Distiller

Collection Trace

Replay Trace

Time-Seq Plot

Simulation

Trace Modulation

Direct Emulation


Status

Port of trace modulation code to Linux mostly complete

No changes to trace modulation yet

Tantalizing results: FTP on unmodified trace modulation


Example 1


Example 2


Plans

Much design, implementation, and validation work lies ahead

· don’t be fooled by success from “low-hanging fruit”

· changes to trace format & collection workload being discussed

· distillation will have to match trace format and workload

· multi-queue replay layer in early design stage

· extensive experiments varying motion, scale & workload

· eventual goal is to evaluate Coda and Odyssey in ad hoc nets

Our experience confirms complementary roles of

· simulation

· direct emulation

· trace modulation

ad hoc network emulation - 1 1999 m. satyanarayanandarpa review 4/23/99 emulation of ad hoc...

Documents