343-2008.doc

Stanford Expedition: Programmable Open Mobile Internet (POMI) 2020

Programmable Open Mobile Internet 2020

Dan BonehAndrea GoldsmithRamesh JohariPaul KimScott KlemmerChristos KozyrakisMonica LamPhil LevisDavid MazieresNick McKeownJohn MitchellGuru ParulkarArogyaswami PaulrajMendel RosenblumFouad Tobagi

Computer Systems LaboratoryStanford University

April 1, 2008

1


Project Summary: Programmable Open Mobile Internet 2020We are on the verge of a new computer and communication revolution where billions of users will

carry smart handheld devices with high-speed network connectivity. Low-cost open handheld computing platforms, with ubiquitous high-bandwidth connectivity, create an opportunity for innovation in software services and applications not seen since the advent of the World-Wide Web. Because smart phones are just emerging, many standards are in flux, creating a unique opportunity to influence a system that will be used by billions. Similarly, as networks are upgraded and replaced, there is an opportunity to create a network that is open to more competition and continued innovation.

Our thesis is that the handheld computing revolution is not just a matter of squeezing the PC functionality into the cell phone but requires a re-think of the computing infrastructure from the servers in the cloud, to our desktop, the individual devices, and the network that interconnects them. Also, as handhelds get smarter we will rely on them more; but because they are small and easily lost, our data and computation will move into the cloud.

Despite progress in this direction, we see real structural barriers to openness that cause us concern: (1) loss of data privacy to major web companies, (2) barrier of entry for new web services, (3) inaccessible wireless capacity, and (4) a closed network infrastructure. Industry has too much vested interest to break down these barriers, and we believe a university team is ideally placed to tackle them through technical innovation. Our expedition aims to promote innovation and competition by breaking down these barriers to create a truly programmable and open mobile internet.

Intellectual Merit. This research will develop our vision of a new three-tier system architecture called Shoka, where (1) users carry their digital identities and caches on the handhelds, (2) uses the handheld to customize generic PCs so they can run their personalized environment, and (3) have all the data, and possibly computations, backed up in the cloud. As we move, our mobile devices will connect to any of the abundant wireless networks around us, regardless of their owners.

We address the barriers described above by creating (1) a virtual data system called PRPL that enables users to take back ownership of their data, (2) the Shoka three-tier computation infrastructure to ease the entry of new web services, (3) the open network to promote network innovation and make wireless capacity available across heterogeneous and abundant radio networks in a vicinity, and (4) open-source software to promote existing efforts in opening the cell phone.

Each of these topics involves careful design and experimentation. Specific technologies we will develop include encryption-based access control; prevention of data leakage via information flow control; a three-tier computation architecture with support for a “network of VMs” and mobile VMs to enable new services in the cloud, a secured and extensible browser for handhelds; rapid multi-modal UI prototyping system; an OpenFlow network architecture with a set of services for mobility management, security, network management, AAA, and more importantly a platform that enables innovative services, higher speed radio access networks; and mobile wireless infrastructure and content for K-12 schools, especially for under-served communities.

As a demonstration of our research, our team will deploy a prototype system of infrastructure, devices and applications – at scale – across the Stanford campus. We believe it will be the most comprehensive, experimental deployment of mobile technology ever performed by a university.

Broader Impact. Our expedition has the potential for enormous impact by shaping the next revolution in computing and communication enabled by mobile devices, networks, and services. By helping to open and secure devices, the development environment and the network infrastructure, we will help the way society uses technology. The field is of great importance to society as a whole, and it is critical that the research community helps get this right. Our team will collaborate with cellular providers, providers of wireless technology and equipment, and application creators.

We will have impact by applying mobile wireless devices and applications for education in under-served communities. We will perform fundamental research in experimental systems, educate and train a new generation of researchers and leaders, and transfer technology openly, through publication, entrepreneurship, and industrial partnerships so as to help transform the society, continuing the tradition at Stanford.

2


1 IntroductionWe have an exciting opportunity to shape two revolutions in computing and communication:

A computer revolution. The PC revolution brought affordable computing to millions of users. In the next generation, Internet-enabled handhelds will bring significant computing power to billions. At our fingertips we will have access to data and services that run locally, or remotely in the cloud. With increased capacity of flash memory, we will store more and more personal data, and carry it with us all the time.

A communication revolution. The cellular industry brought telephony and low-bandwidth Internet access to billions, but on proprietary networks and handhelds. The mobile network is changing: New radio technologies promise orders of magnitude more bandwidth; closed-walls are breaking down, paving the way for innovative new applications; and proprietary cellular networks are being replaced by IP.

Low-cost open handheld computing platforms, with ubiquitous high-bandwidth connectivity, create an opportunity for innovation in software services and applications not seen since the advent of the World-Wide Web. Because smart phones are just emerging, many standards are in flux, creating a unique opportunity to influence a system that will be used by billions. Similarly, as networks are upgraded and replaced, there is an opportunity to create a network that is open to more competition and continued innovation.

Research Overview. Our thesis is that the handheld computing revolution is not just a matter of squeezing the PC functionality into the cell phone, but requires a re-think of the computing infrastructure from the servers in the cloud, to our desktop, the individual devices, and the network that interconnects them. We need innovation in the server infrastructure, so as to offload computation into the cloud. To this end we propose a three-tier architecture called Shoka1 that places the mobile device at the top of a caching hierarchy backed up by desktops, and ultimately servers in the cloud. We will carry our digital identities on our mobile devices, which will unlock all the digital and even physical assets we have access to. When we access a PC or set-top box, we will personalize the machine using our digital personality on our mobile device, so as to take advantage of the large-screen display, full-size keyboard, and the graphics card of the PC. Data and computation will be cached on our mobile devices and desktop machines with the ultimate version stored in the cloud. We will easily reinstate the personal state on our mobile device, when necessary, by plugging a new device into the cloud. As we move, our mobile devices will connect to any of the abundant wireless networks around us, regardless of their owners. Service providers will exist as a service in the cloud, quite separate from the physical network. The physical network will be based on OpenFlow to allow future innovation, while being simple, and backwardly compatible with IP.

The Shoka architecture represents a significant paradigm shift from today’s PC-centric computing infrastructure to having all the data and computing services reside primarily in the cloud. We are concerned that incremental evolutions led by large corporations may not be in the best interest of the end users. We thus propose an expedition to:

1. Provide an open, programmable, and secure environment that fosters innovation and competition. We have identified four major barriers—loss of data privacy to major web companies, barrier of entry for new web services, inaccessible wireless capacity, and a closed network infrastructure.

2. Break down these barriers by creating a foundation to support innovation and competition, making it easy for businesses to roll out new services and letting end users decide how they wish to keep their data and what services to use. Four major parts to our expedition will be:The PRPL Virtual Data System: Allowing users to take back ownership of their data.The Shoka Computation Infrastructure: Easing the entry of new web services.The Open Network: Promoting network innovation; and making all wireless capacity available.Open-source software for handhelds: To improve and promote existing efforts in openness.

This is a timely expedition—it is important to establish a sound foundation at the infancy of a new computing generation, as evidenced by the effect of the PC standardization on the Windows and Intel platform over 20 years ago.

1 Shoka is a form of ikebana (Japanese flower arrangement). Three parts symbolize heaven, earth, and person, corresponding to the servers in the cloud, stationary machines, and personal mobile devices.

3


Team. To deliver such a far-reaching vision of openness takes a broad team with deep expertise who will redesign significant parts of the computing and network infrastructure. Thus, this expedition brings together, for the first time, a Stanford team with expertise in wireless technology (Arogyaswami Paulraj, Andrea Goldsmith), network architecture (Guru Parulkar, Nick McKeown, Fouad Tobagi), operating systems and development environments (Monica Lam, Mendel Rosenblum, David Mazières, Phil Levis, Christos Kozyrakis), computer and network security (Dan Boneh, John Mitchell), economics (Ramesh Johari), and the use of mobile technology in education (Paul Kim). As members of the same institution, we can work closely together to experiment with new fundamental concepts that span the network, individual devices, and large-scale distributed systems.

Experimentation and Outreach. Our team will collaborate with cellular providers, providers of wireless technology and equipment, and application creators. As a demonstration of our research, our team will deploy a prototype system of infrastructure, devices and applications – at scale – across the Stanford campus. We believe it will be the most comprehensive, experimental deployment of mobile technology ever performed by a university. In this expedition, we will:

1. Build and deploy a prototype campus-wide network, providing users with handhelds running our new software infrastructure, over a new network with a variety of radio technologies (Section 8).

2. Demonstrate – through an outreach program – how mobile handhelds and applications can be used for the education and entertainment of disadvantaged populations (Section Error: Reference sourcenot found).

3. Collaborate closely with industrial leaders in the mobile Internet space so as to stay ahead of their research and development, and provide paths for technology transfer.

Technical Contributions. This expedition can have far-reaching effects on the next revolution of computer and networking services. For example, we may see the emergence of a new network paradigm and a new class of distributed services that operate on large amounts of user data without owning the data. The expedition will contribute to standards in the short term such as security measures in web browsers as well as security and energy management techniques in open operating systems like Android. From the experience of preparing for the proposal itself, we are confident that the unprecedented level of cross-domain collaborative effort proposed in this expedition will ignite many new directions of research.

2 Research Rationale and OverviewOpenness and Choice. There is currently much excitement in the air about openness in wireless and mobile computing. Users can choose from a thriving array of handsets, and in many countries can use their handset with a variety of commercial carriers. A burgeoning army of third-party developers are creating applications, games and content for mobile devices. And the Android operating system claims to be the “first truly open and comprehensive platform for mobile devices … all of the software to run a mobile phone, but without the proprietary obstacles that have hindered mobile innovation”. [Andy Rubin/Google]

Arguably these are all positive steps towards a more open ecosystem for the mobile world, creating more choice for users. The mobile industry is healthy, with cellular telephony a world-wide phenomenon. Cellular network owners are investing heavily in spectrum and technology, handset manufacturers are innovating fast, and there is a plethora of applications and content for handheld devices.

We applaud the move towards openness, and are great believers in the power of choice in the marketplace to bring innovation, efficiency and high quality service to the user. Industry benefits too. An innovative marketplace grows the business for everyone, and attracts new players eager to compete with incumbents. Complacent and slow-moving incumbents risk being brushed aside, but agile companies – large and small – will build

4

There is plenty of precedent that openness benefits users. For decades, telephony was closed to competition; US vendors couldn’t even sell telephones to AT&T’s customers. Telephony opened in stages; customer equipment, then long distance, international service, network equipment, local service, and now VoIP service over DSL and CATV networks. As barriers fell, openness allowed users to pick from an array of equipment and service. Hundreds of “virtual” service providers (who own no network infrastructure of their own) vie for our business. Openness led to innovation, quality improved, prices came down, and industry is profitable.


on their domain experience to bring new products to market, and will find new ways to package their services. Openness creates choice which breeds innovation.

Despite all the progress, there are still real structural barriers to openness – barriers that industry and government will not break down on their own – requiring technical innovation. This is the domain of university researchers. In the spirit of enabling choice and innovation through openness, our expedition sets out to break down these technical barriers, including:

1. The concentration of our data into the hands of a small number of owners . Increasingly, we must place our data – in the clear – on the servers of private companies. If we want to share our photos with friends (Flickr, Picasa, Shutterfly), take part in social networking (Facebook, Myspace), or prepare collaborative documents we must place our data in the service provider’s hands, allowing them to mine our data, risk it getting into the wrong hands, and have little choice on the applications we can run on our data. We are forced to give up privacy and control of our data in order to use it. We believe that we should be free to own and control our data – our photos, medical and financial records, and personal information. We should be able to choose and control who can access it, and we should be free and open to run a wide variety of applications on our data without compromise.

2. A high barrier to entry for innovative services. Rapid proliferation of new Internet-wide services – spawned by the likes of YouTube, Facebook and eBay – can lead us to believe that large-scale services can be deployed easily and grow fast. Yet in each case it took huge resources, and tens of millions of dollars, to migrate an idea from the edge to the global cloud of computing, storage and networking. Today, only a small number of companies own massive infrastructure, yet they are closed to third parties who want to innovate. While there are some signs of change (e.g. Amazon’s EC2), we anticipate most infrastructures to be owned and controlled by a small number of companies. Our goal is to enable innovators to take a small idea and deploy it as a business at-scale, without the need to use proprietary and closed infrastructures. With exciting new opportunities brought by the mobile revolution, we aim to remove the high barriers for new applications, such as location-aware social networks, customized e-commerce, and new services yet to be imagined.

3. The inaccessible and closed wireless capacity around us. Today, if we stand in the middle of a city, we can likely “see” multiple cellular and WiFi networks. But, frustratingly, these infrastructures are not available for us to use. Cellular companies restrict us to use their network; most private WiFi networks require authentication, and are effectively inaccessible to us. Although we are often surrounded by abundant wireless capacity, almost all is off-limits; our choice is almost non-existent. This isn’t good for us, and it isn’t good for network owners: Their network might have lots of spare capacity, even though a paying customer is close-by. We believe users should be free to travel in a rich field of wireless networks with access to all infrastructure around them. Openness doesn’t mean free – here it means a healthy market-place with lower-cost connectivity and broader coverage. In the extreme, if all barriers to fluidity can be removed, users could connect to multiple networks at the same time, opening up enormous capacity and coverage.

4. A network infrastructure that is closed to innovation. Cellular networks increasingly use IP. IP has been tremendously successful in bringing choice and innovation to the end user: Arguably its greatest feat is enabling innovation at the edges. IP is simple, standardized, and provides universal connectivity. But we believe that as-is, IP is not the right choice for the future mobile Internet: It is ill-suited to support mobility and security; and it is hard to manage. Its architecture is fixed, allowing little room to add new capabilities. Today we feel the pain from a . lack of support for mobility and security. If we tweak IP to solve these problems, we will find new limitations. We need a network that allows continued innovation, for services we can't yet imagine, while allowing existing applications to work unchanged.

2.1 Expected Technical ContributionsThe PRPL virtual data infrastructure. To give users control over their data, we propose to develop a virtual data system where users own their data, decide who they share the data with at fine granularity, where they store the data, where they access their data, and which applications they run. We are proposing a new PRPL (PRivate-PubLic) protocol that abstracts away the location of the data and allows the owner of

5


the data to exert active access control. Information in this system is semantically indexed and is cached locally. Just as HTTP enabled an explosion of web content, PRPL will make possible a new class of services that combines large amounts of data integrated from various sources while preserving privacy.

Encryption-based access control. The PRPL data infrastructure relies on fine-grain access controls. Our design is to keep all user credentials on our personal mobile device. We will develop techniques needed to unlock both digital and physical assets with such a device. We will develop encryption and other techniques to provide fine-grain sharing while ensuring that the techniques are easy to use. Prevention of data leakage via information flow control. PRPL, as the keeper of our confidential information, will be the target of security attacks. We plan to develop information flow control techniques as a means to guard against user, design, and programming errors.

The Shoka virtual computation infrastructure. To empower small companies to roll out services at a small scale and ramp up, we intend to build a distributed compute utility that users can rent as they go. Computation will be performed at a location oblivious to the user, on the handheld, locally on the desktop, on an anonymous server in the cloud. We envision that a handheld will automatically leverage nearby computational resources to ensure a decent response time. This infrastructure will facilitate many more “long-tail” niche applications with a relatively small user base.

The Open Network. We will create a network that is open to innovation and the addition of new features; in particular, we will demonstrate how a production network can support multiple routing protocols and mobility managers simultaneously. We will enable multiple virtual service providers – running on the Shoka computation infrastructure – to co-exist and provide user choice. We will show how VMs can move, giving more choice of where computation resides.

Openflow. To enable networks that support mobility as a first-class feature, that are more secure and easier to manage, we will build, deploy and use a new flow-based network, called OpenFlow. OpenFlow will enable users, owners and service providers to deploy innovative new services directly into the network, allowing it to continue to evolve and improve. Wireless. We will give users open access to all wireless infrastructure, we will create and demonstrate new ways for handhelds to rapidly and seamlessly select and connect to the best available network, in a way that is independent of the underlying radio technology. Radio Technologies. New fast radio technologies will mitigate interference and better understand the wireless channel, making possible data rates over 1Gb/s and near 100% coverage. We will create and experiment with new fast radio technologies operating at over 2Gb/s.

Open-source Software for Handhelds. We will contribute to existing programs in openness, to provide a more secure OS kernel, energy management technques, secure browser technology, and user interfaces.

Secure web browser. As many web sites are redesigned to display properly on mobile devices, we have the opportunity to influence the design of web browsers to eliminate common vulnerabilities such as cross-site attacks. We have identified several promising approaches to greatly improve browser security, including new security models and tools for testing browsers, fault confinement mechanisms, isolation through application-specific browsers, and new user interfaces to indicate the level of security. We expect to continue to influence commercial browsers; our ideas have been adopted in widely used web browsers like Firefox and Safari, sometimes even before they were published. User experience. We plan to develop a multimodal interface that combines speech and graphical interaction to enhance a user’s experience on the handheld. We will explore how we can use the semantic information available in the PRPL virtual data infrastructure to generate user interfaces specific to the display constraints and user preferences easily and perhaps even automatically. Towards our goal of creating infrastructures to aid in experimentation, we will create a web-hosting framework that will enable designers to rapidly deploy alternatives of a mobile web application and gather comparative usability metrics.Energy efficiency. We will build energy-aware applications and OS, and explore user interfaces that empower people to make effective energy-aware decisions.

6


3 The PRPL Virtual Data InfrastructureHTTP (Hypertext Transfer Protocol) and HTML (Hypertext Markup Language) have brought about

one of the biggest changes in the history of computing by allowing anybody to publish unstructured content on all kinds of devices. With the limited display, cache size, and computing power of the mobile device, however, this unstructured hypertext is an inadequate mechanism for communicating between and portraying data on mobile devices and servers. Instead of storing our private data on handhelds and browsing through many pages of web pages for answers, we need the cloud to compute across all our data and to find the answers we need. We see a dangerous trend of giving up ownership and privacy of our data to "big-brother" portals. Portals have full access to our data and control the applications we run, squeezing out competition vital to innovation.

In this expedition, we will develop a data transport protocol, called PRPL (Private-PubLic), to support communication between mobile devices and servers in the cloud, and for servers to communicate with each other. PRPL will allow data owners to finely control with whom they share data, where they store the data, and what applications to run. By asserting structured facts about PRPL resources using RDF [RDF] and OWL [OWL], PRPL will let developers easily create applications that operate on and make sense of large amounts of distributed data. The structure of the data is explicit, allowing display-limited devices to trim back extra content without losing key information. Caching is built into the protocol so users and applications will enjoy the location-independence abstraction, online and offline, without penalty, Adoption of PRPL will enable many intelligent services, without compromising the confidentiality of data. The effect could be as profound as the revolutionary impact of hypertext on publishing.

What is PRPL? PRPL is a protocol where the owner of the data can exert active control, at fine granularity, over how their data can be accessed. Access can be revoked, assuming a third party has not already gotten a copy of the data. PRPL is independent of the location of the storage: data can be stored anywhere: on a local file server, a generic storage server like Amazon S3, or a Facebook web page. PRPL enforces read-only sharing so that only the owner can change their data.

Instead of files in a file system hierarchy, data is stored in a semantic web [Semantic]. For example, personal contact information will be stored as relations linking the identity to its email address or phone number. Owners can decide which part of the information is exposed to whom. Owners can set up policies that describe how the information is to be shared across groups and individuals. For example, we can set up a group, consisting of members from different institutions, to share work-in-progress documents as easily as sending a message to the group.

As with HTTP servers and browsers, PRPL has a server and a client component. A PRPL server keeps the semantic index and controls access to the data it owns. It supplies clients with the portion of the index they are entitled to and locations where data is stored. PRPL clients interact with servers to get the latest index information, which may include public information as well. The client aggregates the information and supplies users with a unified view of their data sources. It also keeps a cache of the data so that users can access lots of data quickly, even if the network is down.

There has been significant prior work on distributed data storage systems such as NFS [Sandberg]. AFS [Howard], Coda [Kistler], SFS [Mazieres], SUNDR [Li], the Google File System [Ghemawat], Google's BigTable [Chang], Yahoo’s Hadoop [Hadoop], and SFSRO [Fu]. None of these existing systems can provide the fine-grained, controlled sharing of data we need.

3.1 Intelligent Services Without Loss of Data ConfidentialityBy abstracting data retrieval and access control, PRPL makes it easy to create an application that operates on a diverse source of information with controlled exposure of private data. Such an application may run on a PC operating on private data, or on a generic server in the cloud permitted access to relevant data only for the duration, with the data stored encrypted at a third-party site. An example application that would benefit from PRPL is a medical advice program that processes a family’s medical records to recommend medical checkups, diets, exercise regimens, and life insurance purchase strategies. The alternative would be for each family to keep an up-to-date and unencrypted copy of their data at an application service provider, which is cumbersome and undesirable for privacy reasons. Furthermore, if we carry the key to

7


our medical records on our handhelds, we can easily release our medical history to a hospital by producing the handheld and offering a second factor of identification, such as a password or biometric input.

Storing our data in a private semantic web, combined with location information from our mobile devices, enables intelligent services without compromising privacy. For example, when we visit a store, our personal client, based on personal information like friends’ birthdays and our purchasing history, can automatically prioritize the display of the store’s inventory. Similarly, as we sit down to watch TV, our device may suggest programs to watch based on our calendar information and past viewing records. Businesses and customers will benefit from more efficient sale transactions, without requiring businesses to build customer profiles and customers having to give up their privacy.

3.2 Controlling Access to DataWe envision the mobile device as the key-store holding all user credentials. In effect, it represents the user’s identity enabling the user to access data, make payments, and open physical locks. Such a system must provide several core capabilities such as: Revocation in case of loss or theft: the mobile device will be required to periodically communicate

with an online Validation Authority to refresh its credentials. When a device is revoked it can no longer obtain fresh credentials and will effectively stop functioning. This process is transparent to the user.

Credential delegation to colleagues or family members: we plan to leverage our earlier work on the RT trust management language [Li-Mitchell] to specify delegation rights.

Alternate access means when the mobile device is unavailable (e.g. out of power): we will rely on an (optional) online key recovery facility to emulate the mobile device on any computer.

Most importantly, ease of use for the general public. We will engage in extensive user studies to ensure that our mechanism and user interface are easily accessible.

While industry is moving in the direction of using cell phones to hold user credentials, none of the proposals support all the pieces above in a usable device. This project can help guide industry towards identity management on mobile devices that is both flexible and user friendly.

Another challenge comes from the fact that we plan to store data on cheap 3 rd party storage systems such as Amazon S3. To ensure that the system is easy to deploy we prefer to separate the storage system from access control decisions. We plan to use a combination of access control at the storage perimeter and encryption-based access control: Indexing data (such as text and image tags) will be stored in the clear and access to it will be controlled at the storage perimeter. Object data (such as images and sensitive documents) will be stored encrypted. To avoid complex key management we plan to leverage recent work on “Attribute Based Encryption” where data is encrypted under an “access policy” rather than under a key. The idea is that only users who possess credentials satisfying the access policy can decrypt the data.

3.3 Privacy and Convenience TradeoffsThe struggle between privacy and convenience is one we are already facing today. For example, companies would like to have the convenience of using Gmail, but they also worry about privacy. This struggle becomes even more significant with the mobile computing generation because of the dependence on the cloud. Since it is not possible, except for very limited cases, to perform computation on encrypted data, our approach is to provide choice to the end users and make each of the choices as easy as possible.

The PRPL server needs to have access to all the data in order to create the meta-data contained in the semantic web index. We minimize the exposure of private data by allowing the user to control the access to portions of the semantic web information. The bulk of the data can be stored encrypted anywhere. Applications can be given time leases on the data that they can access.

We plan to study how to create and support three kinds of servers: Private Servers. For ultimate privacy, households and companies will have their own PRPL servers.

For example, an Internet service provider may provide with the network access point a PRPL server appliance. The server indexes all data private to the household or to the institution and controls access to its data. It will provide online access of the data as well as allowing all the computers in the household or institution fast access over a LAN. Only an encrypted version of the meta-data is backed up with the service provider for redundancy. The challenge here is how to keep these private servers updated and protected from security attacks.

8


Public Portals. Our model can also encompass the current model where public servers own our data. Our PRPL client can retrieve and integrate data residing at those sites into one unified data view.

Third-party Servers. There will be many mobile device owners who will not have their own private servers. They may wish to keep their data at a third-party storage vendor and protect the privacy of their data with a service license agreement. We will study how to create a scalable PRPL data service, leveraging the Shoka infrastructure described in Section 4.

3.4 Information Flow Control to Prevent Data LeakageAs the keeper of our digital identity and confidential information, the PRPL server and client are likely to come under security attacks, using the history of web servers and clients as a guide. We plan to study ways to guard against both design and coding errors as we develop these systems. We also have to guard against user errors to avoid accidental leakage of data such as those caused by auto-completion of mail recipients in email clients.

We will investigate using information flow control as a means to address both user and programming errors. The basic idea is to control the flow of data throughout the system systematically within a process with the help of a compiler and the run-time system [Lam, Myers], across processes with OS primitives [Vandebogart, Zeldovich], and across machines with network communication primitives [Zeldovich-2].

3.5 Experimentation and AdoptionBesides the security and privacy issues described above, there are many more challenging questions to answer. What does it take for users to adopt this model? Ease of use, deployment, and migration from existing systems are all issues that prevented distributed file system research results from reaching the main stream. The PRPL design, being location independent, allows us to incorporate existing data sources into the system. We will make data in the PRPL system accessible to legacy software by exporting a standard file interface. We will explore data mining techniques to automatically suggest group formations and access control policies. We will also study how we use the higher-level semantic information available to improve user experience. For example, locations of our appointments on our calendar should automatically be used as hints for route destinations in a GPS application.

Our research methodology is to start with prototypes, gain experience with it, and refine. We will use the development of the PRPL server and client themselves as a study of how to build scalable services. We will build applications in parallel to exercise the infrastructure, and develop methodologies and frameworks to simplify application development. For example, we have already created a prototype that allows us to unify our data residing in our local file system, email attachments and Facebook web pages; we can choose our applications such as viewing the data with a rich interactive graphical interface on our local machine and posting the data on Facebook without having to give up ownership of our data.

As an example of a more challenging application, we plan to build an image web using the PRPL infrastructure. Our thesis is that capturing images of what we see regularly with a cell phone can create scaffolding to anchor real, normal photos that we take explicitly. By having enough “overlaps” between images, we can create links between images, which, like page ranks for web searches, can provide a breakthrough for the tough image classification problem. This application is challenging as it shares large volumes of potentially confidential information. It can take advantage of the tiered Shoka architecture to offload computations to servers in the cloud. This also stretches mobility support in networking, because it is a mobile application that generates a massive amount of data as the user moves from place to place.

4 The Shoka Computation InfrastructureOur goals for the computation infrastructure in the context of the Shoka three-tier architecture include (1) to safely execute code on and across the three tiers of the Shoka architecture and allow dynamic and seamless movement of the code from one tier to another; (2) to lower the barrier for innovative small and large scale services especially ones taking advantage of computing, storage, and networking resources within the cloud; and (3) to allow easy and efficient mobility of computation in response to the mobility of the handheld.We plan to build on the concept of virtual machines (VMs) as a basic container of computation. We will develop an abstraction of a network of VMs where individual VMs may run in any of the three tiers of the

9


architecture, and where VMs may move from one server to another dynamically. The network of VMs can be as small as two VMs representing the traditional client and server ends of an application or a large collection of VMs spread over the Internet to support a service like Flickr, Facebook, or a virtual world simulation with millions of concurrent users.

4.1 Computation Across Three Tiers. In the NSF-funded Collective project at Stanford, we created an approximation of the Shoka architecture, where managed virtual machine images migrate between the cloud, the desktop and portable storage [Chandra]. We can launch our personalized virtual machines on a generic PC by plugging in a USB flash drive. With this model, users can work on borrowed computers while leaving nothing personal behind and taking nothing away. Since the USB drive is used just as a cache, a user can replace a lost drive easily by re-populating a new drive with his state in the cloud.

We will build on the ideas of the Collective project and extend them to Shoka with support for three tiers including mobile handhelds. We will explore the use of lighter weight VMs, such as using a hypervisor [Barham], on mobile handhelds. In our envisioned architecture, all downloaded software will be run inside virtual machines to ensure that the basic functions of the cell phones will not be compromised. Recovery from crashes or attacks can be achieved through configuration management and rollback. We will develop an attestation protocol to establish trust between the devices, leveraging our previous work on the Terra system [Garfinkel].4.2 Lowering Barrier to Innovative Services: Small and Large Most existing Internet services (Flickr, Facebook, web search) use distributed computing, storage, and networking resources within the cloud to serve users around the globe. The proliferation of handhelds means cloud-based services will become common. At the same time, a few companies (Google, Microsoft, Yahoo!) own the cloud infrastructure (computing and storage) and it is closed to third parties for deploying new services. We envision a cloud infrastructure that is open and can enable deployment of new services, small and large.

Our proposed computing infrastructure will support “a network of VMs” as a new abstraction, allowing a service creator to specify a network of VMs. A VM in a network of VMs can run on the handheld, PC/set-top box, or a server within the cloud. A VM, for example, running on a server has its own computing, storage, and networking resources allocated to it. A service creator would specify resource requirements for each VM and can add or delete VMs and increase or decrease resources bound to individual VMs. VMs are plumbed together by an OpenFlow network. We will demonstrate how a computing infrastructure that supports this abstraction can reduce barriers to deploying new services.

A network of VMs should grow and shrink on demand. We plan to study how we can create a generic server network facility so that a business can pay as they grow, without having to build their own infrastructure. We will investigate how we can write a program and have it automatically run efficiently in all the three tiers of the Shoka architecture.

Experimental facilities such as PlanetLab and GENI share some of the goals and are building similar capabilities [Peterson, GENI]. However, in PlanetLab an experimenter programs individual VMs, rather than a network. We need an API to support a network of VMs; we believe this high-level abstraction will simplify deploying new services/applications, as the socket layer in Unix did for client-server applications. 4.3 Supporting Mobile Computing with Mobile VMsWith the move from static HTML web pages to richer APIs such as AJAX and Flash, web applications are doing more computation on the client machine to offer a richer and more interactive interface to the user. These better interfaces have set a high bar of service for the coming mobile Internet platforms. Given the inherent challenges of limited power consumption and device size, achieving these rich interfaces is going to be challenging for mobile devices and the people that program them.

We plan to leverage resources in the cloud and virtualization to address the challenge of programming this next generation of mobile web applications. We plan to explore a programming platform that allows for the simple construction of web services for mobile devices and supports rich user interfaces.

The key idea is to use the capabilities of the new network infrastructure and the ubiquitous virtualization layer to construct a system that supports web services that dynamically provision virtual

10


machines in close proximity to the mobile devices using the service. Using virtual machine replication, web services constructed on the platform will be able to assume that the VMs containing the first tier of the service be pushed to the edge of the network and run on the networking infrastructure close by the mobile device at all time. Virtual machine migration will be used to maintain this locality relationship as the device moves. We believe this capability will result in applications that have both a desirable user interface yet can be implemented in the constraints of a mobile device.

Our research program will contain two components. The first is the design and implementation of the platform for provisioning and migrating VMs to maintain close contact with mobile devices. This will build on our previous work on the vMatrix [Awadallah] and integrate with the networking infrastructure built on OpenFlow. We plan to explore both the mechanisms and the policies that maintain the VMs connected to the mobile devices.

A second research thrust explores the construction of partitioned mobile web applications. We will research mobile program toolkits that allow automatic construction of web applications with “helper” VMs that are automatically managed by the platform. For example, images captured from the mobile device’s video camera can be sent to a helper VM for image identification for an augmented reality application.

5 Open-Source Software for HandheldsWe have identified three areas in software for handhelds where research can potentially make a big difference: the operating system, the browser, and user interfaces in general.

5.1 Open-Source Operating SystemsWith Google backing the Android operating system for mobile phones, open-source Linux-based operating systems might dominate handhelds. We plan to contribute to this effort in the following ways.

Virtualization. As discussed in Section 4.1, we will explore using virtualization in operating systems so as to isolate software errors to ensure, for example, the proper functioning of the phone.

Information flow control. We have shown in the HiStar[Zeldovich] and DStar[Zeldovich-2] projects that information flow control can greatly improve the security of operating systems and networked computing. We plan to develop these ideas further, as discussed in Section 3.5, and investigate how to incorporate our results in the Android OS. We will also explore if information flow control can be used to help control and regulate energy consumption as well.

Energy conservation through feedback. Inspired by how energy feedback on a Prius has been shown to improve fuel efficiency by 10%, we will study how to add user feedback on the phone to help users conserve energy on the handhelds.

Energy saving by offloading computation. With the support of the Shoka architecture model, we will explore when and how to offload computation to servers to reduce energy consumption.

5.2 Secure web browsersMobile web browsers are in flux and many web sites will need to be redesigned to display properly on mobile devices. We have a unique opportunity to redesign the web browser to eliminate common web vulnerabilities such as cross-site attacks, session swapping, and many others. While our work is motivated by mobile browsers, our results will apply equally well to desktop browsers.

To date, our team has been very successful at identifying weaknesses in existing browsers [Jackson, Jackson-2, Ross, Jackson-3] and proposing solutions. Many of our proposed mitigations have now shipped in main stream browsers such as Firefox, Safari, and Internet Explorer. However, over the past few years it has become clear that small updates to the browser can only take us so far. A more thorough redesign of the browser is needed to achieve a fundamentally safer browsing experience for end users. In the course of this expedition we intend to explore a number of basic browser architecture issues described below.Models and tools for testing browser security. Currently when new features are added to the browser it is difficult to test whether they break existing security assumptions in the browser. For example, browsers blocked DNS rebinding attacks [DFW’96] via a mechanism called pinning. This defense became totally ineffective due to recent browser features [Jackson]. We intend to develop a browser security model as well as fuzzing tools that will be used to automatically test the security of existing browser features as well

11


as new features being proposed. These tools will help protect vendors from introducing new vulnerabilities or re-introducing old ones. Drive by downloads. Web sites hosting malicious code are one of the top threats facing the Internet today. We plan to experiment with confinement mechanisms that ensure that a browser bug does not result in an OS-level compromise. The challenge is to integrate confinement into the browser without affecting the user experience. Confining third party plug-ins. Third party plug-ins such as Flash player have complete control over the browser and are often the cause of web vulnerabilities [Jackson-2]. We intend to experiment with confinement architectures that limit the power of third party plug-ins in the browser. The goal is to enable plug-ins to fully control a rectangle on the screen without affecting other parts of the browser page.Security indicators on mobile browsers. Current mobile browsers eliminate many of the security indicators available on the desktop. Even the address bar is truncated due to screen size constraints. As a result, mobile users have a harder time determining what page they are viewing and whether the connection is over SSL. As part of our work we intend to experiment with user interfaces that present security indicators on a small screen. Security researchers will collaborate with HCI members of the team to carry out user experiments together to evaluate the various options. Application specific browsers. We plan to experiment with an architecture where a dedicated browser is used for sensitive operations such as home banking. The idea is that an attack on the general-purpose browser will not affect the dedicated banking browser. Currently, security conscious users manually implement this policy for themselves. Our application-specific browser architecture will enable all users to seamlessly do the same. The challenge is to design a system that has negligible impact on the user experience while protecting the dedicated browser.

We plan to continue improving existing web browser security by contributing code to open-source browsers (primarily Firefox and WebKit, a KDE-based platform on which Safari is built). Security code developed in our lab is shipping in Firefox 3 and Safari 3.1.

5.3 User experienceWhat user interfaces are most effective on mobile devices? On the desktop, industry has largely settled on the graphical user interface—in part because of the effectiveness of direct manipulation, and in part because the GUI’s significant momentum makes change difficult. Interaction paradigms for handhelds are emerging, but no particular approach has become hegemonic. Now is the time for clean-slate design thinking and empirical work. In particular, we seek to understand the relative merits of speech, graphical, and multimodal interaction in several scenarios. We propose to combine speech and graphical interaction, and hypothesize that this multimodal interface will outperform a speech-only or graphical-only interface. (Cohen et al. 1998 supports this hypothesis.) Handhelds intrinsically limit the physical real estate available for input and output. (State-of-the-art mobile input systems, e.g. Zhai’s Shapewriter, report 40-50wpm input by trained experts; roughly half the input speed of an expert with a desktop keyboard. Human-to-human speech proceeds at 120wpm; contemporary dictation systems provide 60 wpm.)

We will conduct a series of experiments to ascertain when and how different modalities can be effectively utilized. Drawing on prior research and our own intuitions, we hypothesize that:

Spoken language will be most effective when users have their hands and eyes busy; e.g., driving, surgery. And that spoken language output will – with few exceptions – only be preferable to graphical output when users’ eyes are busy because pixels are generally a more efficient display representation.

The recognition-over-recall benefits of direct manipulation (the user can see all of the available op-tions) mean that graphical interfaces will have a gentler learning curve.

Recognition errors are the “Achilles Heel” of voice interfaces: spoken input will be compelling when there are few recognition errors, and the user experience degrades rapidly as errors increase.

The modality tradeoff is content-dependent, as is their synergistic use. Graphical interaction will be preferable for content that benefits from deixis (pointing) or a spatial representation: maps, diagrams, calendars, etc. Spoken language will be preferable for specifying items from an (in-grammar) set.

12


What software architectures and tools can enable designers and developers to rapidly create and evaluate these alternative mobile interfaces? The web-based, software-as-a-service model enables developers to monitor usage and release new versions more quickly than was previously possible [Hartman, Hartman2, Hartman3, Yeh]. This flexibility has enabled technology companies to try out variants with real users, compare their performance, and make an informed design decision. The value of rapid enlightenment is particularly salient in the mobile domain, where effective interaction idioms are still emerging and device capabilities are changing rapidly. At a high level, our hypothesis is that crisp framework separation the presentation (interface) and data (application logic) portions of the application will enable the rapid creation — perhaps even the automatic creation (building on Gajos & Weld) — of multiple user interface alternatives.

6 The Open NetworkAs we look to the future, we want a network that will allow any handheld to connect to any network, and to move freely and seamlessly from one network to another. On the surface, it seems we are heading in this direction already: In most countries handheld devices are no longer “locked” to one cellular network, and there are several cellular networks to choose from. But today, we are surrounded by abundant wireless capacity we can’t use. Most available network infrastructure is off-limits: Cellular network operators lock us into their network (through a contract), and most private WiFi networks require authentication. The logical next step is for a handheld to connect to any network around it – regardless of who owns the network. While there are obvious economic barriers that stand in our way, we believe a new network architecture is needed to break down these barriers.Plenty of radios. In our vision, intelligent and autonomous mobile devices will hunt the vicinity to find the best radio networks, and connect to them seamlessly, without changing IP address or losing connectivity. Mobile devices will be armed with multiple radios. Whereas today’s phones commonly have three or four radios (e.g. GSM, GPRS, WiFi, Bluetooth), in future they will have more. Shrinking geometries and energy-efficient circuit design will lead to mobile devices with ten or more radios; a mobile device will talk to multiple APs at the same time for improved capacity, coverage and seamless handover. Plenty of service providers. If users are to move freely among many networks, the service provider needs to be separate from the network owner. Service providers should handle the mobility, authentication and billing for their users, regardless of the network they are connected to. To a limited extent, this is happening: Some cellular companies allow MVNOs2 to provide service over their network. And in WiFi networks, when we login to a hotel or airport network a third party provides authentication and billing services. But the service provider does not control mobility across physical networks; mobility and handoff is embedded in each network, is tied to the physical network, and is closed. Cellular companies keep their network closed, making it hard to move seamlessly from one network to another. And there isn’t an easy way for WiFi owners to make their infrastructure available to other users. Plenty of networks. We want to make possible a world with many APs and wired networks owned by many stakeholders: private homes, cities, network providers, cellular providers, employers, coffee shops, libraries, etc. Service providers will be virtual and might not own any network. They will provide us with billing and mobility services no matter where we are, and will compensate the network owners.

In summary, we believe in lots of service providers, lots of radios, and lots of types of radios, all tied together by lots of wired networks. We assume that there will be diversity at all levels: diversity in space (many networks to choose from), channels (more spectrum will become available), antennas (more MIMO), radios (a handheld will contain many radios), APs (a handheld may connect to several APs at once, for diversity and increased signal quality). With more radios, we assume always make-before-break continued connectivity, so that streaming applications will operate seamlessly as we walk, drive, or fly.

2 MVNO: Mobile Virtual Network Operator. In the US, Virgin is an MVNO in Sprint’s network; Sprint owns the radios and wired network, and Virgin provides branded AAA and billing services for its customers. In some countries, notably Holland, hundreds of MVNOs compete over a small number of physical networks.

13


6.1 A New Network ArchitectureTrying to remove mobility from the network illustrates a problem with the current IP network: Routing is considered part of the network, and is embedded in the routers along the datapath. Mobility management is about routing, which has made it hard to shoe-horn variants of Mobile IP [Perkins, Cheshire] into an architecture that was not designed to support mobility, and does not readily accommodate change. Despite the goals of the “end-to-end principle”3, routing does not have to be part of the network – source routing is a trivial example of an end-host choosing the route. This seemingly simple observation4 underlies our proposed new network architecture, called OpenFlow [McKeown,OF]. We believe that OpenFlow can help prevent the cellular industry from falling into the same trap as the wired Internet – today, unfortunately, cellular networks bundle more and more complexity into the network for AAA, billing and mobility.

OpenFlow has the following two main characteristics:1. A “dumb” datapath that is a generalization of IP, but is fully backwardly compatible. No end host or

application needs to change. 2. Routing, management, access control (and almost all network features) run in software as

“applications” in the Shoka computation layer. OpenFlow will enable rapid innovation, openness, and lots of choice. For example, two users on the same network might use different routing protocols, or might connect to different service providers who run different mobility managers.

OpenFlow in a nutshell. An OpenFlow switch is just a flow-table with multiple network interfaces (e.g. Ethernet or WiFi), and a standard open protocol to add entries to (or delete them from) the flow-table. If an arriving packet matches an entry in the flow-table, an action is performed on the packet. The matching is designed to be flexible: The flow-entry could specify the IP address (in which case the switch can operate like a router), the MAC address (to operate like an Ethernet switch), or any other packet header fields. In many cases it will specify the application flow (e.g. the IP addresses and TCP port numbers) so each flow can be processed differently by the switch. An OpenFlow Type 0 switch performs only three basic actions on matching packets: (1) Drop the packet, (2) Forward to one or more ports, (3) Encapsulate and forward over a secure channel to the OpenFlow Controller. The Controller is a software application that runs anywhere. Typically, a default entry in the flow-table forwards all non-matching packets to the Controller.Our proposed network. Our proposed network consists of wired networks built entirely from OpenFlow switches (we explain how we will accomplish this in Section 6.3). Radios are connected as leaves to the OpenFlow network – just like the WiFi link layer in an IP network. The radios are as “dumb” as possible – while they can be interrogated and controlled by the handset or the Controller (e.g. to read or set power levels in the radio), they have no intelligence and make no decisions of their own. All of the intelligence resides in the Controllers. The Controllers are logically centralized in a given network, although they will certainly be physically replicated for load-balancing and robustness. Controllers will communicate with peer Controllers in other networks.A mobile network service provider is just an application. In an OpenFlow Type 0 network, the only resources are flow-table entries, and they are owned by the network owner (e.g. a cellular network provider, an Internet service provider, or a home user). The network owner runs a Controller with privileged access to control the flow entries in all its switches. When a handheld starts communicating with a radio, the flow is detected by the Controller and is connected to its service provider (selected by the handheld/user). The service provider (SP) – a software application – authenticates the user, and adds flow-table entries to route the user’s flow. The SP might “own” blocks of flow entries in the flow-tables of different networks (e.g. by renting space, essentially a virtualizing the flow tables); or the SP could rent them on-demand – it is up to the SP and the network owner. The SP can now control the routing (and hence mobility), authentication, and billing. Different SPs can use different methods and algorithms, breeding innovation. Of course, a network owner can also be an SP by vertically integrating.

3 “Only place functionality in the network if it cannot be done at the edges.”4 It is illustrative to think about electricity distribution networks: the power distribution network owner runs

software to control the “datapath” so as to make energy flow from a set of producers to a set of consumers – not the transformers or their vendors. Likewise in the network, we believe that the network operator, the service provider and end user should decide how data is routed; not the box vendor.

14


Why not simply tweak IP? IP has been a tremendously successful in bringing choice and innovation to the end user. But IP is fixed and allows no room for evolution or addition of new capabilities (it is 15 years since IPv6 was proposed). Today we feel the pain from its lack of support for mobility, security and manageability. If we tweak IP to solve these problems, we will find new limitations. OpenFlow prepares the network for continued innovation, to overcome limitations and support services we can't yet imagine. The opportunity. There is an incredibly exciting opportunity before us. Cellular network operators are the biggest investors in network equipment today. They moved to IP because it lowered equipment costs, and new client applications prospered. The cellular network operators are well-placed to define the next generation Internet, and to enable our vision. An outcome of our research will be to define the new network, then work with the cellular providers to make it happen through their investment in new infrastructure. We will work with owners of WiFi networks (schools, colleges, homes, cities....) as they invest in new infrastructure too.

Our technical approach is in two phases: 1. We will deploy an OpenFlow network on Stanford campus, designed to enable innovation in mobility,

security, manageability and continued evolution (MSM&E). We will build it to be representative of our vision: It will have multiple radio technologies (WiFi and WiMax to start with; others later), connected by an OpenFlow network that is backwardly compatible with IP. The network will allow students and researchers to experiment with new mobility mechanisms, new security models, and new ways to manage networks – all in our campus network, with IP and non-IP traffic, alongside our production traffic. We will place mobile devices in the hands of our students. We will create the platform; and then we will stand back and watch our creative researchers.

2. We will create our own experiments in mobility, security, manageability and evolution. We describe examples of our experiments in the next section.

3. We will make OpenFlow available to as many researchers as possible, by helping them deploy OpenFlow in their networks too. We will create reference systems, work with equipment vendors to support OpenFlow, and create network “kits” for widespread deployment.

6.2 Experiments in our OpenFlow networkThe basics. The basic mechanism for mobility management in an OpenFlow network is very simple. The Controller creates all routes. When a handset decides to connect to one or more new APs, it tells the Controller, which re-routes the flow. The IP address stays the same and so connectivity is maintained.The details. Of course mobility is more complicated in practice [HIP, Zhuang], and there are many questions to answer. When a user moves, we need to maintain the authenticated session between the user, the network and the SP; and make sure the handover process is fast and simple. Our preliminary studies suggest the problem is quite manageable, with a lot of design choices. While cellular networks take the stance that mobility and directory management is complicated and difficult, and has to be decentralized, we take the opposite stance. The amount of information is well within the processing capabilities to handle it centrally, and each year Moore’s Law makes it easier still. This leaves room for many different innovative solutions to compete – centralized or not. For example, consider the problem of how frequently a user hands-off from one AP to the next. The handoff lasts from when the handheld device first decides to connect to a new AP until the flow has been re-routed, and must complete before the next handoff starts. This is determined by how fast the user is moving, the size of a cell, the number of APs that are visible, and the network round-trip time from the leaves to the common root of the two networks the device is moving between (which dictates the time to re-route the flow). Preliminary analysis suggests the Controller needs to handoff at most once every 100ms for a network the size of North America; enough time to execute several hundred million instructions on a PC. Our initial estimate is surprising – we believe a single Controller based on a $200 PC could manage mobility for over one million users. A small set of Controllers running in Shoka could manage mobility for the entire country. This is not to say that it should be done this way – only that it is feasible; we can choose how to partition mobility management. We will experiment with mobility managers that emulate the behavior of re-routing, and maintain a continuously authenticated connection. We will use and deploy a variety of mobility managers in our network.

15


We also need to ask what happens if cell sizes get smaller – and there is good reason to think they will. Handoff will happen more often, perhaps much more so. What design choices do we have if, say, a handoff must complete in 50ms or 10ms? Do we now need to distribute the mechanism to the edges of the network?

How can multiple Controllers exist at the same time, representing different owners of the network? Can we virtualize the OpenFlow switches, giving each SP the impression of their own private, isolated flow-table for use by their customers? How do two Controllers interoperate to handoff between them? How scalable are the Controllers? Is there a natural aggregation of flows to make OpenFlow scale further? Mobile computation too. We think of OpenFlow as a flexible “plumbing” layer that allows us to route and re-route flows at will between entities in the network. We can extend this to help plumb Virtual Machines (VMs) together, allowing them to move. In this case, a Controller can contain a VM mobility manager to help VMs move without having to worry about network state or changing IP addresses.

6.3 How we will deploy our OpenFlow networkWe are laying the groundwork to deploy an OpenFlow network on Stanford campus. We are working with several switch vendors to add OpenFlow as a “research” feature of their switches; most notably HP and Cisco, the two biggest makers of Ethernet switches for US college campuses. We will deploy OpenFlow in two buildings to connect over 1,000 users. Our goal is to deploy a network representative of an enterprise or set of small network owners in five buildings across campus.

We will create OpenFlow WiFi APs in the OpenWRT embedded Linux environment, running on commercial APs, and deploy them liberally on campus. We will identify and program WiMAX APs to support OpenFlow and deploy them; we already have a small WiMAX network in our School of Education.

We will experiment with OpenFlow Controller software built by researchers, and with open-source NOX software [Gude]. As OpenFlow gains momentum, we expect more Controllers to be available from the research community.

6.4 Economic QuestionsCreating a network capable of supporting continued innovation raises interesting business and economic questions. Economists describe an open system as one that provides maximum choice and innovation in user experience, while maintaining investment incentives and profitability for players in the chain of delivering that experience (infrastructure, device, service, and applications).

Our network architecture raises a number of interesting questions that we will address in our research.Thesis 1: Competition increases available choice. While diversity of choice can increase competition, will it be a positive feedback loop? Can we show that our vision of users choosing among a rich choice of networks provides sufficient incentive for investment in infrastructure?Thesis 2: For high fixed cost infrastructure, thesis 1 may be flawed. The high fixed costs of deploying networks can prevent us from deploying them; hence commercial deployments are frequently closed. However, if high fixed costs are overcome and the resulting infrastructure is open, competition can thrive on top of the infrastructure.

This leads to a question about business choices. One choice is to try and control everything: services, apps, device, and network infrastructure. Most cellular companies picked this path by integrating vertically and locking in the user. Another choice is for separate ecosystems to thrive at different layers. We believe the choice is determined exactly by the present discounted value of future innovation. In a future where extensive innovation is forecast, the benefits of openness are huge.

On the economic front, our research will draw on the extensive economic literature on market design [Mas-Colell, Chapter 23] and contract theory [Bolton]. We will couple these economic models with two different lines of work: first, recent progress in modeling wireless networks via scaling laws [Ozgur,Ozgur2] and alternative channel models [Tse]; and second, classical models for the diffusion of innovations in technology [Bass,Lilien].

6.5 Fast Radio Access NetworkOur vision assumes continued innovation in radio technology, and a marketplace where many types of radio co-exist. By 2020 we can expect dramatic improvements in radio access networks. The ITU has defined goals for IMT-Advanced radio network to be fielded in the 2010-12 timeframe [3G-forum]. These

16


are 1Gbps indoors and 100Mbps outdoors, coverage or areal reliability of 99% and round trip delays of < 5ms. We should expect a 2020 radio network to be at least a factor of ten better than IMT-Advanced goals.

A number of technologies will be needed to meet these ambitious targets: higher spectrum efficiency, flexible spectrum sharing and improved link diversity/reliability. Promising techniques under development include cross-layer design, multiple antennas, cognitive radio, multi-user coding and opportunistic scheduling. These improvements have already entered 4G technologies such as WIMAX and 3GPP-LTE, but significant refinement and scaling of these techniques are still needed.

Even more exciting are clean slate ideas for radio networks, where dramatic departures in architecture are proposed. We focus on two key areas: The first is in fighting interference. Cellular networks are increasingly interference limited, rather than noise limited, and interference mitigation can yield dramatic improvements. Our approaches include variable/flexible reuse, power control, multi-cell coding, interference-aware opportunistic scheduling, and interference cancellation at the receiver and transmitter [Paulraj, Vu]. In all cases, better theoretical understanding and practical solutions are needed. The second area is to improve transmit channel knowledge (Tx-CSI). It is well known that Tx-CSI can reduce receiver complexity, improve spectrum efficiency, and improve link reliability, yet networks before 3G paid no attention to Tx-CSI. However, new network architecture can improve Tx-CSI and buy major improvements.

In summary, a number of techniques promise big improvements in the radio network. Our research plan will focus on clean slate ideas that we believe have the greatest potential for 2020. We will monitor and integrate near-term ideas from research programs worldwide, and focus our research on longer term goals. We plan to aim for peak rates of 10 Gbps, spectrum efficiency of 20 bits/Hz/cell, areal reliability of 99.9% and round trip delays <1ms. Our work will be focused at systems level to broadly define the radio access network that can deliver these performance goals, rather than develop detailed algorithmic or coding techniques. Further we will develop an abstraction model of the radio access network so that it can serve as a base for simulating the overall performance at the network and application layers. We also expect that cross layer issues will come to the fore – not just top down, but also bottom up. For example, the cells may have to become much smaller (say 300M) to support our performance goals which will mean much higher handoff rates, and this may require specific responses at the security and network layers.

Related work. There has been enormous activity to improve wireless PHY [3G-forum]. The best distillation of ideas to-date is in the WiMax (16e) and 3GPP LTE standard. A lot of work underpinning these advances was done in academia, the WINNER program in Europe and Japan’s Super 3G program [Biglieri, Paulraj2]. Work on the next generation has started, e.g. WIMAX–16m and 3GPP LTE+ [Wimax].

7 Concluding RemarksWe believe there is a huge opportunity to shape the future of mobile computing, by rethinking the software and network infrastructure so as to maximize openness, innovation, and choice. There are many parts to be rethought: A data infrastructure that allows us to protect and control our personal data, giving us choice on where we store it, and the applications that can access it; a computation infrastructure that allows our applications to move freely between our handheld and the cloud; and a network that provides choice among service providers, gives us access to any available wireless capacity, and is able to continuously evolve.

Our goal is to open up a new frontier in mobile computer systems, and to have impact in each area. We will bring the many parts together through coordinated experiments and demonstrations on our campus. To this end, we have assembled a broad-based team with expertise in each part, and a track record of having big impact on technologies and infrastructure.

A successful expedition will have a significant impact on the mobile Internet, and ultimately benefit society. To have impact requires the transfer of technology and ideas. We will work closely with our industrial partners to build and transfer expertise, and bring mobile computing into our undergraduate and graduate curriculum. We will work to bring our technology to the under-privileged through applications targeted for educational use in under-served communities.

17


References

[3G-forum] 3G Forum. Defining 4G White Paper. http://3gamericas.com/PDFs/3G_Americas_Defining_4G_WP_July2007.pdf

[Anderson] Anderson, E., Kelly, F., and Steinberg, R., “A contract and balancing mechanism for sharing capacity in a communication network,” Management Science 52 (2006).

[Attewell] Attewell, J., “Mobile technologies and learning: A technology update and m-learning project summary,” Technology enhanced learning research centre. Retrieved March 20, 2007, from http://www.lsda.org.uk/files/pdf/041923RS.pdf

[Awadallah] Awadallah, A. and Rosenblum, M., “The Matrix: A Network of Virtual Machine Monitors for Dynamic Content Distribution”, 7th International Workshop on Web Content Caching Distribution (WCW 2002), Boulder, Colorado, August 2002

[Barham] Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Neugebar, R., Pratt, I. and Warfield, A., “Xen and the Art of Virtualization”, In the Proceedings of the ACM Symposium on Operating Systems Principles (SOSP), October 2003.

[Bass] Bass, F. A New Product Growth Model for Consumer Durables. Management Science, 15 , 215-227, 1969.

[Biglieri] Biglieri, E., Constantinides, A., Calderbank, R., Goldsmith, A., Paulraj A., and Poor. V., “Introduction to MIMO Wireless,” Cambridge Univ. Press, Nov. 2006.

[Bolton] Bolton, P., and Dewatripont, M. (2005). Contract theory. MIT Press.

[Boneh] Boneh, D., Daswani, D., "Experimenting with electronic commerce on the PalmPilot", Proceedings of Financial Cryptography '99, LNCS 1648, 1999.

[Casado] Casado, M., Freedman, M.J., Pettit, J., Luo, J., McKeown, N., Shenker, S., “Ethane: Taking Control of the Enterprise,” ACM SIGCOMM, 2007.

[Casado2] Casado, M., Garfinkel, T., Akella, A., Freedman, M., Boneh, D., McKeown, N., Shenker, S., "SANE: A Protection Architecture for Enterprise Networks" 15th Usenix Security Symposium, Vancouver, Canada, August 2006.

[Chandra] Chandra, R., Zeldovich, N., Sapuntzakis, C., Lam, M.S., “The Collective: A Cache-Based System Management Architecture.” In Proceedings of the 2nd Symposium on Networked Systems Design and Implementation (NSDI), 2005.

[Chang] Chang, F., Dean, J., Ghemawat, S., Hsieh, W.C., Wallach, D.A., Burrows, M., Chandra, T., Fikes, A., Gruber, R.E., “Bigtable: A Distributed Storage System for Structured Data.'' In Proceedings of the 7th Symposium on Operating Systems Design and Implementation (OSDI), 2006.

[Cheshire] Cheshire, S., and Baker, M., “Internet Mobility 4x4,” in Proceedings of SIGCOMM, 1996.

18

http://www.lsda.org.uk/files/pdf/041923RS.pdf

http://3gamericas.com/PDFs/3G_Americas_Defining_4G_WP_July2007.pdf


[Cohen] Cohen, P., Johnston, M., McGee, D., Oviatt, S., Pittman, J., Smith I., Chen L., and Clow, J., "QuickSet: multimodal interaction for distributed applications," MULTIMEDIA '97: Proceedings of the fifth ACM international conference on Multimedia, 1997.

[Cui] Cui, S., Goldsmith, A., “Cross-layer Design in Energy-constrained Networks Using Cooperative MIMO Techniques,” EURASIP Journal on Applied Signal Processing, Special Issue on Advances in Signal Processing-based Cross-layer Designs. August 2006. pp. 1804-1814.

[Cox] Cox, R., Hansen, J., Gribble, S., Levy, H., “A Safety-Oriented Platform for Web Applications,” Proceedings of the 2006 IEEE Symposium on Security and Privacy (S&P'06).

[FCC] FCC07: http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-07-132A1.pdf

[Ford] Ford, B., Strauss, J., Lesniewski-Laas, C., Rhea, S., Kaashoek, F., Morris. R., “Persistent Personal Names for Globally Connected Mobile Devices,'' In Proceedings of the 7th Symposium on Operating Systems Design and Implementation (OSDI), 2006.

[FIND] FIND: Future Internet Design, NSF Program, http://www.nets-find.net/.

[Fu] Fu, K., Kaashoek, F., Mazieres, D., “Fast and secure distributed read-only file system,” In ACM Transactions on Computer Systems, 20(1):1-24, February 2002.

[Gajos] Gajos, K., and Weld, D., “SUPPLE: automatically generating user interfaces,” In IUI '04: Proceedings of the 9th international conference on Intelligent user interfaces, 2004.

[Garfinkel] Garfinkel, T., Pfaff, B., Chow, J., Rosenblum, M., Boneh, D., “Terra: A virtual machine-based platform for trusted computing,” In Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP 2003).

[GENI] GENI: Global Environment for Networking Innovations, http://www.geni.net/.

[Ghemawat] Ghemawat, S., Gobioff, H., Leung, S., “The Google File System, ” In Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP), 2003.

[Greenberg] Greenberg, A., Hjalmtysson, G., Maltz, D., Myers, A., Rexford, J., Xie, G., Yan, H., Zhan, J., and Zhang, H., “A clean slate 4D approach to network control and management.” In SIGCOMM Computer Comm. Rev., Oct. 2005.

[Glibb] Gibb, G., Lockwood, J., Naous, J., Hartke, P., and McKeown, N., “NetFPGA -- Open Platform for Teaching How to Build Gigabit-rate Network Switches and Routers", To appear: IEEE Transactions on Education, 2008.

[Gude] Natasha Gude, Teemu Koponen, Justin Pettit, Ben Pfaff, Martin Casadao, Nick McKeown, Scott Shenker, “NOX: Towards an Operating System for Networks,” In submission. Also: http://nicira.com/docs/nox-nodis.pdf.

[Hadoop] Hadoop: Apache open source project. Available at http://hadoop.apache.org/ [Hartman] Hartmann, B., Abdulla, L., Mittal, M., and Klemmer, S., "Authoring sensor-based interactions by demonstration with direct manipulation and pattern recognition," CHI '07: Proceedings of the ACM SIGCHI conference on Human factors in computing systems, 2007.

19

http://hadoop.apache.org/

http://nicira.com/docs/nox-nodis.pdf

http://www.nets-find.net/

http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-07-132A1.pdf


[Hartman2] Hartmann, B., Klemmer, S., Bernstein, M., Abdulla, L., Burr, B., Robinson-Mosher, A., and Gee, J., "Reflective physical prototyping through integrated design, test, and analysis," UIST '06: Proceedings of the 19th annual ACM symposium on User interface software and technology, 2006.

[Hartman3] Hartman, B., Wu L., Collins, K., and Klemmer, S. "Programming by a sample: rapidly creating web applications with d.mix," UIST '07: Proceedings of the 20th annual ACM symposium on User interface software and technology, 2007.

[HIP]“Host Identity Protocol,” http://www.openhip.org/irtf/wiki/index.php?title=Main_Page.

[Howard] Howard, J. H., Kazar, M. L., Menees, S. G., Nichols, D. A., Satyanarayanan, M., Sidebotham, R. N., West, M. J., "Scale and performance in a distributed file system." ACM Transactions on Computer Systems, 6(1), February 1988.

[Hristea] Hristea, C., Tobagi F., "A network infrastructure for IP mobility support in metropolitan areas", Computer Networks 38 (2002).

[Jackson] Jackson, C., Barth, A., Bortz, A., Shao, W., Boneh, D., "Protecting Browsers from DNS Rebinding Attacks," Proceedings of the 14th ACM conference on Computer and Communications Security (CCS), 2007.

[Jackson-2] Jackson, C., Bortz, A., Boneh, D., Mitchell, J., "Protecting Browser State from Web Privacy Attacks," Proceedings of the 15th International Conference on World Wide Web, WWW '06, ACM Press.

[Jackson-3] Jackson, C., Simon, D., Tan, D., Barth, A., "An Evaluation of Extended Validation and Picture-in-Picture Phishing Attacks," In Proceedings of Usable Security (USEC '07) 2007.

[Jackson-4] Jackson, C., Wang, H., "Subspace: Secure Cross-Domain Communication for Web Mashups" In Proceedings of the 16th International Conference on World Wide Web (WWW) 2007.

[Kim] Kim, P., Miranda, T., Olaciregui, C. “Pocket school: Exploring mobile technology as a sustainable literacy education option for under-served children in Latin America,” International Journal of Educational Development. doi:10.1016/j.ijedudev.2007.

[Kistler] Kistler, J.J., Satyanarayanan, M., ``Disconnected Operation in the Coda File System.'' In ACM Transactions on Computer Systems, 10(1):3-25, February 1992.

[Klues] Klues, K., Handziski, V., Lu, C., Wolisz, A., Culler, D., Gay, D., Levis, P., “Integrating concurrency control and energy management in device drivers,” In Proceedings of the ACM Symposium on Operating Systems Principles (SOSP) 2007.

[Kristensson] Kristensson, P., and Zhai, S., "SHARK2: a large vocabulary shorthand writing system for pen-based computers," UIST '04: Proceedings of the 17th annual ACM symposium on User interface software and technology, 2004.

[Lam] Lam, M. S., Martin, M. C., Livshits, V. B., Whaley J., “Securing Web Applications Using Static and Dynamic Information Flow Tracking,” In ACM Sigplan 2008 Workshop on Partial Evaluation and Program Manipulation, (Keynote address), January 2008.

20

http://mmnetworks.stanford.edu/papers/hristea_compnet02.pdf

http://www.openhip.org/irtf/wiki/index.php?title=Main_Page


[Li] Li, J., Krohn, M.N., Mazières, D., Shasha, D., “Secure Untrusted Data Repository (SUNDR).'' In Proceedings of the 6th Symposium on Operating Systems Design and Implementation (OSDI), 2004.

[Li-Mitchell] N. Li and J.C. Mitchell, RT: A Role-based Trust-management Framework, DARPA Information Survivability Conference and Exposition (DISCEX III), April, 2003.

[Lilien] Lilien, G., Kotler, P., and Moorthy, K.S. (1992). Marketing models. Prentice-Hall.

[Lockwood] Lockwood, J.W., McKeown, N., Watson, G., Glibb, G., Hartke, P., Naous, J., Raghuraman, R., Luo, J., “NetFPGA - An Open Platform for Gigabit-rate Network Switching and Routing,” IEEE International Conference on Microelectronic Systems Education, 2007.

[Mas-Colell] Mas-Colell, A., Whinston, M.D., and Green, J.R. (1995). Microeconomic theory. Oxford University Press.

[Mazieres] Mazières, D., Kaminsky, M., Kaashoek, F., Witchel, E., “Separating key management from file system security.'' In Proceedings of the ACM Symposium on Operating Systems Principles (SOSP), 1999.

[McKeown] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S., Turner, J., “OpenFlow: Enabling Innovation in College Networks,” to appear in ACM CCR, April 2008

[Myers] Myers, A. C., Liskov, B., ``Protecting privacy using the decentralized label model.'' In ACM Transactions on Computer Systems, 9(4):410-442, October 2000.

[OF] OpenFlow Switch Specification. Available at: http://OpenFlowSwitch.org

[Ozgur] Ozgur, A., Leveque, O., and Tse, D.N.C. Hierarchical Cooperation Achieves Optimal Capacity Scaling in Ad Hoc Networks. IEEE Transactions on Information Theory, vol 53, no. 10, pp. 3549 - 3572, October 2007.

[Ozgur2] Ozgur, A., Johari, R., Leveque, O., Tse, D.N.C. (2007). Information theoretic operating regimes of large wireless networks. Submitted.

[OWL] OWL Web Ontology Language Overview. Available at http://www.w3.org/TR/owl-features.[Perkins] Perkins, C.,“RFC 3220: IP Mobility Support for IPv4,” IETF, Jan 2002.

[Parno] Parno, B., Kuo, C., Perrig, A., "Phoolproof Phishing Prevention." In Proceedings of the 10th International Conference on Financial Cryptography and Data Security (FC'06), 2006.

[Paulraj] Paulraj, A., Gore, D., Nabar, R., Bolcskei, H., “An overview of MIMO communications - a key to gigabit wireless.” Proceedings of the IEEE, Volume: 92, Issue: 2, Feb 2004.

[Paulraj2] Paulraj, A., Nabar R., and Gore, D., “Introduction to Space-Time Wireless Communications,” Cambridge Univ. Press, May 2003. Reprinted Chinese Ed. 2004, Reprinted Russian Ed. 2007)

[Peterson] Peterson, L., Anderson, T., Culler, D., and Roscoe, T., “A Blueprint for Introducing Disruptive Technology into the Internet,” (HotNets-I ‘02), October 2002.

[Roschelle] Roschelle, J., “Unlocking the learning value of wireless mobile devices,” Journal of Computer Assisted Learning, 19, 260-272, 2003.

21

http://OpenFlowSwitch.org/


[Ross] Ross, B., et al, "Stronger Password Authentication Using Browser Extensions," In Proceedings of the 14th USENIX Security Symposium, 2005.

[RDF] Resource Description Framework (RDF). Available at http://www.w3.org/RDF.

[Sandberg] Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon B., "Design and Implementation of the Sun Network Filesystem", In Proceedings of the Summer 1985 USENIX Conference, 1985

[Semantic] W3C Semantic Web Activity. Available at http://www.w3.org/2001/sw.

[Tse] D. Tse. A Deterministic Model for Wireless Channels and its Applications. Information Theory Workshop, Lake Tahoe, Sept 2007.

[Vandebogart] Vandebogart, et al, ``Labels and event processes in the Asbestos operating system.'' In ACM Transactions on Computer Systems, 25(4):11, December 2007.

[Vu] Vu, M., Paulraj, A., “MIMO Wireless Linear Precoding,” Signal Proc Magazine, IEEE, Sept. 2007.

[Wang] Wang, H., Fan, X., Howell, J., Jackson, C., "MashupOS: Operating System Abstractions for Client Mashups," In Proceedings of the ACM Symposium on Operating Systems Principles (SOSP) 2007.

[Wimax] WIMAX and IMT 2000. White paper by WIMAX forum. http://www.wimaxforum.org/technology/downloads/WiMAX_and_IMT_2000.pdf, January 2007.

[Yeh] Yeh, R., Liao, C., Klemmer, S., Guimbretiere, F., Lee B., Kakaradov, B., Stamberger, J., and Paepcke, A., "ButterflyNet: a mobile capture and access system for field biology research," In CHI '06: Proceedings of the SIGCHI conference on Human Factors in computing systems, 2006.

[Zeldovich] Zeldovich, N., Boyd-Wickizer, S., Kohler, E., Mazieres, D., “Making information flow explicit in HiStar,'' In Proceedings of the 7th Symposium on Operating Systems Design and Implementation (OSDI) 2006.

[Zeldovich-2] Zeldovich, N., ``Securing Untrustworthy Software Using Information Flow Control.'' Ph.D. Thesis, Department of Computer Science, Stanford University, October 2007.

[Zhuang] Zhuang, S., Lai, K., Stoica, I., Katz, R., Shenker, S., "Host Mobility using an Internet Indirection Infrastructure," First International Conference on Mobile Systems, Applications, and Services (ACM/USENIX Mobisys), May, 2003.

22

http://www.wimaxforum.org/technology/downloads/WiMAX_and_IMT_2000.pdf

343-2008.doc

Documents

open network

mobile devices

mobile wireless devices

mobile wireless infrastructure

network innovation

mobile vms

new services

network management