intentional networking brett higgins, azarias reda, timur alperovich, jason flinn, t.j. giuli...
Post on 21-Dec-2015
216 Views
Preview:
TRANSCRIPT
Intentional Networking
Brett Higgins, Azarias Reda, Timur Alperovich, Jason Flinn, T.J. Giuli (Ford), Brian Noble,
David Watson (Ford)
The problem
Mobile devices experience significant network diversityas they move……as other devices come and go……across many different technologies.
Not all messages are created equalsome traffic latency sensitive,for some, eventual delivery is okay,some is purely opportunistic.
Current systems eitherhide all of these details, inevitably mismatching
traffic, orexpose all the messy details, complicating
applications
The Insight
Separate concernssystem layer tracks, measures connectivity optionsapplications describe their trafficsystem matches traffic to the right alternative
Be qualitativeapplications specify only simple labelsforeground vs. background; small vs. large
Embrace concurrencymultiple networks ~ multiple coresabstractions for safe (network) concurrency
Abstraction: Multi-Sockets
Client Server
A socket: single connection between correspondent hosts
ININ
Abstraction: Multi-Sockets
Client Server
Multi-sockets provide a “virtual connection”
ININ
Multi-Sockets
Client Server
Multi-sockets provide a “virtual connection”as alternatives come and go
ININ
Multi-Sockets
Client Server
Multi-sockets provide a “virtual connection”as alternatives come and go
and measure the performance of each
Multi-sockets extend interface
Can use the standard interfaceapplication provided with TCP semanticstransparently pick the “best” option available at any
time
Easy extension: what should “best” mean?optional label: small (latency) or large (bandwidth)
Interesting extension: what is important?another label: foreground or backgroundforeground always* goes first
Not ordered! That’s crazy talk!
Not with the right abstractionsmutual exclusionhappens-before
Applications can specify units of mutual exclusion...one or more send calls
…and the partial order on those unitsnaming prior units as dependencies
By default, each send() depends on the prior oneapplications must explicitly relax ordering
Example Application: BlueFS
A DFS for mobile devices, consumer electronicsRPC plus a bulk-transfer protocolon-demand and speculative fetcheswrites propagated asynchronously
Intentional Networking modificationsRPC stub generator: takes labels, ordering
constraintson-demand block fetch: {foreground, small}data pre-fetch, write-back: {background, large}writes must be played back in order
Less than 550 lines of code (out of >44K)~400 in stub generator
How did we do?
Evaluation environment: trace-based replaynetwork observed during two live vehicle drivesrun Andrew-style benchmark under those
conditions
Compare Intentional Networking to three selection strategiesalways the lowest latencyalways the highest bandwidthminimum latency, sum of all bandwidths
IntuitionTotal task time: beat single-networks, approach
blendResponse time: leverage hints for a big win
Results
Scratching the surface
More detailsexpose events to applicationskeep background traffic out of the waymore applications, experiments
Other things to think aboutinfer labels in existing applications?infer “foreground” from user behavior?express cross-application tradeoffs easily?
A couple other things in the hopperinformation access in the developing world (Azarias)“smooshed migration” of clients across access points
top related