intentional networking

Download Intentional Networking

Post on 22-Feb-2016




0 download

Embed Size (px)


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 diversity as they move as other devices come and go - PowerPoint PPT Presentation


Slide 1

Intentional NetworkingBrett Higgins, Azarias Reda, Timur Alperovich, Jason Flinn, T.J. Giuli (Ford), Brian Noble, David Watson (Ford)1The problemMobile devices experience significant network diversityas they moveas other devices come and goacross 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 InsightSeparate concernssystem layer tracks, measures connectivity optionsapplications describe their trafficsystem matches traffic to the right alternativeBe qualitativeapplications specify only simple labelsforeground vs. background; small vs. largeEmbrace concurrencymultiple networks ~ multiple coresabstractions for safe (network) concurrency

Abstraction: Multi-SocketsClientServerA socket: single connection between correspondent hostsININAbstraction: Multi-SocketsClientServerMulti-sockets provide a virtual connectionININMulti-SocketsClientServerMulti-sockets provide a virtual connectionas alternatives come and goININMulti-SocketsClientServerMulti-sockets provide a virtual connectionas alternatives come and goand measure the performance of eachMulti-sockets extend interfaceCan 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! Thats crazy talk!Not with the right abstractionsmutual exclusionhappens-beforeApplications can specify units of mutual or more send callsand 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: BlueFSA DFS for mobile devices, consumer electronicsRPC plus a bulk-transfer protocolon-demand and speculative fetcheswrites propagated asynchronouslyIntentional 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 orderLess than 550 lines of code (out of >44K)~400 in stub generatorHow did we do?Evaluation environment: trace-based replaynetwork observed during two live vehicle drivesrun Andrew-style benchmark under those conditionsCompare Intentional Networking to three selection strategiesalways the lowest latencyalways the highest bandwidthminimum latency, sum of all bandwidthsIntuitionTotal task time: beat single-networks, approach blendResponse time: leverage hints for a big win

ResultsTime (seconds)Time (seconds)

Scratching the surfaceMore detailsexpose events to applicationskeep background traffic out of the waymore applications, experimentsOther 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