From: NOSSDAV'97, St. Louis, Missouri, May 19-21, 1997, pp. 143-154.
Copyright 1997 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.
System Support for Mobile Multimedia Applications Jon Inouye
Shanwei Cen
Calton Pu
Jonathan Walpole
[email protected]
[email protected]
[email protected]
[email protected]
Department of Computer Science and Engineering Oregon Graduate Institute of Science and Technology P.O. Box 91000, Portland, Oregon 97006 http:://www.cse.ogi.edu/DISC/projects/quasar
hand-held devices and PDAs combined with the ready availability of network access via protocols such as SLIP and PPP, and the rapid proliferation of wireless networking technology is evidence of the trend toward increased mobility. The convergence of these two trends is signi cant for system designers because of the potentially con icting characteristics of streaming applications and mobile systems. Streaming multimedia applications have the following salient characteristics. They tend to be resource-hungry. That is, they care about CPU, network and perhaps disk bandwidth, are often ready to consume whatever bandwidth is available to them, and want to know when more becomes available. They are also connection-oriented, due to their long-term, streaming nature. For example, they usually require a long-term association between IP addresses of peers, clients and servers. As people become more dependent on streaming applications and mobile systems the need to run streaming applications over mobile systems arises. For example, a user may wish to continue a video conference via a docked laptop and Ethernet LAN back in his oce even though the conference was started in a conference room over a wireless LAN. System designers must anticipate the following kind of question from users { \Why must I shut down my streaming multimedia application every time I want to move my laptop?" This anticipated ubiquitous use of streaming applications in a mobile environment raises several dicult problems. First, mobility has the potential to introduce radical changes in available resource capacity. Available network bandwidth, for example, drops by several orders of magnitude when a docked laptop is disconnected from its Ethernet-based LAN and must continue operation via a PPP-based cellular modem con-
Abstract
The emergence of free streaming media players, coupled with the availability of powerful inexpensive laptop computers has created a domain for mobile multimedia applications. Mobile multimedia applications must deal with the inherent variability generated when migrating from oce to conference room, den to patio, or classroom to dorm room. This paper presents a multi-layered multimedia architecture utilizing adaptive layers and cross-layer noti cations. An implementation of that architecture is demonstrated using a streaming media player that communicates with a video server while switching from wired LAN to POTS to wireless LAN, transparently adapting to new network addresses and bandwidth uctuations. Mobility is supported by using device indications to force the adaptive feedback system into an \exploratory" mode and signal the application to re-establish the control and data channels.
1 Introduction
Recent years have witnessed two prominent trends that have serious implications for operating system and network design: the proliferation of streaming multimedia applications and the move toward increased system mobility. Examples of streaming multimedia applications are video conferencing systems such as White Pine's CUSeeMe R , Intel's ProShare R , LBL's vic/vat [6, 15], and streaming audio and video players such as those from VXtreme and Progressive Networks. The wide-spread use of laptop computers, This research was supported by the Advanced Research Projects Agency (ARPA) under grant N00014-94-1-0845 and contract MDA904-95-C-5547, Intel Corporation, and Tektronix, Inc. Jon Inouye was supported by an Intel Foundation Graduate Fellowship.
1
Necessary Ingredients
Level
Adaptation Policy
Presentation Specification
User
"What to scale?"
Scalable Content
Application
"How to scale?"
Software Feedback
Dynamic library
"How much to scale?"
Device Indications
Operating System
"When have we moved?"
Figure 1: Mobile Multimedia Architecture nection. Similarly, re-docking the machine results in a dramatic increase in available bandwidth. Resource hungry applications, such as streaming video players, need to know when such changes occur so that they can tailor their resource usage in a way that is appropriate to the application. For example, when bandwidth drops dramatically the decision of whether to drop frames, or reduce spatial resolution, or reduce color depth, etc., needs to involve the application, and perhaps even the user. The range of possible and appropriate approaches di ers among di erent applications and di erent users performing di erent tasks, and hence the decision can not be made unilaterally by the system. Noti cations of mobility-induced changes are not widely available on today's systems, neither are today's applications tailored to adapt to them. Second, streaming applications can not easily be converted to a transactional style of operation to cope with the path changes between peers that result from mobility. The continuous nature of streaming combined with potentially tight quality of service (QoS) requirements over the timing of data delivery strongly encourage a connection-oriented approach. Without a connection-oriented approach, how would systems maintain QoS requirements? In order to support mobility, however, such connection-oriented approaches must be adaptive. This paper presents a solution to the above problems that spans the operating system, network protocol, and application layers. The solution is based on the basic ideas of cross-layer noti cation and adaptation. We present an overview of our model for crosslayer adaptation, and describe an implementation based on a 4.4BSD operating system [16], TCP/IP network protocol stack, and the Quasar streaming
video player [8]. The paper is organized as follows. Section 2 outlines the architecture of our adaptive multimedia system. Section 3 describes the implementation of the streaming video player and the support added to the operating system. Section 4 evaluates the system by moving it between various heterogeneous networks. In Section 5 we compare the support we added to Unix with the existing support in Microsoft Windows. We describe other approaches in supporting mobile multimedia in Section 6 and summarize in Section 7.
2 Multimedia Architecture
Figure 1 outlines our approach for supporting mobile multimedia applications. Each layer adapts in a semantically meaningful manner using a methodology based on quasi-invariants, guards, and intelligent adaptation. Quasi-invariants are explicit assumptions made by a layer, about the environment in which it operates. For example, the IP address of a mobile client can be considered quasi-invariant; it usually doesn't change, but it might. Guards are used to detect invalidations of quasi-invariants. Due to the diculty of detecting invalidations within one layer, guards may be transferred across layer boundaries. Invalidations of these guards trigger cross-layer noti cations and invoke adaptation routines. No layer attempts to transparently hide all aspects of mobility from other layers. Each layer adapts in a manner best suited to it, and adaptation policies may be passed down from higher layers. This promotes intelligent adaptation, that is, adapting to a valid set of constraints. A xed adaptation policy may be inappropriate for all environments visited by a mobile host. 2
2.1 Presentation Speci cation
layers that mobility events have occurred and triggering mobility-related adaptation. The operating system must be able to recon gure devices and the network stack after detecting mobility events such as device changes, network migrations, and disconnection. We elaborate on these requirements in Section 3.2.
When resources are tight, con icts will exist. In addition to specifying \what I want", presentation speci cations also declare \what to scale" when adapting. Speci cations provide an application with user preferences, and hence provides a framework for intelligent adaptation. For example, a particular environment may support only 28.8 Kbps of network bandwidth to a video server, and the user may request that audio quality be preserved. In this case, the application could decrease the quality of the video to reduce the bandwidth requirements of the presentation to a suitable level. If the user had preferred spatial resolution over frame rate (for example, when video is used to display slides at a conference), the application could lower the frame rate rather than increase the amount of lossy compression. Our approach to providing a presentation QoS speci cation is fully described in [20].
3 Implementation
In this section, we described the implementation of the video player and enhancements made to the operating system.
3.1 Player Architecture
The prototype real-time distributed MPEG video player [8, 7] has a server/client architecture as shown in Figure 2. It consists of a video server and a client connected through a TCP/IP network. The client is further composed of a video decoder/renderer and a controller. A reliable TCP connection is used for control messages between the video server and the client controller, while a best-e ort SCP [7] connection is employed for streaming video frames and shipping feedback messages. All the MPEG video clips are stored in the video server. During a playback session, the server streams the frames of the requested video clips to the client in real time. The client receives and bu ers the frames, and decodes and display them also in real time. The video server, video network connection, and video decoder/renderer e ectively form a video pipeline, within which the video frames ow. Each stage, when overloaded, drops frames independently, either randomly or selectively based on its local knowledge of the current state of the video stream. The client stage also drops frames that are already late when they arrive. Through the GUI provided by the client controller, the user can initialize the video server with speci ed video clips, start or stop playback sessions, or specify their presentation preferences. Presentation speci cation. The user can express his preference on various aspects of the video quality. With the prototype video player, he can specify a maximum frame rate, and a trade-o between spatial resolution and frame rate. The latter is accomplished using high and low frame rate threshold values. When the display frame rate surpasses the high threshold, the client asks the server to send the next higher resolution stream. Similarly, if the rate drops below the lower threshold, the client asks for the next lower resolution stream. The player does not reserve resources to enforce guarantees on video quality. Instead, through the feedbacks for video quality and server/client synchronization, it accommodates the speci ed user preferences with the currently available resources in a best-e ort and adaptive manner.
2.2 Scalable Content
While users might understand frame rate and spatial resolution, the typical user might not understand \how to scale" a particular media type. Applications are best equipped to intelligently choose the scaling algorithms best suited to their media type. For example, for encoders using frame di erences, like MPEG, dropping a frame means all frames based on the dropped frame are unusable and should also be dropped. In this case, the quasi-invariant is the display frame rate appropriate for this session and the guard is registered in the feedback layer described below. Responsibility for scaling the media stream remains in this layer.
2.3 Software Feedback
While an application can scale its resource consumption, it does not know \how appropriate" the current resource usage is for the environment. Feedback informs the application when the data rate it is requesting is below or beyond the capabilities of the current environment. Note that feedback takes into account more than network bandwidth. It is truly end-to-end, allowing it to also adapt to uctuations in CPU load and disk trac. Our sample application uses software feedback to dynamically discover the appropriate data stream (e.g., frame rate) to use and detect when it becomes inappropriate [8].
2.4 Network and OS Support
Due to the adaptation support within the higher layers, our architecture does not require rate lters or new network protocols within the network stack and operating system. The operating system is responsible for detecting mobility events, recon guring itself, and supply higher layers with mobility indications. Indications are cross-layer noti cations informing interested 3
Feedback messages video decoder/renderer Video server
Internet
Video frames control messages
Controller
Mobility indications
Video client
User actions
Figure 2: Architecture of the prototype adaptive distributed video player Scalable content. The player supports video clips with multiple spatial resolutions. A source video clip may be compressed into multiple MPEG video les at di erent resolutions. These les are treated as components of a single video stream, referred to as multiresolution video stream. During a playback session of a multi-resolution video stream the player selects the appropriate resolution automatically and dynamically, based on the current resource availability and the user preference. Software feedback. The video player e ectively adapts to changes in the network and server/client hosts through the extensive use the toolkit-based software feedbacks [7]. SCP, the protocol used on the video data network connection, is an adaptive protocol for real-time streaming media data such as video and audio. Similar to TCP, SCP has a slow-start policy upon start-up to quickly nd out the available network bandwidth, and an exponential back-o policy when congestion is detected. However, SCP is very di erent from TCP in that it does not re-transmit lost packets and adopts a stable-state policy that ensures smooth streaming and stable bandwidth partitioning among multiple sessions. On top of SCP, the player employs two end-to-end feedbacks for the video pipeline: a QoS feedback and a server/client synchronization feedback. The QoS feedback continuously monitors the rate at which the client currently displays video frames (display frame rate) and decides accordingly the resolution and frame rate at which the server streams video. At the next-step, server streaming resolution and frame rate are determined by the available bandwidth of the bottleneck stage in the pipeline, which can either be the server (disk bandwidth or CPU speed), the network connection (bandwidth) or the client (CPU speed). The server/client synchronization feedback maintains the appropriate amount of time for the server to work ahead of the client, such that the client-side bu ering is minimized
with out under owing (no frames are late). The optimal server work-ahead time depends on the latency and latency variation of the pipeline stages, especially the network connection. Mobile awareness. The player uses mobility indications to trigger second-level feedback operations. Upon receipt of an indication during a playback session, the player re-establishes the control and data connections between the client and the server (in the case when its IP address changes) and continues the playback from where interrupted. It also resets all the feedback parameters, including SCP, and the QoS and synchronization feedbacks. Upon reseting, the feedbacks invoke slow-start policies to quickly determine the new network parameters such as bandwidth, latency and variation, and adapt the video quality to the new network environment. Without being reset upon network interface switch, it would take much longer for the feedback to converge. For example, upon switching from Ethernet to POTS, SCP would time-out and back-o exponentially, and many video frames would be late and dropped by the client due to PPP's long latency in transmitting big video frames. Similarly, upon switching from PPP to Ethernet, since SCP and the QoS feedback are in steady state, it would take long a long time before to fully explore the several orders magnitude larger network bandwidth.
3.2 Network and OS Support
Our system implements a device availability model and supports dynamic network recon guration. The system is implemented using FreeBSD 2.1R augmented by the April 1996 release of the PAO patch kit and Portland State University's non-IPSEC mobile IP release.1 Figure 3 illustrates the various components of our system. pmid implements a device availability model that supports Physical Media Independence
1 See http://www.jp.FreeBSD.org/PAO for more information on the PAO patches and http://www.cs.pdx.edu/research/SMN for information on PSU's mobile IP release.
4
application
pulse process uses heartbeats (ICMP echo requests and replies) to validate a NIC's IP address and LAN connectivity. In normal connected operation, heartbeats between the mobile host and an adjacent \anchor" host are used to validate link-layer connectivity. Once the number of consecutive missed beats passes a threshold (default of 2), the next heartbeat is sent to the all-hosts multicast group (224.0.0.1) and the rst valid reply becomes the new anchor host. If no valid replies are received from the multicast request, the Berkeley Packet Filter (BPF) [14] is employed to promiscuously listen for all ICMP echo replies. This allows the implementation to distinguish between linklevel disconnections (no response at all) and network migrations (responses with incorrect destination MAC addresses). If any response is detected, the network name associated with the device is invalidated. If no response is detected, the link-connectivity characteristic associated with the device is invalidated. In normal disconnected operation, BPF is used to send out requests since there should be no routes associated with that interface { routes are only attached to available interfaces. If a response is detected, pmid is informed so that it may initiate recon guration options, e.g., DHCP, to acquire a valid IP address for that interface. We only use heartbeats on LAN devices and depend on FreeBSD's user-level PPP driver (tun0) to release its route resources when the carrier signal is lost.
application indications
costd
pulse pmid
routedjr
pccardd
Route Table
/dev/pmi
PCIC driver /dev/card
Figure 3: Device Availability Support (PMI) [12]. Making network management on mobile laptops as easy as it is for stationary desktops is the goal of PMI. On startup, pmid examines each interface on the system and removes those interfaces that it knows are not associated with network devices, such as the loopback interface. For every LAN interface, pmid res up a pulse process to monitor the network directly connected to the interface. A route information gathering process helps discover possible routers and a cost monitoring process makes sure network connectivity does not exceed a user's monetary budget. We break down the required network and operating system functionality into four sections: hot swapping capability, network awareness, exible routing policy, and device availability indications. Monetary costs concerns are beyond the scope of this paper.
3.2.3 Routing Policy
Traditional local routing protocols such as RIP and OSPF use \distance" metrics to judge between comparable routes. These protocols were designed with an autonomous network in mind, and are not always appropriate when a mobile computer overlaps multiple autonomous domains. In particular, a rigid policy for selecting the default route is dangerous because of its in exibility. We allow the user to specify a default route selection policy that includes type of interface (Ethernet before WaveLAN before PPP) and network name (use 129.95.50.54 on network 129.95.50.0/24). The latter simply allows a con guration le to support multiple network personalities, depending on the location, rather than a single personality for all locations. We use routedjr, a modi ed version of the RIP routing daemon routed, to collect default route advertisements and pass them to pmid. Possible default route candidates are also marketed via ICMP router advertisements [10] and DHCP [11] servers but routedjr currently does not exploit these sources of information.
3.2.1 Hot Swapping
FreeBSD 2.1R supports hot swappable network interface cards with the addition of the PAO patches. These enhancements provide a driver for the PC card interrupt controller (PCIC) and pseudo-device driver (/dev/card). The pseudo-device acts as a communication mechanism between the PCIC and pccardd, the user-level daemon. The device allows the \tuples" associated with 16-bit cards to be mapped into memory and analyzed by the user-level daemon. We needed only to modify the FreeBSD 2.1R WaveLAN driver to allow hot insertion and removal of all cards used in our experiments.
3.2.2 Network Awareness
The network stack must detect when the network con guration associated with a network interface card (NIC) becomes inappropriate, such as moving beyond the range of a wireless basestation or reconnecting an Ethernet cable from one network to another. Each 5
WaveLAN
MH
350
PPP
Video Client
Router 129.95.56/24
Dialup Server
300
Ethernet
250
129.95.50/24 Router Frame Number
Video Server
"128x96" "256x192"
129.95.48/24
Figure 4: Experimental Environment
200
150
100
3.3 Device Indications
Device indications are used to inform applications about changes in device availability. Applications need to be informed when a device they are using becomes unavailable, and when a new device become available because the device characteristics assumed by the application may change dramatically. We have added indication support to FreeBSD using a pseudo-device driver. The application can use the write() system call to describe what types of events are interesting, the select() system call to await the events, and the read() system call to determine what event has occurred.
50
0 0
1000
2000
3000
4000 5000 6000 Time (milliseconds)
7000
8000
9000
10000
Figure 5: Frames Shown when Ethernet-connected 30
Display Frame Rate (fps)
25
4 Experiments
Our player runs on \Mobile Host" (MH), a Toshiba T4900CT laptop computer with a 75MHz Pentium R processor and 16 MB of RAM. The server runs on \Video Server" (VS), a Linux desktop system with a 166MHz Pentium and 64 MB of RAM. MH is capable of simultaneously using three di erent network interfaces: a 10 Mbps IBM Ethernet PC card, a 2 Mbps AT&T WaveLAN PC card, and a Courier 28.8 Kbps modem. The Ethernet interface connects to the same physical subnet used by the video server, and the other two interfaces are within two hops. Figure 4 illustrates our experimental setup. We use the same video for all experiments: a multiresolution ve minute MPEG clip of a NBA basketball game. The low-resolution stream is 128x96 and the high-resolution stream is 256x192. Both streams are captured at 30 frames per second.
20
15
10
5
0 0
50
100
150 Time (frame number)
200
250
300
Figure 6: Frame Rate when Ethernet-connected is the number of frames displayed per second, and not the number of frames received by the client.2 We calculate the frame rate observed at frame i as the inverse of the average interval between frames, IBFavg (i). We calculate the average interval between frames using a weighted average as shown in Equation 2 where IBFavg (0) = I0 . We use a weighted average to smooth out the burstiness present within an MPEG stream. Lower values of , the low pass lter coecient, force more intervals to be used in calculating the average. We set = 0:01 for all our frame rate plots.
4.1 Metrics
The goal of our experiments is to measure how quickly our system adapts to the new environment. We want to measure the hando latency and stabilization time seen by the application. We de ne hando latency as the time between the last frame played from the previous interface to the rst frame played on the new interface. Stabilization times are harder to de ne, since even a stable control system goes through
uctuations. Rather than come up with a single time, we present stability graphically as the convergence of display frame rate over time. The display frame rate
FrameRate(i) = IFB1 (i) avg
(1)
IBFavg (i) = Ii + (1 ? )IBFavg (i ? 1)
(2)
2 The real-time player has the option of throwing away late frames rather than spending time decoding them.
6
30
1600
1500
25
"300x128"
Frame Number
Display Frame Rate (fps)
1400 20
15
1300
1200
10 1100
5
1000
0 0
1000
2000
3000
4000 5000 6000 Time (frame number)
7000
8000
9000
900 30000
10000
Figure 7: Frame Rate when Ethernet-connected
35000
40000 Time (milliseconds)
45000
50000
Figure 8: Frames Shown (hando ) 30
The following example is taken from a client connected via Ethernet. The user has selected the higher resolution image (256x192) with a high threshold of 25 fps and a low threshold of 10 fps for resolution adaptation. Figure 5 shows the frames played by the client over the rst 10 seconds. At the beginning, the client cannot decode the incoming frames in time, so many frames are dropped because they are not processed before their deadlines. As the server begins to drop frames, the client can meet the real-time deadlines of more frames. After about six seconds, the client realizes it cannot achieve the 10 fps threshold and informs the server to reduce the resolution. Figure 6 displays the frame rate observed by the client. Since the rst two consecutive frames are displayed, the curve starts with 30 fps, and falls o quickly when frames are dropped. The frame rate drops to about ve frames per second until near frame 200 (6.7 seconds into the clip) where frame rate begins to increase as the lower resolution frames are processed by the video pipeline. Figure 7 shows the frame rate measured over the entire clip.
Display Frame Rate (fps)
25
20
15
10
5
0 900
1000
1100
1200 Time (frame number)
1300
1400
1500
Figure 9: Frame Rate (hando ) The majority of this gap is caused by the excessive number of exec operations used by pccardd and pmid. On detecting card removal, pccardd is con gured to execute a program that sends an appropriate message to pmid. On the receipt of a device removal message, pmid executes a utility program that selectively removes route entries associated with the invalid device. All our exec operations are performed cold (since we are assuming a mobile host will not move frequently enough that recon guration programs will be cached in memory), so they result in disk operations. The route cleaning utility is also rather inecient since it must remove routes one by one. A tighter integration would presumably improve performance, at the expense of more re-integration work for new releases. The application level hando is much faster. Figure 10 shows a tcpdump analysis from a machine connected to the Ethernet. The time between the SYN request from mh-wave and the rst UDP packet from the video server is about 40 milliseconds. The bottle-
4.2 Migrate without Bandwidth Change
In our rst experiment, MH is connected using only the Ethernet and WaveLAN interfaces. All trac between VS and MH is through the Ethernet device. Around 30 seconds into the clip, the Ethernet card is removed. At this time, pmid disables that interface, removes routes attached to that interface, and creates a new default route through the WaveLAN interface. The application is then noti ed that a mobility event has occurred. Figure 8 focuses on the frame numbers dropped by the client during hando and Figure 9 displays the frame rate over that same period. There is a large 3.867 second gap where only a single frame is played. 7
Ethernet to POTS to WaveLAN 30
mh-ether.1026 > vserver.1171: udp 12 vserver.1171 > mh-ether.1026: udp 1298 mh-ether.1026 > vserver.1171: udp 12 vserver.1171 > mh-ether.1026: udp 295 vserver.1171 > mh-ether.1026: udp 1182 vserver.1171 > mh-ether.1026: udp 1412 vserver.1171 > mh-ether.1026: udp 464 vserver.1171 > mh-ether.1026: udp 303 vserver.1171 > mh-ether.1026: udp 1412 vserver.1171 > mh-ether.1026: udp 386 vserver.1171 > mh-ether.1026: udp 1412 vserver.1171 > mh-ether.1026: udp 427 mh-wave.1025 > vserver.1172: tcp 0 syn vserver.1172 > mh-wave.1025: tcp 0 syn ack vserver.1172 > mh-wave.1025: tcp 0 syn ack mh-wave.1025 > vserver.1172: tcp 0 mh-wave.1025 > vserver.1172: tcp 4 vserver.1172 > mh-wave.1025: tcp 2 (DF) vserver.1172 > mh-wave.1025: tcp 4 (DF) vserver.1172 > mh-wave.1025: tcp 2 (DF) mh-wave.1025 > vserver.1172: tcp 2 vserver.1172 > mh-wave.1025: tcp 4 (DF) mh-wave.1025 > vserver.1172: tcp 4 mh-ether.1024 > vserver.7102: tcp 0 fin vserver.7102 > mh-ether.1024: tcp 0 vserver.1172 > mh-wave.1025: tcp 0 vserver.7102 > mh-ether.1024: tcp 0 fin ack vserver.1173 > mh-wave.1027: udp 1412 vserver.1172 > mh-wave.1025: tcp 0 vserver.1173 > mh-wave.1027: udp 1412 mh-wave.1027 > vserver.1173: udp 12
25
Display Frame Rate (fps)
17:58:50.304607 17:58:50.393365 17:58:50.394507 17:58:50.452323 17:58:50.493125 17:58:50.603541 17:58:50.603935 17:58:50.812316 17:58:50.993584 17:58:51.412515 17:58:51.823496 17:58:52.632775 17:58:53.713820 17:58:53.714179 17:58:53.715601 17:58:53.719549 17:58:53.722138 17:58:53.722964 17:58:53.723078 17:58:53.724726 17:58:53.724853 17:58:53.725643 17:58:53.727239 17:58:53.731418 17:58:53.731545 17:58:53.742493 17:58:53.742713 17:58:53.753892 17:58:53.768224 17:58:53.771082 17:58:53.796454
20
15
10
5
0 0
1000
2000
3000 4000 5000 Time (frame number)
6000
7000
8000
Figure 11: Frame Rate w/ noti cations MH
Video Client WaveLAN
HA
PPP
FA
Video Server
Dialup Server
Router
Figure 10: tcpdump hando trace
Figure 12: Mobile IP Setup
neck for the hando appears to be the network recon guration time. The decoder remains the bottleneck for the application, so there is no noticeable di erence in frame rate despite having 8 Mbps less peak throughput.
is noti ed, its new TCP control connection uses the WaveLAN interface and video data is re-directed to the WaveLAN interface. When the display frame rate of the lower resolution stream passes the 12 fps upper threshold, the higher resolution stream is requested and a stable display frame rate of 5 fps is achieved. Note that the PPP interface still remains in use and all other routes through that interface continue to use it.
4.3 Migrate with Bandwidth Change
The second experiment demonstrates adaptation to changes in both network migration and bandwidth change. The user has speci ed a high threshold of 12 fps and a low threshold of 3 fps for resolution adaptation. MH starts o with both the Ethernet and PPP connection and the player achieves a 5 fps display rate using the higher resolution stream. After 100 seconds (frame 3000), the Ethernet interface is removed. pmid disables the device and adjusts the default route to use the PPP interface, the only available interface left. The player responds to the lower bandwidth by dropping frames and requesting a resolution change once it determines it cannot meet the 3 fps minimum speci cation. After another 100 seconds (frame 6000), the WaveLAN card is inserted. It takes approximately three seconds to enable the device, and then pmid migrates the default route to the WaveLAN router. At this point, trac from MH ows back to the VS over the WaveLAN interface though video data continues to
ow into the PPP interface. Once the application
4.4 Mobile IP Comparison
In our nal experiment, we compare the TCP reestablishment and SCP reset with the transparency of a Mobile IP solution. The current implementation supports only hando s between WaveLAN devices. To simulate hando s between heterogeneous devices, we used the con guration shown in Figure 12. Hando to the FA occurs near frame 1600 and hando back to the HA occurs near frame 4000. While mobile IP successfully hides the e ects of dynamic network changes, it cannot hide the e ects of a drastic decrease, and later increase, in bandwidth from the video player. While the player eventually gures out the appropriate frame rate, because it is in its \stable state" mode, it reacts to changes in bandwidth in a sluggish manner and relies on SCP to avoid trampling TCP trac. If we had added indications to the Mobile
8
Mobile IP between WaveLAN and POTS
32-bit WinSock-2 Application
30
WinSock-2 API
Display Frame Rate (fps)
25
20
32-bit WinSock-2 DLL WinSock-2 SPI
15
Layered Service Provider 10
5
0 0
1000
2000
3000 4000 5000 Time (frame number)
6000
7000
Transport Service Provider
(TCP/IP)
(IPX/SPX)
8000
TDI
Figure 13: Frame Rate wo/ noti cation
LAN Protocols NDIS Interface
IP implementation, we believe we would have achieved similar results to those presented in Section 4.3 but with lower hando latencies.
5 Windows Evaluation
In addition to Unix, we want to run our multimedia applications on top of Microsoft Windows R , the dominant operating system platform. In this section, we describe our evaluation of the network and operating system support within Windows and compare it to 4.4BSD.
NDIS Intermediate
Network Media Aware Protocols
NDIS Miniport
Figure 14: WinSock-2 and NDIS Architecture So pulse may fail to detect the migration to a new network composed entirely of Windows95 and WindowsNT hosts and would falsely believe the interface to be disconnected. Link layer connectivity for wireless devices has excellent support within the lower layers. Newer releases of the Network Driver Interface Standard (NDIS) support the wireless extensions proposed by the Personal Computer and Communications Association (PCCA) [18]. These extensions add to NDIS 3.1 a number of new objects that allow service providers to query drivers about channel quality, registration status, radio link speed, network latency, and battery level. Support for indications is provided by a call that allows providers to register a condition on an object's value. For example, a provider can register a condition that channel quality should be greater than 50 (the scale is 1-100, and 100 is the highest quality). If channel quality falls below 50, the provider will receive an indication.
5.1 Hot Swapping
The Windows Plug and Play R architecture allows the dynamic insertion and removal of PCMCIA cards, along with hot docking. Our opinion is that Windows95 provides the best support for PCMCIA cards primarily because most PC cards have drivers for Windows. Our only problem was being able to receive packets from our WaveLAN card, and this was remedied once AT&T released a new miniport driver compatible with Windows95 OEM Service Release 2. Windows NT 4.0 has no support for Plug and Play.
5.2 Network Awareness
Windows95 has no support for detecting network changes during normal operation. If con gured to use the Dynamic Host Con guration Protocol (DHCP) [11] to acquire a network name Windows95 will recon gure the interface correctly when migrating between networks as long as the computer is either rebooted or resumed when it is attached to the new network. The computer must also be able to communicate with a DHCP server on the new network. We found that Windows95 and WindowsNT using the Microsoft network stack do not respond to ICMP echo request to the all hosts multicast address.3 3
Transport Service Provider
5.3 Routing Policy
WinSock-2 [22] is the new networking software interface for Windows operating systems and is built into all WindowsNT 4.0 platforms. While Windows95 does not fully support the WinSock-2 architecture, it will probably do so in future releases. The WinSock-2 architecture is a transport-layer application programming interface. Our problem is we want to in u-
It is an optional feature for a host network stack.
9
tion. Because our player was already quite sophisticated in adapting to bandwidth variations, enhancing it to support IP address variations required minimal modi cations. We require only a few enhancements to the operating system and no changes to the network stack. Another approach would be to place more of the burden on the system and network, avoiding any modi cations to existing applications. This provides application-transparent mobilitysupport and supports the largest number of legacy applications. We use a subset of the OSI reference model to help categorize other approaches. Figure 15 depicts the general structure of any client-server-based mobile system. The intermediate gateway provides a layer of indirection that adapts in response to client migration.
ence network-layer policies related to routing, such as selecting the default route and multicast interface. WinSock-2 encapsulates all routing information and policies within each Service Provider [23]. While both Windows95 and WindowsNT provide DOS commands4 to access the routing table, there is no published API for route table access. This hides both mechanisms and policies within the Service Provider and di ers from 4.4BSD where routing policies are implemented in user-level daemons that communicate with the kernel's route table using the routing socket [24]. While a single routing policy is not that noticeable when using one interface, it may become an obstacle when multiple interfaces are in use. Windows95 appears to set the default route to the router attached to the NIC inserted last. Windows dial-up networking may also be con gured to set the default route, and it will take precedence over a LAN route if a dialup PPP session is started after a LAN card has been inserted.
6.1 Application-level Gateways
Video gateways [2, 17] address the problem of maintaining backward compatibility with video servers designed for a particular network environment. UC Berkeley's video gateway, vgw [2], performs bandwidth adaptation through transcoding and ratecontrol. Acting as a gateway between a high and low bandwidth network, vgw receives RTP-encapsulated motion JPEG input from the high bandwidth side, transcodes it to H.261 (dropping JPEG frames as necessary), and sends the resulting H.261 RTP stream out to the low bandwidth side. The gateway allows the video server to multicast high quality video without worrying about ooding the low bandwidth network.
5.4 Mobility-generated Indications
Windows has a huge win in supporting mobilityrelated indications. Both WinSock-2 and NDIS provide a much richer (and more complex) programming interface compared to 4.4BSD. WinSock-2's owspec includes a NetworkAvailability eld. This can be used in conjunction with the WSAEventSelect() function to receive a noti cation when the socket's QoS changes. While WinSock-2's owspec supports failure indications, it does not support optimistic indications that inform applications when \better" interfaces become available. WinSock-2 was designed to provide a transportlayer API, and network availability can be considered more of a link-layer concern since it is associated with devices. Applications will be able to access the NDIS extensions mentioned in Section 5.2 via the NetDev API.
6.2 Network-level Gateways
Network address transparency is provided by these gateways. Mobile IP [19] allows a host to retain its IP address while migrating between di erent IP networks. Intermediate network-level gateways, called mobile agents, are used to maintain this concept. When away from home, a mobile host is responsible for acquiring a \care-of-address" (COA). This address can be obtained by the mobile host through a dynamic con guration protocol such as DHCP, or provided via a registration with a \foreign agent" (FA). The mobile host uses the COA to register with a \home agent" (HA) on the home network. Once the registration has been approved, packets sent to the mobile node are intercepted by the HA and forwarded to the COA using IP encapsulation. Packets sent from the mobile host are routed to the destination address in a traditional manner.5 Unlike link-layer solutions, Mobile IP handles mobility over heterogeneous networks. Stemm [21] has demonstrated \vertical hando s" between two di erent wireless technologies,
5.5 Summary
The strengths of the Windows architecture are primarily Plug-and-Play and powerful transport and driver interfaces. The glaring de ciency is the encapsulation of network-level policies within service providers. This makes it dicult to experiment with the user-level mobility policies mentioned in this paper.
6 Related Work
Our approach in supporting mobility places the majority of the adaptation burden on the applica4 route
entries.
can be used to display, add, and remove routing table
5 This is the basic mode of operation though there are many possible variations [9].
10
Application
Application
Application
Transport
Transport
Transport
Network
Network
Network
Data Link
Data Link
Data Link
Intermedia Gateway
Mobile Host
Multimedia Server
Figure 15: Client-Server Mobile Computer Architecture error rates. Rutgers' I-TCP [3] and Berkeley's snoop protocol [4] use a specialized retransmission mechanism to avoid the performance problems that occur when TCP inappropriately invokes congestion control mechanisms in response to packet lost to bit errors. Systems that are highly mobile will require more advanced hando schemes to reduce the disruption of real-time multimedia streams. Several approaches have been used to minimize this hando latency [13, 5].
AT&T WaveLAN and Metricom's Ricochet. While mobile IP provides network address transparency, it ignores end-to-end bandwidth concerns. Our experiments with Mobile IP have show that changes in bandwidth are much less disruptive if the bandwidthadaptation module is informed when paths change dramatically. Mobile IP would be more e ective for streaming multimedia applications if hando noti cations could be passed up to application programs.
6.3 Link-layer Gateways
7 Summary
These gateways handle mobility transparently at a low level and require no changes to be made at any other layer. One example, the cellular telephony network, handles mobility without requiring modi cations to either network protocols or application programs. The widely deployed AMPS and GSM networks provide nearly ubiquitous access for a mobile host. Metrocom's Ricochet6 technology provides similar access within a metropolitan area network (MAN). Lack of bandwidth is the major de ciency of wide area wireless technology. Cellular networks provide roughly 9.6 Kbps while Ricochet networks provide approximately 30 Kbps. So while a multimedia application designed for these networks is highly mobile, its content is limited by severe bandwidth constraints. Wireless ATM [1] and LAN technology may provide higher bandwidth, but their range is limited to usually a single building.
We have outlined a layered architecture for supporting mobile multimedia applications. Each layer performs the adaptation best suited for it using a methodology of de ning quasi-invariants, guarding quasiinvariants, and adapting intelligently when guards trigger. No single layer attempts to hide all the e ects of mobility. By passing guards on mobility-related characteristics to lower layers, higher layers can receive cross-layer noti cations and perform the scaling and other adaptation operations best suited to them. We demonstrated this architecture using an implementation of a mobile streaming video player. Mobility indications force the software feedback module into an exploratory mode and cause the video client to re-establish the control and data channels between it and the server. This allows the player to quickly adapt to new environments while migrating across heterogeneous networks. We are currently in the process of re-structuring our system to make it more system independent and allow it to function on both Unix and Win32 platforms.
6.4 Other Problems Caused by Mobility
In this paper, we have concentrated on two e ects caused by mobility: variations in network addresses and drastic changes in available bandwidth. There are other mobility-induced variations that a ect multimedia applications. Wireless networks have di erent characteristics associated with them, such as high bit 6
Acknowledgements
We would like to thank the Quasar group for developing the adaptive framework described by this paper, and the anonymous referees for their comments. We
See http://www.ricochet.com for more information.
11
would also like to thank Jim Binkley (Portland State University) for providing the mobile IP implementation and routers used in our experiments. The Windows investigation was performed by Jon Inouye as an intern in Intel's Internet and Wireless Lab (IWL). That investigation bene ted from many discussions with Mike Tso and the IWL group, and meetings with Chunrong Zhu, David Anderson, and Charlie Tai within Intel Architecture Labs.
[11] Droms, R. Dynamic Host Con guration Protocol. Network Working Group Request for Comments: 1541, October 1993. [12] Inouye, J., Binkley, J., and Walpole, J. Physical Media Independence: System Support for Dynamically Available Network Interfaces. Tech. Rep. CSE-97-001, Department of Computer Science, Oregon Graduate Institute of Science and Technology, January 1997. [13] Keeton, K., Mah, B. A., Seeshan, S., Katz, R. H., and Ferrrari, D. Providing ConnectionOriented Network Services to Mobile Hosts. In Proceedings of the USENIX Mobile and LocationIndependent Computing Symposium (Cambridge, Massachusetts, August 1993), pp. 83{102. [14] McCanne, S., and Jacobson, V. The BSD Packet Filter: A New Architecture for User-level Packet Capture. In Proceedings of the 1993 Winter USENIX Conference (San Diego, CA, January 1993), pp. 259{ 269. [15] McCanne, S., and Jacobson, V. vic: A Flexible Framework for Packet Video. In Proceedings of the Third ACM Conference and Exhibition (Multimedia '96) (San Francisco, California, November 1995), pp. 511{522. [16] McKusick, M. K., Bostic, K., Karels, M. J., and Quarterman, J. S. The Design and Implementation of the 4.4BSD Operating System. Addison-Wesley, 1996. [17] Meggers, J., Bautz, G., and Park, A. S.-B. Providing Video Conferencing for the Mobile User. In Proceedings of the 21st Conference on Local Computer Networks (Minneapolis, Minnesota, October 1996), pp. 526{534. [18] Extensions to NDIS 3 for Wireless WANs. Portable Computer and Communications Association, 1995. Available at http://www.airdata.com/pcca/. [19] Perkins, C. IP Mobility Support. Network Working Group Request for Comments: 2002, October 1996. [20] Staehli, R. Quality of Service Speci cation for Resource Management in Multimedia Systems. PhD thesis, Oregon Graduate Institute of Science and Technology, January 1996. [21] Stemm, M. Vertical Hando s in Wireless Overlay Networks. Master's thesis, University of California at Berkeley, 1996. Published as UCB Technical Report CSD-96-903. [22] Windows Sockets 2 Application Programming Interface, Revision 2.2.0, May 1996. [23] Windows Sockets 2 Service Provider Interface, Revision 2.2.0, May 1996. [24] Wright, G. R., and Stevens, W. R. TCP/IP Illustrated, Volume 2: The Implementation. AddisonWesley, 1995.
References
[1] Agrawal, P., Hyden, E., Krzyzanowski, P.,
Mishra, P., Srivastava, M. B., and Trotter, J. A. SWAN: A Mobile Multimedia Wireless Net-
work. IEEE Personal Communications 3, 2 (April 1997), 18{33. [2] Amir, E., McCanne, S., and Zhang, H. An Application-Level Video Gateway. In Proceedings of the Third International Multimedia Conference and Exhibition (Multimedia '95) (San Francisco, California, November 1995), pp. 255{265. [3] Bakre, A., and Badrinath, B. R. Hando and System Support for Indirect TCP/IP. In USENIX Mobile and Location Independent Computing Symposium (Ann Arbor, Michigan, April 1995). [4] Balakrishnan, H., Seshan, S., Amir, E., and Katz, R. H. Improving TCP/IP Performance over Wireless Networks. In Proceedings of the First Annual International Conference on Mobile Computing and Networking (Berkeley, California, November 1995), pp. 2{11. [5] Caceres, R., and Padmanabhan, V. N. Fast and Scalable Hando s for Wireless Internetworks. In Proceedings of the Second Annual International Conference on Mobile Computing and Networking (Rye, New York, November 1996), pp. 56{66. [6] Casner, S., and Deering, S. First IETF Internet Audiocast. Computer Communications Review 22, 3 (July 1992). [7] Cen, S. A software feedback toolkit and its applications in adaptive multimedia systems. PhD thesis, Oregon Graduate Institute of Science and Technology, In preparation. [8] Cen, S., Pu, C., Staehli, R., Cowan, C., and Walpole, J. A Distributed Real-Time MPEG Video Audio Player. In Proceedings of the Fifth International Workshop on Network and Operating System Support of Digital Audio and Video (NOSSDAV '95) (Durham, New Hampshire, April 1995), pp. 151{162. [9] Cheshire, S., and Baker, M. G. Internet Mobility 4x4. In Proceedings of the ACM SIGCOMM'96 Conference (Stanford University, CA, August 1996). [10] Deering, S. ICMP Router Discovery Messages. Network Working Group Request for Comments: 1256, September 1991.
12
