CSAIL Research Abstracts - 2005 link to http://publications.csail.mit.edu/abstracts/abstracts05/index.html link to http://www.csail.mit.edu
bullet Introduction bullet Architecture, Systems
& Networks
bullet Language, Learning,
Vision & Graphics
bullet Physical, Biological
& Social Systems
bullet Theory bullet

horizontal line

Horde: Flexible Application Driven Network Striping

Asfandyar Qureshi & John Guttag

Introduction

Inverse multiplexing, or network striping, allows the construction of a high-bandwidth virtual channel from a collection of multiple low-bandwidth physical channels. Network striping takes data from the source virtual channel and sends it in some order over the smaller physical channels. Although a great deal of past research deals with network striping, many assumptions made by earlier researchers do not hold when striping over unstable and dissimilar network channels, such as cellular Wireless Wide Area Network (WWAN) channels. We have developed the Horde middleware [8] [9] to allow applications to stripe data over WWAN channels.

Horde is middleware that facilitates flexible striping over WWAN channels. Horde is unusual in that it separates the striping policy from the striping mechanism. It allows applications to describe network Quality-of-Service (QoS) objectives that the striping mechanism attempts to satisfy. Horde can be used by a set of data streams, each with its own QoS policy, to stripe data over a set of WWAN channels. The WWAN QoS variations observed across different channels and in time, provide opportunities to modulate stream QoS through packet scheduling.

The key technical challenge in Horde is giving applications control over certain aspects of the data striping operation while at the same time shielding the application from low-level details. Horde exports a set of flexible abstractions replacing the application's network stack. Horde allows applications to express their policy goals as succinct network-QoS objectives. Each objective says something, relatively simple, about the sort of network QoS an application would like for some data stream(s).

Motivation

Our overall research project aims to provide advanced remote diagnostic capabilities, using high-bandwidth video, for patients in an ambulance moving about in an urban area. When appropriate health professionals cannot be physically present to diagnose patients, telemedicine can be used to connect these professionals to those in need of their expertise. We focus on using telemedicine to improve outcomes when dealing with acute incidents involving critical care patients. By relaying real-time telemetry and video from ambulances, we hope to provide EMS teams with expert opinions on complex trauma injuries, and to aid the in-hospital teams in better preparing themselves for incoming patients. In many situations, the timely application of an appropriate therapy is of critical importance, and mobile telemedicine can help (e.g. stroke treatment [7]). From the moving ambulance, we want to transmit real-time uni-directional video, bi-directional audio, and multiple uni-directional physiological data streams (EKG, blood pressure, etc).

In order for the telemedicine system we design to be useful, the system must be economically viable to build, deploy and operate. We therefore leverage existing communications infrastructure, instead of using our own network infrastructure to handle the ambulance's requirements. We also build our system out of conventional off-the-shelf components.

WWAN Background

Our research leverages the widespread cellular wireless data networks. In most urban areas, a number of public carrier cellular WWANs provide mobile connectivity to the Internet, using standard cellular technologies such as GSM/GPRS and CDMA2000. Notably, these providers have overlapping coverage areas, allowing us to connect to more than one provider at the same time.

Unfortunately, individual WWAN channels have low bandwidths and provide little in the way of network QoS guarantees. Additionally, different WWAN channels can provide very different QoS. Network QoS is affected by the layout of a provider's base-stations relative to the WWAN interface, and by the WWAN technology, both of which vary across providers. Vehicular motion introduces additional complications, depending on the WWAN technology.

The available diversity in present-day WWAN environments makes network striping an especially appealing approach. By taking advantage of service provider diversity, overlapping coverage, and network technology diversity (e.g. GPRS and CDMA), one can attempt to provide each application with the illusion that a reliable stable high-bandwidth channel is available. The existence of technological and provider diversity---a benevolent side-effect of the competitive nature of the cellular provider market---is likely to bolster the virtual channel, making it more reliable. The underlying channels are more independent than if the same technology or the same provider were being used.

Approach

A great deal of work has been done on network striping [1] [2] [3] [4] [5] [6]. Most of this work is aimed at providing improved scheduling algorithms under the assumption that the underlying links are relatively stable and homogeneous. If this assumption holds, there is little reason to give applications control over how the striping is done, and allowing applications to be oblivious to the fact that striping is taking place is appropriate.

In our environment, however, the underlying links are neither stable nor homogeneous. Therefore, the manner in which the middleware decides to schedule the transmission of application packets can have a large influence on observed packet latencies, stream loss rates, and bandwidth. Furthermore, the application streams in our telemedicine system are heterogeneous with respect to which aspects of the network service they are sensitive: some applications care about average latency, some not; some care about loss more than others; and some care more about the variance of the latency than they do about the average latency.

In our WWAN environment the packet scheduler can modulate application observed QoS on a data stream and different applications can care about very different aspects of this QoS. This leads us to want to give applications some control over how striping is done.

Horde is most useful when dealing with:

    Bandwidth-Limited Applications: Situations in which applications would like to send more data than individual physical channels can support, justify both the network striping operation and the additional processing cost associated with Horde's QoS modulation framework.

    Sensitivity to Network QoS: If no application data streams are sensitive to network QoS, Horde's QoS modulation framework becomes redundant.

    Heterogeneous and Dynamically Varying Network Channels: With such channels, the striping packet scheduler has an opportunity to significantly modulate application observed QoS. Additionally, Horde's approach is most useful when the available network channels have characteristics that are predictable in the short term. Our experiments have shown that public carrier WWAN channels are of this nature.

    Heterogeneous Data Streams: When different streams gain value from different aspects of network performance, trade-offs can be made when allocating network resources among those streams. An example is an application in which some streams value low latency delivery and others value low loss rates.

Horde is not meant to be general networking middleware: as long as most application data can be sent down a single, stable link, using Horde is overkill. More generally, in situations where one is dealing with a fixed set of relatively homogeneous and stable channels, other techniques may be more appropriate.

Research Support

This research is supported by the National Library of Medicine, CIMIT, the Center for the Integration of Medicine and Innovative Technology, and Acer Inc., Delta Electronics Inc., HP Corp., NTT Inc., Nokia Research Center, and Philips Research under the MIT Project Oxygen Partnership.

References

[1] J. Duncanson, "Inverse Multiplexing." In IEEE Communications Magazine, April 1994.

[2] P. Fredette, "The Past, Present, and Future of Inverse Multiplexing." In IEEE Communications Magazine, April 1994.

[3] Hari Adiseshu, Guru M. Parulkar and George Varghese, "A Reliable and Scalable Striping Protocol." In the proceedings of SIGCOMM 1996.

[4] Alex Snoeren, "Adaptive Inverse Multiplexing for Wide-Area Wireless Networks." In the proceedings of IEEE conference on Global Communications 1999.

[5] Luiz Magalhaes and Robin Kravets, "Transport Level Mechanisms for Bandwidth Aggregation on Mobile Hosts." In the proceedings of ICNP 2001.

[6] Pablo Rodriguez, Rajiv Chakravorty, Julian Chesterfield, Ian Pratt and Suman Banerjee, "MAR: A Commuter Router Infrastructure for the Mobile Internet." In the proceedings of ACM MOBISYS 2004.

[7] M. P. LaMonte, Y. Xiao, P. Hu, D. Gagliano, M. N. Bahmouth, R. D. Gunawardane, C. F. Mackenzie, W. R. Gaasch and J. Cullen, "Shortening time to stroke treatment using ambulance telemedicine: TeleBAT." In the Journal of Stroke 2004.

[8] Asfandyar Qureshi and John Guttag, "Horde: Separating Network Striping Policy from Mechanism." In the proceedings of ACM MOBISYS 2005.

[9] Asfandyar Qureshi, "Flexible Application Driven Network Striping over Wireless Wide Area Networks." MEng Thesis, Massachusetts Institute of Technology, March 2005.

horizontal line

MIT logo Computer Science and Artificial Intelligence Laboratory (CSAIL)
The Stata Center, Building 32 - 32 Vassar Street - Cambridge, MA 02139 - USA
tel:+1-617-253-0073 - publications@csail.mit.edu
(Note: On July 1, 2003, the AI Lab and LCS merged to form CSAIL.)