context-based adaptation in delay- tolerant...

Context Based Adaptation in DelayContext-Based Adaptation in Delay-Tolerant Networks

Agoston Petz BSEE MSEAgoston Petz, BSEE, MSESoftware Engineering - Dept. of Electrical and Computer Engineering

Dissertation Defense

Committee: Dr. Christine Julien (Advisor), Dr. Scott Nettles, Dr. Lili Qiu, Dr. Sanjay Shakkottai, Dr. SriramVishwanathDr. Sanjay Shakkottai, Dr. SriramVishwanath

1 November 29, 2012

Challenge areag

This dissertation focuses on the class of networks known as delay-tolerant networks (DTNs) Also called “challenged networks” or “disruption-tolerant networks”

Delay-Tolerant NetworksDelay-Tolerant NetworksDynamic, ad-hoc networks in which senders and receivers are often completely disconnected from each other, often for long periods of time.time.

2INTRO

An examplep

Well-connected portions of the network are separated by areas of transient connectivity E.g., disaster recovery, remote villages, military deployments

One example of a DTN

Use ad-hoc network protocols in the well-connected portions of

the network

Use ad-hoc network protocols in the well-connected portions of

the networkthe networkthe network

Use DTN protocols while in transit between

i

Use DTN protocols while in transit between

i

3

regionsregions

INTRO

The challengeg

Delay-Tolerant Networks present a challenging environment to network protocols due to their dynamically varying nature. Sparse, mobile, bad connectivity No end to end paths No end-to-end paths

We want to use the network technology best suited to the combination of a communication session's requirements and the qinstantaneous network context DTNs vary, one set of protocols cannot cover all cases Thus the network stack must adapt to context changes By adapting protocol selection, protocol parameters

4INTRO

Our solution

Allow applications to seamlessly use the best combination of protocols for any given situation Develop a middleware architecture to enable dynamic network stack

reconfiguration based on network contextreconfiguration based on network context Define context and how to collect it, and develop a framework for

context-based stack adaptation Treats the mechanisms by which context is used to inform stack adaptation, and

the mechanisms by which the stack is modified dynamically (i.e., during runtime)

Design and build a complete DTN solution that uses context to adapt g p pcommunication in a real-world environment

5INTRO

Overview of contributionsDynamic Stack Adaptation

•ArchitecturesDynamic Stack Adaptation

•ArchitecturesContext Sensing and AggregationContext Sensing and Aggregation

P i C S i

Research Contribution 1 Research Contribution 2

Architectures• Proof-of-concept implementations


DynSS MaDMAN

Passive Context Sensing

Context Agent Framework

Case Study:MADServer

Research Contribution 3

Complete Systems Solution• For network coded routing in DTNs


Validation• Using autonomous robots from Pharos Testbed



6

• Using autonomous robots from Pharos Testbed• Using autonomous robots from Pharos Testbed

INTRO

Dynamic network stack adaptationy p

Based on the idea that DTN-specific PHY, MAC, network, and transport protocols need to coordinate to provide the best network utilization When operating in DTN “space” use DTN protocols When operating in DTN space use DTN protocols When well-connected, use ad-hoc protocols, or standard Internet

protocols

Goal: distance application developer from network implementation details

7RC1 :: DynSS

Dynamic network stack adaptation (cont.)y p ( )

Allow one network stack to be swapped for another during an active application session Allowing app to continue to do work w/o disrupting connectivity Potentially relying on other devices transiting between areasPotentially relying on other devices transiting between areas

8RC1 :: DynSS

DynSS architecturey

Our DynSS architectured h f Designed with four components

User Library, Routing and Transport Layer, Service Daemon, and Context AggregatorAggregator

Validated our ideas on dynamic connection migration1

Context Aggregator envisioned as a vertical component which collects information from any layer of the stack Using passive context sensing to avoid using network resources E.g., connectivity, throughput, latency, number of neighborsE.g., connectivity, throughput, latency, number of neighbors

Selects from among existing network stacks

9

1 A. Petz and C. Julien. "An Adaptive Architecture to Support Delay Tolerant Networking,“ ARM2008

RC1 :: DynSS

Evaluating benefits of stack swappingg pp g

We evaluated our idea of connection swapping Using custom DTN emulator Emulates end-to-end behavior of DTNs

Packet delays drops out of order delivery Packet delays, drops, out of order delivery

Bridging interface with probabilistic (per packet) delay queue and out-of-order

d l

Bridging interface with probabilistic (per packet) delay queue and out-of-order

d lNodes run Linux with Nodes run Linux with

deliverydeliveryconnection swapping across TCP and UDP

connection swapping across TCP and UDP

10RC1 :: DynSS

DynSS prototype evaluationy p yp

Two scenarios Short delay: node wanders into disconnected area for two minutes

[~5 sec delays, 0.1 – 5% drop] Long delay: node wanders away for 10 minutes and experiences Long delay: node wanders away for 10 minutes and experiences

longer delays [~2 min. delays, 0.1 – 5% drop] In both cases, packet drops were a linear function of delay

11RC1 :: DynSS

Short DelayShort Delay

ts

TCP delivered 47k packets (0%

loss)


loss)C

P-on

ly

resu

l

TC

rSwaps are triggered

when delayincreases/

Swaps are triggered

when delayincreases/

Dynamic Dynamic

decreasesdecreases

mic

delivered 85k packets (80% improvement)


Dyn

am

12RC1 :: DynSS

Long DelayLong Delay


loss)


loss)C

P-on

lyT

C

Dynamic Dynamic mic Dynamic


Dynamic delivered 60k packets (90% improvement)

Dyn

am

13RC1 :: DynSS

DynSS Summaryy y

Adaptation of stack can be beneficial in DTNs Dynamic stack swapping allows for better delivery and latency

characteristics in mixed DTN/Ad-Hoc environments Arguably it is better to use TCP (or TCP-like) protocols when you cang y p y For reliability, rate scaling

Swap to DTN protocols only when throughput is “unacceptable” Now what are the best adaptations? Now, what are the best adaptations?

Drawbacks of DynSS include: Forced to adhere to limited Linux socket API to control stack parameters

Limited information available through /proc filesystem

Monolithic stack implementations in the kernel limits granularity of control

Integration of context from outside the kernel is complicated by user-mode/kernel-

14

mode interaction possibilities

RC1 :: DynSS

MaDMAN

Middlware for Delay-Tolerant Mobile Ad-Hoc Networks2

dd h l f SS Addresses the limitations of DynSS Uses modular stack compositions As opposed to monolithic kernel implementation Modularity promotes good software engineering principles

Runs in user-mode and kernel-mode, making for ease of development and testingg

Tight integration with the Bundle Protocol Based on the Click Modular Router Large selection of available protocols Large selection of available protocols Modular framework, easy to extend Good framework for developing experimental protocols

15RC1 :: MaDMAN

2 A. Petz and C. Julien. "The MaDMAN Middleware for Delay-Tolerant Networks," Poster at HotMobile '10

The Bundle Protocol

Popular general purpose application-layer protocol for DTNs

Transport-, network-, routing-agnostic

Defined in IETF RFC5050*

Groups application data into large bundles (up to 2GB) Every bundle has a globally unique ID (GUID) E d i t ( h t) h l b ll i d i t ID (EID) Every endpoint (e.g., host) has a globally unique endpoint ID (EID)

RFC5050 requires a convergence layer to act as the network stack, and some forwarding strategy to accomplish (eventual) best-effort a so e o wa g st ategy to acco p s (eve tua ) best e o t delivery

16RC1 :: MaDMAN

* http://tools.ietf.org/html/rfc5050

MaDMAN: architectureAPI: similar to previously

presented designAPI: similar to previously

presented design

Bundle Protocol Interface: specific to the popular Bundle

Bundle Protocol Interface: specific to the popular Bundle specific to the popular Bundle

application layer protocolspecific to the popular Bundle

application layer protocol

Selection and management of lower layer protocols,

connection migration

Selection and management of lower layer protocols,

connection migration

17

Modular protocol implementations Modular protocol implementations

RC1 :: MaDMAN

Intro to Click Modular Router

Modular, flexible experimental routerC++ k 2 2 2 4 2 6 C++, works on Linux v2.2, 2.4, 2.6

Widely used for experimental networks E.g., MIT RoofNet Hydra (UT-Austin) Back-pressure routing for intermittently connected networks

Powerful and convenient way to control and modify the Linux owe u a co ve e t way to co t o a o y t e u TCP/IP stack Much of the code to modify the stack and dynamically change it is

already therealready there Low-level functionality Easier to add low-level functionality than to the kernel

18RC1 :: MaDMAN

MaDMAN: implementation in Clickp

Two stacks, DTN and Traditional Traditional uses IP Routing and

TCP Linux socket DTN uses Epidemic Routing and DTN uses Epidemic Routing and

UDP transport

TCP Magic: parses TCPpackets to extract stateinformation

U d t b t t UDP ti Used to bootstrap UDP connection when network stack transfers a connection

In order delivery and seq # tracking

19

In-order delivery and seq. # tracking

RC1 :: MaDMAN

MaDMAN evaluation Using Pharos Testbed robots 3 d t ll l DTN 3 nodes create a small-scale DTN Contrived, intended to demonstrate potential

Hardware and software signal atten.gproduced range between 5-15 ft.

64B Epidemic Routing beacons ~200ms

Fixed rate of 10 or 100 pkts/sec – 1448B For reference:

15 kB/ hi h li 15 kB/s: high quality streaming audio

150kB/s: low qualityi id

20

streaming video

RC1 :: MaDMAN

MaDMAN evaluation

TCP-only (left) vs. adaptive (right) Adaptation based on triggered context input Adaptation based on triggered context input

Enables early delivery by leveraging the mule through epidemic routing

21RC1 :: MaDMAN

MaDMAN evaluation (cont.)( )

TCP-only (left) and adaptive (right) MaDMAN improves application-level throughput 65% delivery vs. 38% (TCP-only) Improvement depends heavily on the nature of the experimental

setup and connection opportunities

22

p pp In general, application-level connections benefit from multiple delivery vectors

RC1 :: MaDMAN

What about Bundle Protocol integration?g

The Click Convergence Layer3

Connecting Click Modular Router and the DTN2 Reference Impl. Allowing for MaDMAN Bundle Protocol connection

Design complicated by two general issuesDesign complicated by two general issues Interface between the bundle protocol and its convergence layers is not as clean

and well-defined as RFC5050 makes it seem

Must decide hich “additional” ser ices to include in the interface Must decide which additional services to include in the interface

Not monolithic like other convergence layers

Must interface DTN2 with another application running as a separate process

We designed a custom IPC mechanism No “Click API” so DTN2 cannot call into Click directly

3 A P t B W lk C A di d C J li "Th Cli k C L P tti M d l R t

23

3 A. Petz, B. Walker, C. Ardi and C. Julien. "The Click Convergence Layer: Putting a Modular Router Under DTN2” ExtremeCom 2010. Received Best Paper Award

RC1 :: MaDMAN

Click convergence layerg y

Two separate channels for IPC O f B dl One for Bundles Another for control messages Uses POSIX memory mapping

Components Components ClickCLA

The convergence layer adapter – schedules bundles set and deletes next-hop routesp

BundleInterface: Click router element to interface with Click CLA

Beaconer: Implements low-level beaconing protocol to track neighbors

Implementation done in C++ Control msg. types: { BUNDLE_READY, BUNDLE_SENT, LINK_UP, LINK_DOWN }

24

g yp { }

RC1 :: MaDMAN

RC1 conclusions

Show viability of stack adaptationSS l d DynSS in emulated environment

Click/MaDMAN for real-world DTN deployments Good modular architecture, ease-of-prototyping, easy to test Some problems: Performance limited by IPC Use of kernel buffers and Click design limits “throughput’’ in high-load

scenarios

Using commodity hardware Real-world DTN experiments show benefits Integrates with Bundle Protocol Important to the research community

How to use real context to inform adaptation decision?

25

p

RC1 :: Conclusion

OutlineDynamic Stack Adaptation



P i C S i




DynSSDynSS MaDMANMaDMAN

Passive Context Sensing


Case Study:MADServer







26


Context sensing and aggregation in DTNSg gg g

Many possibility for context-based adaptation

We focus on mechanics of sensing, aggregating, and adapting

o Table: Examples of context and its useso Table: Examples of context and its uses

27RC2 :: Context

Passive Context

Context can be expensive to collect Active context sensing approaches add to network traffic Active context-sensing approaches add to network traffic E.g., using pings to measure instantaneous latency Sharing coordinates for location-aware routing, or velocity information for

determining degree of mobility

DTNs are often over burdened So adding extra traffic is not always a good idea

Passive context sensing offers a solution with no communication goverhead PCS relies on intercepting and interpreting existing network traffic to

derive context Eavesdropping on wireless transmissions Works great for 802.11 Does not work for some mediums, eg. Bluetooth

28RC2 :: Passive Context Sensing

PCS Architecture

Our PCS architecture4

What kinds of context can we collect? Network Load: direct measurement of all (locally

seen) traffic overheard by a nodeseen) traffic overheard by a node Allows for prioritizing network operations, throttling communication, etc.

Network Density: a node’s one-hop neighbors Useful for congestion control mechanisms, etc.

Network Dynamics: a node’s mobility, relative to its neighbors Can predict probability of link failure etc Can predict probability of link failure, etc

4 A. Petz, T. Jun, N. Roy, C-L. Fok and C. Julien. “Passive Network-Awareness for Dynamic Resource-

29

Constrained Networks,” (DAIS '11).

RC2 :: Passive Context Sensing

Example: network load estimatorp

One example: Network Load: the total number of bytes seen in a specific

(configurable) time interval At time t, the network load metric at node i is:At time t, the network load metric at node i is:

nli(t) = ɣnli (t – v) + (1 - ɣ) nlim (t – v)

current estimateprior estimate

ɣ provides the discount factor for previous estimates


Implementation and Real-World Evaluationp

We implemented the PCS Suite for Linux Using the Click Modular Router as the framework

Evaluated implementation using autonomous robots from the Ph T tb dPharos Testbed

Used AODV implementation For comparability to existing For comparability to existing

simulated evaluation


PCS Conclusions

Provides context on which to base network stack adaptation Adaptive DTNs require inexpensive context acquisition and

aggregation techniques, and a framework to support them With the ability to add new metrics easilyWith the ability to add new metrics easily

The Passive Context Sensing Suite (PCS) provides implementations for simulation and an easily deployable Linux-based framework Click-based implementation for Linux nodes Modular and easy to modify Modular, and easy to modify

Demonstrated validity of passively sensed context using simulation and real-world experiments

32

p

RC2 :: Passive Context Sensing

Context Agent Framework (CAF)g ( )

A general-purpose context sensing, aggregation, and adaptation framework for DTNs

Design principles C t t t t b k i i Context types cannot be known a priori

Different types of context require different aggregation strategies E.g., system-, data-, user-, network-contextg y

Adding new types and aggregators to the framework should be easy Ease of programmer/network deployment use

33RC2 :: Context Agent Framework

Context Agent Framework architectureg

CAF consists of one or more context agents and the World View Context Agents: collect or adapt to context Gather context from network user system etc Gather context from network, user, system, etc. Post context samples to the World View Subscribe to context types in order to adapt to changes

World View: local context store World View: local context store Publish/subscribe semantics Shares ‘views’ between neighbors, merges new/updated context samples

Adaptation portal defines interface to external applications with

34

Adaptation portal defines interface to external applications with adaptation “hooks”

RC2 :: Context Agent Framework

CAF: implementationp Multi-threaded user-space application Easy to define new agents, new adaptation rulesy g p Very flexible architecture allows for limitless context usage

possibilities W itt i P l f f Li t i t ti Written in Perl for ease of Linux-system integration

35RC2 :: Context Agent Framework

Case Study: MADServery Mobile Advanced Delivery Server5

Context-based data offloadingContext based data offloading Send small (or high-priority) content over 3G E.g., HTML frame, text

Send large content over an offloading vector (WiFi/DTN/etc)Send large content over an offloading vector (WiFi/DTN/etc) E.g., video, large images

Based on client context (i.e., only do this when beneficial) What context to gather? What context to gather? What is useful for this scenario? E.g., contact/mobility/location patterns, system context, network status, data

prioritypriority

How to distribute and respond to context? Piggybacked on client request to web server Some context can be cached on server

36

Some context can be cached on server

5 A. Petz, A. Lindgren, P. Hui, and C. Julien. “MADServer: An Architecture for Opportunistic Mobile Advanced Delivery,” CHANTS 2012.

Case Study: MADServer (cont.)y ( )

Prototype built using Django web service middleware

Results

3G W F d l l3G vs. WiFi delivery latency

3G vs. WiFi bandwidth usage (16MB video file)

3G vs. WiFi delivery latency

3G vs. WiFi advanced delivery (20x 5MB image)

37RC2 :: Case Study :: MADServer




P i C S iP i C S i





Passive Context SensingPassive Context Sensing



Case Study:MADServerCase Study:MADServer







38


Complete systems solution for DTNsp y

Combining the CAF with a real DTN system Using context-based adaptation to enabled “smart” network coded

routing

We focus on network coded routing We focus on network coded routing Prior work on network-coded routing for DTN2 suffered from

“unintelligent” contact utilization6

Led to wasted bandwidth due to Lack of regard for the relative information diversity of different nodes

Lack of awareness of who should control the channel during contacts Lack of awareness of who should control the channel during contacts

In general, this is a problem for all DTN routing protocols Unless they specifically build in such intelligence

396 A. Petz, B. Walker, C-L. Fok, C. Ardi and C. Julien. "Network Coded Routing in Delay Tolerant

Networks: An Experience Report,” ExtremeCom 2011.

Motivation

Many DTN routing protocols utilize context to minimize overhead Each has specific mechanisms (e.g., RIB in Prophet) Lots of applicable context is not easily accessible from within BP

routing implementationsrouting implementations Aggregating “network” specific context requires a context-sharing

mechanism CAF presents a good framework where the World View holds entire collection of

relevant context

We are motivated by a desire to unify router intelligence We are motivated by a desire to unify router intelligence into a framework that can be used to adapt many different protocols across a wide range of available context

40RC3 :: System Solution for DTNs

Brief overview of network coding in DTNsg

Send linear combinations of bundle fragments A receiver can collect any N linearly independent pieces and recover

data

1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB1MB

Alice

∑

Bob Carol Robespierre

1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB


Context-aware network coded router The Context Aware Network Coded Router (CANCR)7

Built on primitives of a simple network coding router for DTNsBuilt on primitives of a simple network coding router for DTNs Which itself was collaborative work with our sponsors

Exposes several parameters to be tuned via context-based rules Rate: controls how fast a node sends encodings to a neighbor relative to how

fast it receives them from that neighbor

Weight: allows for bias in the selection of which GUID to favor when creating and forwarding encodings

Balance: relative channel distribution in the presence of multiple neighbors

i.e., weighted time division multiplexing

7 A. Petz, A. Hennessy, B. Walker, C-L. Fok, and C. Julien. "An Architecture for Context-Aware Adaptation of Routing in Delay-Tolerant Networks,"

42

ExtremeCom 2012.

RC3 :: System Solution for DTNs

CANCR AgentWorld View for indoor tests

g

Agent adapts the rate, weight, and balance Rele ant conte t t pes Relevant context types: Geo. location and destination (Geo-Context Agent) Information diversity Measure of total amount of information relative to decoding Measure of total amount of information relative to decoding The rank-reduced order of the decoding matrix

Data context Source of bundle, destination(s) of bundle, size , ( ) ,

System context Node role: hybrid context gained from geographical destination (e.g., static, or

mobile)

ld World View Publishes samples of geo-tagged information diversity and locations of

known sources and sinks S b ib t h t th

43

Subscribes to changes to the same


Components of our system implementationp y p



Context Agent to adapt CANC Router

Context Agent to adapt CANC Router

Framework (CAF)

Framework (CAF)

h lh l

DTN2 Reference Implementation of the

Bundle Protocol

DTN2 Reference Implementation of the

Bundle Protocol Geographical location and destination

context

Geographical location and destination

context

Bundle Protocol (middleware)

Bundle Protocol (middleware)

Context-Aware Network Coded

Router

Context-Aware Network Coded

Router

Pharos: Autonomous

outdoor mobility

Pharos: Autonomous

outdoor mobility

44

Commodity 802.11 WiFinetwork (Atheros chipset)Commodity 802.11 WiFinetwork (Atheros chipset)


CANCR Agent adaptation rulesg p

Our context-based adaptation rules Only one specific example of what is possible using the CAF





P i C S iP i C S i

Research Contribution 1Research Contribution 1 Research Contribution 2Research Contribution 2




Passive Context SensingPassive Context Sensing



Case Study:MADServerCase Study:MADServer

Research Contribution 3Research Contribution 3






46


System validationy Compared context-based adaptive network coding system (CANCR) with

non-adaptive network coding router (SimpleNC6) Using autonomous mobile robots from the Pharos Using autonomous mobile robots from the Pharos

Testbed Indoor experiments

Camera-based line-following for navigation Virtualized Testbed

Less realistic, can achieve a larger number of trials Outdoor experiments

Using GPS-based autonomous navigation Using GPS-based autonomous navigation

Communicating parties All experiments have some combination of static nodes and mules (mobile nodes)

Heterogenous, mixed DTNg

Data Each bundle is 100MB, and split into 1000 encodings of 10kB each

6 A P t B W lk C L F k C A di d C J li "N t k C d d R ti i D l T l t

47RC4 :: Validation

6 A. Petz, B. Walker, C-L. Fok, C. Ardi and C. Julien. "Network Coded Routing in Delay Tolerant Networks: An Experience Report,” ExtremeCom 2011.

Indoor Experimentsp

3-node experiment Single source, sink, mule

One 100MB bundle

5-node experimentp Single source, sink

Two mules

One intermediate host One intermediate host

One 100MB bundle

Indoor navigation Using line-following

Approximate locationsprovided by Pharos Testbed

48

controller

RC4 :: Validation :: Indoor Experiments

Indoor experiment results7p

3-node (left) and 5-node (right) decoding matrix ranks CANCR lt i l h d 2000 di 6000 CANCR results in less overhead— ~2000 encodings vs. ~6000 Due to more efficient link utilization

5-node experiment resulted in even greater latency and overhead

49

p g ygains

RC4 :: Validation :: Indoor Experiments

VMT experimentsp

Performed same experiment with Virtual Mesh Test (VMT) mobile wireless testbed

Commodity wireless hardware with an emulated channel

Mobility physically emulated using hardware attenuators to mimic path-loss y p y y g p(based on expected path loss calculation)

Very similar results to Pharos experiments In terms of decoding matrix rank vs time In terms of decoding matrix rank vs. time

Greater repeatability allowed us toprovide std. dev.p

50RC4 :: Validation :: VMT Experiments

VMT Results

Latency and overhead results7

7 A. Petz, A. Hennessy, B. Walker, C-L. Fok, and C. Julien. "An Architecture for Context-Aware

51

7 A. Petz, A. Hennessy, B. Walker, C L. Fok, and C. Julien. An Architecture for Context Aware Adaptation of Routing in Delay-Tolerant Networks," ExtremeCom 2012.

RC4 :: Validation :: VMT Experiments

Outdoor experiments Dell Diamond Baseball Stadiump

Similar variations to the indoor experiments Performed at the west parking lot

of the Dell Diamondof the Dell Diamond 30-60 minutes per experiment 3-5 robots per experiment Results are the culmination of 62 successful real-world experiments

Mobility ensured disconnections In combination with hardware attenuators used in some experiments

52RC4 :: Validation :: Outdoor Experiments Satellite image from maps.google.com

Outdoor experiments (cont.)p ( )

3-node experiment Single mule 1 or more bundles

R lt h f Results shown are fromsingle-mule, single-bundle

Channel prioritization leadsChannel prioritization leadsto better efficiency With SimpleNC, sometimes

mule would starve the source or the sink would starve the mule

53RC4 :: Validation :: Outdoor Experiments

Outdoor experiments (cont.)p ( ) Single-Mule, Multi-Bundle 2x 100MB bundles One from Guinness Spaten, one vice versa

4-node (two mule) experiments are similar


SimpleNCCANCR

Outdoor experiments (cont.)p ( )

5-node experiments Single source, multiple sinks

Varied hardware attenuation3dB 10dB 3dB – 10dB

New context-adaptation rule To account for different mule paths and different sink locations To account for different mule paths and different sink locations Sink locations discovered through geo-tagged context sampling and sharing

Addition was made in the field


Outdoor experiments (cont.)p ( ) Results from 2 mule, 2 bundle experiment

6dB attenuation

Even more significant gains over SimpleNC due better channel utilization


SimpleNCCANCR

ConclusionsCommunicating parties in a DTN want their connections supported by the bestcombination of protocols and protocol parameterizationsCommunicating parties in a DTN want their connections supported by the bestcombination of protocols and protocol parameterizations

This dissertation enables context-based network stack adaptation for DTNs Two novel architectures: DynSS and MaDMANy Rely on context to inform stack adaptation mechanism

Provides mechanisms to gather, share, and adapt-to context Passive context sensing for DTNsg Context-based adaptation framework Integrated with the Bundle Protocol and the DTN2 Reference middleware Concepts validated using Pharos Testbed and further validated by case study using

d DTN f ll l k (MADS )context and DTN concepts for cellular networks (MADServer) Flexible context agent allows for aggregation of many types of context, and allows for

many types of adaptations

Context-based adaptation can improve efficiency and latency

57

Context based adaptation can improve efficiency and latency Verified for network coded routing Hypothesis: it will work for other routers as well

Impactp

This dissertation offers several unique, first-of-their-kind contributions: G l t t b d t k t k d t ti hit t f General-purpose context-based network stack adaptation architectures for

delay-tolerant networks (DynSS, MaDMAN) First proof-of-concepts and real-world analyses

G l t t i iti f k f DTN (CAF) General-purpose context acquisition framework for DTNs (CAF) And the first to integrate externally gathered context and internal DTN2 Reference

Implementation routers

External convergence layer architecture and implementation External convergence layer architecture and implementation Won best paper at ExtremeCom, a DTN workshop (now conference)

Implementation and real-world deployment of network coding Also first to offer context based optimizations to improve latency and overhead Also first to offer context-based optimizations to improve latency and overhead

performance in a real-world evaluation setting

First usage of autonomous robots to form real-world DTNs to test protocol behavior

58

Thanks!

?/!

59

Future Work

Optimizing context sharing for DTNs As number of context samples grow, so does World View and sharing

overhead Efficiently summarizing context could leverage projects like Grapeviney g g p j p

General purpose delay-tolerant routing algorithm The holy grail!

l fl bl b d f d l h h l A single, flexible, basic store-and-forward routing algorithm that is entirely controlled by rules written in the Context Agent Framework

Context-based routing to replicate, simplify, and expand upon existing routers

Unifying different “optimal” protocols into a single router, and using context to determine how to proceed

60

p

Publications C. Julien, A. Petz, E. Grim. “Rethinking Context for Pervasive Computing: Adaptive Shared Perspectives,” invited, to appear in

International Symposium on Pervasive Systems, Algorithms, and Networks. 2012

A P t A Li d P H i d C J li "MADS A A hit t f O t i ti M bil Ad d D li " A. Petz, A. Lindgren, P. Hui, and C. Julien. "MADServer: An Architecture for Opportunistic Mobile Advanced Delivery," Proceedings of the ACM MobiComWorkshop on Challenged Networks. 2012.

A. Petz, C-L. Fok, and C. Julien. "Experiences Using a Miniature Vehicular Network Testbed," Proceedings of the ACM International Workshop on VehiculAr Inter-NETworking, Systems, and Applications. 2012.

A. Petz, A. Hennessy, B. Walker, C-L. Fok, and C. Julien. "An Architecture for Context-Aware Adaptation of Routing in Delay-T l N k " P d f h 4 h E C f C 2012Tolerant Networks," Proceedings of the 4th Extreme Conference on Communication. 2012.

A. Petz, B. Walker, C-L. Fok, C. Ardi and C. Julien. "Network Coded Routing in Delay Tolerant Networks: An Experience Report," Proceedings of the 3rd Extreme Conference on Communication. 2011.

B. Walker, C. Ardi, A. Petz, J. Ryu and C. Julien. "Experiments on the Spatial Distribution of Network Code Diversity in Segmented DTNs," Proceedings of the ACM MobiCom workshop on Challenged Networks (CHANTS '11).g g p g

A. Petz, T. Jun, N. Roy, C-L. Fok and C. Julien. "Passive Network-Awareness for Dynamic Resource-Constrained Networks," Proceedings of the 11th IFIP International Conference on Distributed Applications and Interoperable Systems (DAIS '11).

A. Petz, B. Walker, C. Ardi and C. Julien. "The Click Convergence Layer: Putting a Modular Router Under DTN2," Proceedings of the 2nd Extreme Workshop on Communication. 2010. Received Best Paper Award

A Petz and J Enderle and C Julien "A Framework for Evaluating DTN Mobility Models " Proceedings of the 1st Workshop on A. Petz and J. Enderle and C. Julien. A Framework for Evaluating DTN Mobility Models, Proceedings of the 1st Workshop on Scenarios for Network Evaluation Studies. 2009.

A. Petz and C. Julien. "An Adaptive Architecture to Support Delay Tolerant Networking," Proceedings of the 7th Workshop on Adaptive and Reflective Middleware. 2008.

A. Petz and C. Julien. "The MaDMAN Middleware for Delay-Tolerant Networks," Poster at HotMobile '10 (Proceedings of the 11 h k h M bil i d li i ) 2010

61

11th workshop on Mobile computing systems and applications). 2010.

Extra Slides

****************************************************

62

Case Study: MADServery

System Architecture Server-Side web service architecture

63RC2 :: Case Study :: MADServer

Why do Network Coding?y g

Research shows several benefits Erasure coding can improve worst-case delay Can increase throughput when mobility is non-homogeneous Better transmit power vs delay tradeoff Better transmit power vs. delay tradeoff

Overall performance of NC compares favorably to probabilistic protocolsp

64

Network Codingg

How it works First a node generates a bundle:

BUNDLE

65

Network Coding (cont.)g ( )

If bundle is too big to be transferred in a single contact (and it b bl i ) h b dl i f dprobably is), the bundle is fragmented

Bundles split into M (non-encoded) fragments

BUNDLE

X0 X1 X2 X3 X4 X5 X6 X7

66


Fragments are combined according to randomly chosen coefficient d dvectors to create codewords

++X0 X3 X4<1 0 0 1 1 0 0 0>: ++ = Wx

<0 0 0 1 1 0 0 0>: X3 X4+ = Wy

<1 0 0 0 1 0 0 0>: X0 X4+ = Wz

67


Encoded fragments are then sent in their own bundle tagged with the di d i i l GUIDencoding vector and original GUID

Receivers maintain decoding matrices to check whether un-encoded bundles can be recovered Full-rank is needed to decode

Inverting matrix yields the linear solution to recover original fragments, and thus the bundlethus the bundle

68

NCBundleCollection

69

Routers

We provide both an erasure-coding and network-coding router SimpleECRouter - Erasure coding router Given an available link to a neighbor, randomly selects encoding from a

random NCBundleCollection

When send is completely, repeats

All encoding done at the application layer

SimpleNCRouter implements full network coding SimpleNCRouter – implements full network coding Encoding done in router

Dynamically creates new encodings

Re-encodings possible (linear combinations of codewords)

70

SimpleNCRouterp

Decoding and/or re-encoding

71

EvaluationEvaluation

Compared Flood Routing with p gNetwork Coding

Using autonomous mobile robots GPS for navigation Linux v.2.6 with x86 motherboards C dit Ath 802 11b/ Commodity Atheros 802.11b/g

wireless cards (running MadWifi)

72

Experimental Setupp p

One source, one sink, and one data ‘ferry’ Source and sink cannot communicate except through ferry Source generates a 100MB file Fragmented into 2098 50KB encoded bundles Fragmented into 2098 50KB encoded bundles

For fairness, FloodRouter sends fragments as well

Two movement patterns: synchronous and asynchronous Synchronous keeps source & ferry in contact until all bundles are transferred

Asynchronous decouples movement from communication

73

Single Ferry Synchronous Movmnt.g y y

FloodRouter vs. Erasure-Coded (EC) Router( )

Coupon collectors problem

74

Single Ferry Asynchronous Mvmnt.g y y

Using Erasure Coding (EC) Router

75

Single Ferry Asynchronous Mvmnt.g y y

Using Network Coding (NC) Router

76

Pharos Testbed

Presenting Pharos Mobile and Pervasive Computing Testbed[1]

Small-scale

Autonomous (GPS and digital compass)

Modular (hardware and software) Modular (hardware and software)

Commercial, off-the-shelf

Inexpensive (~$2500 per node)

[1] http://pharos.ece.utexas.edu/

Inexpensive (~$2500 per node)

77

[1] http://pharos.ece.utexas.edu/

Pharos Testbed Architecture

78

Supporting Network Experimentspp g p

Simulations are still important

We want to be able to simulate and deploy implementations

A d th l t th And then relate the results to each otherto reason aboutperformance!

79

Pharos Software Architecture

Java-based experiment control middleware Centralized controller creates

experiment object experiment object Encompassing all experiment

variables and parameters

Once experiment object is Once experiment object isdeployed, the nodes are fully autonomous and(probably) disconnected from(probably) disconnected fromthe central controller

80

Pharos Software Arch. (cont.)( )

The middleware can launch any number of arbitrary programs E.g., the experiment Any Linux-based code will work Programs have access to testbed info (location speed GPS time Programs have access to testbed info (location, speed, GPS-time,

battery, etc.) through the Pharos API Experiment examples: opportunistic routing, network coded routing, mobility

heuristic collection (neighbors, interconnect times, etc.)

81

Relating results back to simulationg

Comprehensive framework for dual sim./real-world analysis and mobility replay

82

Collecting Heuristicsg

Our framework allow us to collect the following in both simulation and real-world experiments Position vs. time, neighbors, unique neighbors Partition: size memberships disconnected nodes Partition: size, memberships, disconnected nodes Message delivery possibility Independent of routing

Baseline for best-case performance (especially relevant to opportunistic networks)

83

Early Resultsy

Experiment setup: Simple ‘lollipop’ mobility pattern 9 robots, start 30s apart 1 5 2 m/s speed 1.5-2 m/s speed UDP-based beacons To compare real connectivity to

150m

‘expected’ simulated connectivity

1 sec interval, 64B packet length

Comparing simulated vs real

m

Comparing simulated vs. realconnections

84 77m

Early Results (cont.)y ( )

Framework allows us to reason about effective radio range Which can depend on the network usage as well as

l i d di !location and radio range!

85

Other Pharos Capabilitiesp

Indoor tests! For convenience or

inclement weather reasons

86

context-based adaptation in delay- tolerant...

Documents