Hi, my name is Jing and I’ll be presenting Haggle. Haggle is a systems solution that simplifies mobile networking for applications. This is work I participated in as an intern at Intel Research Cambridge. A significant amount of this project was already underway well before I arrived, and one of the principle architects is James Scott, who is now at Microsoft Research Cambridge.
Many other individuals were instrumental in the design and implementation of the architecture. This talk will mostly be at a high level, trying to give the basic flavor and motivation for the Haggle architecture. The main focus of the talk will be on the concept of the architectural design and some of the interesting aspects of what it enables. For many other considerations and details not mentioned in this talk, I encourage you to refer to the paper.
* Spell out, they’re mobile I’m going to start this presentation with a running scenario…. a challenge, if you will. The challenge is as follows. Bob and Alice are both mobile users, attending a conference. Bob, who is sitting next to Alice, wants to send her an email thread discussing an attached PowerPoint presentation. So what would the obvious solution be? Well, just use email! But there’s a slight snag, no cellular coverage.
Okay so cellular is out. What about a hotspot access point? This also might be unavailable. No coverage, over-congested, or they could be non-open or non-free.
Okay so they decide that they both have capable devices so their establish some kind of ad hoc peer to peer link to send the email over. Amazingly, this won’t work either! Even with their devices linked, the email will refuse to be sent.
So they give up and use a USB key to transfer the PowerPoint file. While this works in getting the PowerPoint transferred, something really important got lost… we lost the email context around the PowerPoint. It’s no longer an email. How to see the thread of discussion, the participants, email addresses, times of discussions, etc.
So why doesn’t email work in ad hoc connections? It’s because Bob’s email client has built-in logic that ties it to the Internet. Specifically, to deliver email, it tries to use DNS to look up the Mail Exchange record for the domain portion of Alice’s mail address. Obviously in ad hoc the DNS is not available.
(pause, slow down) The bullet points are a bit sparse and don’t say much to someone if they don’t catch what I’m saying. Spend some more time relating back to the example. Explain the observational points. We observe that mobile networking experience is very poor. Users have to manually configure and manage their devices and applications because application logic is intertwined with the underlying network technology. As a result, applications cannot react to or take advantage of rich mobile environments. But there’s hope. The mobile hardware works. What we need is a systems software solution.
The solution is the separate applications from the complexities of underlying networking concerns. Allow applications to focus on their logic and serving the user. Once the networking concerns have been separated, we develop a new node architecture for the mobile device that manages the node’s networking. This new networking architecture tackles the challenges of mobile networking using two techniques: First, late-bind the networking resources based on the devices capabilities, such available battery power and radio types; the networking context; and user preferences such as high/low priority messages and willingness to pay for certain networks. Second, provide integrated resource management so that networking resources are used effectively and in a manner consistent with the user’s preferences. Haggle simplifies the user’s model of mobile device networking. One application for one user level purpose. If the user wants to use email to send a message and attachment, and the network is there, it should just work.
What’s in an application from the perspective of mobile networking? An application has Data that it externalizes to some kind of persistent store, but how that bucket of bits is interpreted, the meta-data, is internal to the application logic. Application logic also contains the set of protocols that the application knows how to communicate over, and the type of network interface it can use those protocols over.
For an email client the data contains the bits for messages, folders, and attachments, but how to interpret these bits is in the application logic which knows how to interpret this meta-data. The protocols that a mail agent understands would be POP and SMTP, using a TCP/IP socks interface.
We need to externalize the network interfaces, such as WiFi or Bluetooth, from the application as well as the protocol that is used over the interface. We also externalize the meta-data to support deep introspection by the network architecture so that the appropriate transformations can be applied depending on the late bound protocol and network interface. For example, to reach an individual, Haggle may need to transform an email to a MMS. You need the meta-data to transform the rich text and attachments.
To recap, we’ve separated networking from applications to enable seamless mobile networking. So how do we build a new networking architecture which enables seamless mobile networking? To understand this, we need to understand what are mobile networking environments, and what it means to seamlessly move through them. Haggle considers three main categories of networking environments: infrastructure, ad hoc, and delay tolerant or pocket switched networks.
We’ll use an example to illustrate what Haggle means by seamless mobile networking across dynamic mobile environments. Bob starts his week at his office where life is good and Internet and infrastructure is freely available. He then travels to a conference where he has many discussions with colleagues. In these discussions, they want to exchange data and messages, so their devices form ad hoc networks. Infrastructure isn’t available everyone’s device has to cooperate and help forward each others’ packets. Bob then travels to a rural location to study how Ubicomp technologies can help improve health-care. The only means of networking is via a delay tolerant network provided by a postal truck doing daily rounds. Here the device must understand how to operate under long periods of disconnect. In these different networking environments, how endpoints are addressed, the method of transport, and the expectations of the network behavior can vary dramatically. These dramatically different network characteristics is what makes existing apps unable to cope.
The Haggle architecture provides a data-centric application API which allows them to work free from network complexities. Instead of a rigid layered architecture, Haggle’s compartmentalized managers handle the late-binding of endpoint names, forwarding algorithms for pushing data, protocols used for encoding data, and interfaces used to communicate over. Next I will talk about how Haggle uses late-binding to determine HOW the networking resources get used. Then I will describe the integrated resource management which determines WHEN the networking resources get used.
Need a quick re-cap that we’re going to talk about how late-binding is going to take place. Clarify (more slowly) that we have a rich name graph but here it is a compressed simplified set.
Before transition to next slide…. These are paths. Now we will talk about how haggle determines which paths to take and when.
Need a re-cap. Late binding shows how to take action. How do we know WHEN to take action. Stop talking from perspective of Task. Just say, actions are delegated. There are things we need to consider: the benefit of the action, and the cost of the action. All requests for action in Haggle are expressed as Tasks. Tasks take into consideration two functions, the benefit of the task as well as its cost. As device and networking conditions change, the benefit and cost functions for the task return different values. The resource manager performs a cost/benefit comparison to decide which actions to allow and when.
Reword first bullet: Enable new application features * easy to express optional or async tasks By delegating and late-binding actions, applications can easily express many desired actions, such as a web browser requesting predictive downloads of links and popular bookmarks, high priority operations for pages the user is actively waiting on, or hoarding requests. Unlike traditional applications where too many simultaneous network sockets can overwhelm the system or cause it to use resources poorly, the haggle architecture balances when and how network resources are best used.
We implemented support for two legacy applications, messaging via email as well as web browsing. With Haggle enabled web-browsing, you can search for data in the caches of other Haggle peers when the infrastructure is not available. For example, at a conference where the AP is congested, it is likely someone has a cached copy of the conference schedule and proceedings. It’s in the environment, my device should be able to find it. * Maybe break into 2 slides…. Second slide talking about the prototype applications of the prototype arch. Use a picture (figure) to make the apps nice looking and easy to understand.
Take some more time (short) mention some interesting aspects about the implementation and explain the behaviour we see. * Must mention… for haggleboth - adhoc/ap is a limitation of how WiFi is used. We can have stuff like multi-net to fix these problems.
Emphasize that p2p is giving key new functionality that you otherwise cannot get.
Haggle is a stab at a clean-slate redesign of the network architecture for mobile devices. Haggle eases the ability to design applications for mobile network environments by taking the networking out of the application. The result is a cleaner model which allows users to use familiar apps without having to be networking experts. The networking model is: if data could get there or be found there, Haggle enables it.
To protect data, we can use existing solutions of cryptography, provided that it doesn’t require synchronous access to some highly available third party. This is because the third party might not be available in all situations. Enabling greater ability to use the rich mobile environment also creates a new threat to privacy, in that it potentially allows you to be tracked. Also, because the name graphs in forwarding objects are richly populated, there can be significant private information in it. There are possible solutions that can help address this, such as forwarding algorithms which are aware of social circles and only forward detailed private information to known contacts.
With the Haggle framework applications can very easily make predictive hoarding requests easily according to user preferences instead of worrying about networking code. Applications can now automatically make resource consumption decisions according to user preferences. For example, the user wants their vacation photos uploaded to Flickr, but not via expensive GPRS.
To describe the problem, let’s start with a scenario. Suppose Bob wants to send a message to Alice. Though I call it a message here, we can imagine a more concrete and common example, such as an email thread discussing the revisions for a PowerPoint presentation. The obvious choice is to use email to send the message. However, there are some potential snags. There might not be hotspot or cellular coverage available, or the monetary costs to use them at the moment are too high. So what do they do? The current solutions available to day require manual labor. They could reconfigure their devices to connect ad hoc (BT or WiFi) and perform a p2p file transfer, or more commonly, the would use a USB key to transfer the file. But this band-aid solution that we use today is incomplete, because it loses the context of file. In the case of the power-point presentation, the entire thread history is lost. Of course there are many possible work-arounds to attempt to preserve this context, but none of them work universally and require significant user intervention. For regular users Bob and Alice, it’s not obvious why they can’t email each other even after they managed to connect their devices via a BT ad hoc network.
Another scenario which exemplifies the shortcomings of the current state of the art is the inability to ask for content from other mobile peers. For example, suppose you were at a conference and you want to look up some local restaurant information, or read today’s news headlines because you were bored. Chances are, this kind of information is available in the caches of the peers around you. Unfortunately, you can’t get at it, even if the peers are willing to share it with you. Even if I wanted to share a cached page with someone else using a USB key to transfer the page, I would have a hard time finding the right cache file and necessary related files to reconstruct the page.
The underlying problem is that the current layered networking architecture forces applications to specify many networking details, such as binding endpoints, communication protocols, and network interfaces to use. Designing and building an application which supports dynamic selection and binding is very difficult. As a result, applications are designed to an assumed set of networking conditions and availability of certain services (such as DNS). Because applications are not designed for dynamic mobile environments, managing and coordinating resource usage is hard. Right now, we leave it to the user to decide what apps to run or what operations to perform. The result of having specific applications targeted for specific networking conditions and leaving it to users to choose and toggle between them is that applications internalize all of their data and meta-data context because it was previously not possible to cooperatively use and share this information. This is what leads to the current state of systems, where even if we wanted to cooperate and share in this rich mobile environment, it is very hard.
Haggle’s proposed solution is the free applications from networking responsibility. Applications use a data-centric model of focusing on their processing logic, and procuring and disseminating data. We provide a mechanism that makes it easy and natural for applications to expose meta-data and relationships of their data for their own purpose. This same mechanism allows applications to search and procure data easily between applications as well as across applications on different nodes. The haggle node architecture manages the core networking logic, allowing it to make dynamic binding and resource management decisions. The result is that applications are now able to dynamically function across mobile environments seamlessly.
Because mobile devices can dynamically transition across many different types of networks, ranging from well connected infrastructure to highly disconnected pocket switched networks, Haggle must support all of these networking modes in its design for handling networking logic. An important aspect of this consideration is the basic problem of Naming. Depending on the networking context, directory services for resolving names may be different or completely unavailable. Furthermore, names which are usable in one network, for example email addresses, have no context in other networks such as bluetooth piconets. To support all of the targeted network types, Haggle must provide a rich naming system. Depending on the network type, forwarding decisions can be dramatically different with different anticipated results. Infrastructure networks can expect near-guaranteed endpoint-to-endpoint reachability without need for cooperation. MANETs can reasonably expect endpoint rechability but requires cooperation. And PSN expects long disconnects using store and forward; and depending on the protocol, cooperation may or may not be necessary. How to forward messages as well as when to perform which actions due to changing power, priority, and cost conditions are decisions no single application can make alone. By externalizing the forwarding mechanisms and resource management decisions, we can potentially run many different forwarding algorithms simultaneously. The resource management system will be able to choose the best forwarding mechanism based on the current context.
The result is that applications can focus serving the user, and has a simpler interface for procuring, disseminating, and searching for data regardless of the network.
The basic building block of Haggle’s data model is the Data object. Each data object contains an arbitrary number of type/value attribute pairs. These attributes are used for expressing both the data content as well as the meta-data context. Data objects can be linked together using directed edges to express relationships, structural organizations, and ownership.
There are several specialized data object types in Haggle, of which I’ll highlight a few. One of the specialized types is a data object filter which is what applications use to search for data. Filters can be made persistent, so that they have a “subscribe” type of behavior instead of a simple one-off.
Messages are marked by a special data object called a forwarding object. The forwarding object contains links to the set of data objects which need to be sent, as well as a rich graph of name objects describing the intended recipient.
An interesting and powerful specialized data object is the data object filter. These filter objects not only allow us to search for data locally, but also to express subscription requests to other local applications as well as applications on remote nodes. Data object filters consist of a regular expression describing the kinds of data objects to acquire. The filter objects can be one-time or persistent. For example, the data object filter mechanism is how a Haggle-enabled web browser can query for all data objects in nearby nodes which have HTTP content containing the keyword “news”.
Forwarding objects are special data objects containing meta-data such as priorities and TTL. The forwarding objects themselves contain links to all related data objects as well as graphs of names for the intended recipient. Because the full structure of the name is sent, intermediary nodes can make the best forwarding decision given their current context.
Haggle embeds data object information as a a hidden attachment. If the receiving node is Haggle enabled it will properly unpack and integrate this information. What’s interesting is that we can use the email infrastructure as a store-and-forward medium for more than just simple mail messages. It can be used to communicate all kinds of information automatically transparent to the user.
Point out semi-log graph. (only if questioned.)
P2P web results perform faster in the complex rotten tomatoes case (over “no haggle”) because the meta-data structure indicated what related objects were needed and shipped all of the data objects together instead of requiring multiple round trips up and down from the browser and into Haggle.
Haggle: Seamless Networking for Mobile Applications Jing Su University of Toronto (interned at Intel Research Cambridge) James Scott Microsoft Research Cambridge (previously Intel Research Cambridge)
Haggle: Seamless Networking for Mobile Applications Eben Upton, Meng How Lim (Intel Research Cambridge) Ashvin Goel, Eyal De Lara (U. of Toronto) Jon Crowcroft, Pan Hui (Cambridge University) Christophe Diot (Thomson) In collaboration with others from the EU-funded project
What’s in an App? Application Logic Network Code Protocol(s) Data Metadata
What’s in an App? Application Logic Network Code Protocol(s) Data Metadata Email client Mail Files POP/SMTP TCP/IP Messages, attachments, folders, tags, flags, etc
Externalize Data and Networking Application Logic Wifi Network Code Email Protocol HTTP Protocol P2P Protocol Bluetooth Network Code Metadata Data Data and Meta-Data Storage Protocols Network Interfaces
Separate networking from application to enable seamless mobile networking
What are mobile networking environments?
Delay Tolerant / Pocket Switched Networks
Haggle targets all environments
The Mobile Networking User Infrastructure Ad Hoc Network Delay Tolerant Naming: IP, DNS Forwarding: dedicated routers everything is reachable Naming: MAC address, peer discovery Forwarding: ad hoc, cooperative forwarding peers are reachable Naming: MAC, IP, … Forwarding: postal truck routing long disconnects
important tag work tag . . . data pdf file type … … [email_address] from Blah text Rfc822 (email) type
Data Object Filters no persist is MP3 and has tag U2 regex Filter object yes persist is HTML and contains news and timestamp > 30 minutes ago regex Filter object
Forwarding Objects important tag work tag . . . data pdf file type important Flag Blah text Email message type “ Alice Smith” Name Name object [email_address] Name Name object 00:12:EF:… Name Name object PDA device Name Name object high priority 255 TTL Forwarding object
Data Object Filters are Powerful Mechanisms Subscribe (send all photos created by user X to X’s PC) “ Web” Search (find “london restaurants”) Remote Listen (wants to receive incoming data) “ Desktop” Search (find mp3s with artist “U2”) Local Persistent One-Off
Haggle Application Interface Applications (messaging, web, etc) Protocol Resource Data Name Connectivity Forwarding Connectivities (WiFi, BT, GPRS, etc) 5. Set task “send via X” 6. Execute (when worth it) 1. Insert data 7. Send! 2. Insert names 3. Call “send” 9. Raw data 10. Connect & transmit 8. Get & encode data 4. Decide next hop X