context-based adaptation in delay- tolerant...
TRANSCRIPT
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
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
Complete Systems Solution• For network coded routing in DTNs
Validation• Using autonomous robots from Pharos Testbed
Validation• Using autonomous robots from Pharos Testbed
Research Contribution 4
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)
TCP delivered 47k packets (0%
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)
delivered 85k packets (80% improvement)
Dyn
am
12RC1 :: DynSS
Long DelayLong Delay
TCP delivered 32k packets (0%
loss)
TCP delivered 32k packets (0%
loss)C
P-on
lyT
C
Dynamic Dynamic mic Dynamic
delivered 60k packets (90% improvement)
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
•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
Architectures• Proof-of-concept implementations
DynSSDynSS MaDMANMaDMAN
Passive Context Sensing
Context Agent Framework
Case Study:MADServer
Research Contribution 3
Complete Systems Solution• For network coded routing in DTNs
Complete Systems Solution• For network coded routing in DTNs
Validation• Using autonomous robots from Pharos Testbed
Validation• Using autonomous robots from Pharos Testbed
Research Contribution 4
26
• Using autonomous robots from Pharos Testbed• Using autonomous robots from Pharos Testbed
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
30RC2 :: Passive Context Sensing
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
31RC2 :: Passive Context Sensing
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
OutlineDynamic Stack Adaptation
•ArchitecturesDynamic Stack Adaptation
•ArchitecturesContext Sensing and AggregationContext Sensing and Aggregation
P i C S iP i C S i
Research Contribution 1 Research Contribution 2
Architectures• Proof-of-concept implementations
Architectures• Proof-of-concept implementations
DynSSDynSS MaDMANMaDMAN
Passive Context SensingPassive Context Sensing
Context Agent Framework
Context Agent Framework
Case Study:MADServerCase Study:MADServer
Research Contribution 3
Complete Systems Solution• For network coded routing in DTNs
Complete Systems Solution• For network coded routing in DTNs
Validation• Using autonomous robots from Pharos Testbed
Validation• Using autonomous robots from Pharos Testbed
Research Contribution 4
38
• Using autonomous robots from Pharos Testbed• Using autonomous robots from Pharos Testbed
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
41RC3 :: System Solution for DTNs
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
RC3 :: System Solution for DTNs
Components of our system implementationp y p
Context Agent Framework
Context Agent Framework
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)
RC3 :: System Solution for DTNs
CANCR Agent adaptation rulesg p
Our context-based adaptation rules Only one specific example of what is possible using the CAF
45RC3 :: System Solution for DTNs
OutlineDynamic Stack Adaptation
•ArchitecturesDynamic Stack Adaptation
•ArchitecturesContext Sensing and AggregationContext Sensing and Aggregation
P i C S iP i C S i
Research Contribution 1Research Contribution 1 Research Contribution 2Research Contribution 2
Architectures• Proof-of-concept implementations
Architectures• Proof-of-concept implementations
DynSSDynSS MaDMANMaDMAN
Passive Context SensingPassive Context Sensing
Context Agent Framework
Context Agent Framework
Case Study:MADServerCase Study:MADServer
Research Contribution 3Research Contribution 3
Complete Systems Solution• For network coded routing in DTNs
Complete Systems Solution• For network coded routing in DTNs
Validation• Using autonomous robots from Pharos Testbed
Validation• Using autonomous robots from Pharos Testbed
Research Contribution 4
46
• Using autonomous robots from Pharos Testbed• Using autonomous robots from Pharos Testbed
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
54RC4 :: Validation :: Outdoor Experiments
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
55RC4 :: Validation :: Outdoor Experiments
Outdoor experiments (cont.)p ( ) Results from 2 mule, 2 bundle experiment
6dB attenuation
Even more significant gains over SimpleNC due better channel utilization
56RC4 :: Validation :: Outdoor Experiments
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
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.
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 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
Network Coding (cont.)g ( )
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
Network Coding (cont.)g ( )
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
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
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
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/
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