8/8/2019 p52-satyanarayanan

1/4

A p p l i c a t i o n - Aw a r e A d a p t a t i on f o r M o b il e C o m p u t i n g

M. Satyanarayanan, Brian Noble, Puneet Kumar, Morgan PriceSchool o f Compute r Sc ience

Carnegie Mellon Universi ty

Abstract

This paper identifies application-aware adaptation as an essential capability of mobile clients, andprovides an o verview ofOdyssey, an architecture that supports this capability. Functionality that hashitherto been implemented monolithically must now be split between the operating system andindividual applications. The role of the operating syste m is to sense external events, and to monito rand allocate scarce resources. In contrast, the role of individual applications is to adapt to changingconditions b y using the information and resources provided by the operating system.

1. IntroductionIn this posi t ion paper we put for th the view thataccess to shared data in mobile computing systems is best achieved

by a "collaborative partnership between the operating system and individual applications. This s t rategycharacter izes the design space between two extremes. At one extreme, the system provides total t ransparency:appl icat ions are completel y unaw are of mobil i ty. At the other extreme, there is no system support : each appl icat ioncopes with m obil i ty on i ts own. I t is our thesis that a col laborat ive partnership wil l bet ter cope with the proble msinduced by m obil i ty. We refer to such a s t rategy asapplication-aware adaptation.

2. Functional Partitioning for Mobile ComputingData access in mobile environm ents is complicated by a number of factors . First ,scalability is a concern bothbecause o f the expec ted ub iqu i ty o f mobi le compute rs and because o f the inc reas ing vo lume of da ta in sharedreposi tor ies . Second, we have to cope with cer tainfundam ental constraints of mobil i ty: mobi le hos t s t end to beresource poor because of s ize, weight , and power constraints ; they are physical ly vulnerable to loss , thef t and otherhazards; and they have to cope with considerable variat ion in the perfOrmance and rel iabi l i ty of wirelesscomm unicat io n. Third, data is increasinglydiverse in format: in addi t ion to the well-understoo d data formats ofUnix-l ike hierarchical f i le systems and SQL databases, there is growing interest in video images, maps and otherspat ial images, and hypertext- l ike data as in the World-Wide Web.

The resource poverty, physical vulnerabi l i ty and scalabi l i ty concerns of mobile hosts suggest a c l ient-serverarchi tecture, with serve rs being the t rue home of data and cl ients merely being caching s i tes . At the sam e t ime, theuncertainty in wireless communicat ion requires cl ients to adapt dynamical ly, reducing their dependence on serversas the qual i ty of com mun icat ion degrades. The need to support diverse types of data suggests that the adaptat ion

cannot be un iversal , but needs to be customiz ed for each type of data .

These considerat ions l ie behind our advocacy of appl icat ion-aware adaptat ion as the paradigm of data access in

mob ile environments . In our model , the role of the operat ing system is to sense external events (such asconnect ivi ty and physical locat ion changes) , and to monitor and al locate resources (such as network bandwidth,cache space, bat tery power, and com mun icat ion budget) . In contrast , the role of individual appl icat ions is to adaptto changing condit ions b y using the information and resources provided by the operat ing system. The nature o f theadaptat ion is specif ic to the appl icat ion. For example, in accessing video data , degrading the display from ful l -motio n color to black and white , and thence to s low-scan might be appropriate . But when accessing map data , themeaningfu l fo rm o f degrada tion migh t b e to lower the reso lu tion and m in imu m fea tu re s i ze represen ted . The overa l lgoal is to minimi ze the need for act ive intervent ion by users to cope with the consequences of mobil i ty. Forexam ple, i t is inappropriate to require the user to use a different video display program w hen ban dwidth drops.

5 2

8/8/2019 p52-satyanarayanan

2/4

3. Ex ample: Application-Specific Conflict ResolutionA sim ple instance of this col laborat ive paradigm is a lready operat ional in the Coda Fi le System [2, 3] . Cod a uses anoptimist ic repl ica control s t rategy to al low updates to cached data while disconnected. Resp onsibi l i ty formonitor ing connect ivi ty, resynchronizing cache s tate upon reconnect ion with servers , and detect ing update confl ic tsis vested in the Coda cache manager, Venus . But once a confl ic t is detected on a f i le , Venus invokes anapplication-specific resol ver (A SR )and lets it resolve the confl ic t . I f the ASR succeeds, the confl ic t is t ransparent tothe user; otherwise the confl ic t become s vis ible and has to be repaired manual ly.

The impor tance o f app l ica t ion ass i s t ance can be seen by cons ider ing the example o f a ca lendar managementprogram . Suppo se an execut ive and her secretary both make appointments while the forme r is disconnected. Upo nreconnect ion, V enus detects that the f i le containing appoin tments is in confl ic t . But i t has no know ledge o f theforma t of f i le contents , nor of whether there is real ly a scheduling confl ic t . Only co de specif ic to the calendarprogram can tel l , for instance, that appointments for an hour each at 8am and 10am on the same day pose noproblem if they are in the execut ive 's off ice, while those same appointments are impossible to keep i f they are inNew York and San Franc i sco.

At the same t ime, the central izat ion of resource control provided by Venus is essent ial to managing cache space andnetwork bandw idth across appl ications. There is a lso an important performa nce benefi t during reintegrat ion: thecommon case of no confl ic ts is eff ic ient ly handled by Venus using the syntact ic approach of version comparisonrather than by the more exp ensive semantic app roach of invoking appl icat ion-specif ic code on each cach ed f i le .

One can think o f this part i t ioning of responsibi l ity in terms of the end-to-end argument [4]. Correctness requireshelp from the end points ( in this case, the appl icat ions) . But eff ic iency and resource manage men t considerat ionsargue for suppo rt a t lower levels of the system ( in this case, Venus) .

4. Odyssey: A Platform for Mobile Data AccessWe are current ly exploring the paradigm put for th in this posi t ion paper. The veh icle for our wo rk isOdyssey, a setof Unix extensions for mobil i ty. The extensions are both at the system cal l level and internal to the operat ingsystem. The O dysse y archi tecture is a general ization of the Coda archi tecture [5]. Data is s tored in a shared,h ie ra rch ica l nam e space made up o f typed vo lum es ca l l edtomes. There a re th ree components o f Odyssey a t eachclient:

the Odyssey API, a set of new sy stem cal ls ;

the viceroy, which provides type-independent funct ional i ty and resource management; and,

mult iple wardens, which handle type-specif ic funct ional i ty and resource management .

4.1. TomesTomes are conceptual ly s imilar to volumes [1] in AFS and Coda. They are the uni t of system administrat ionfunct ions such as backup and disk quota enforcement . But they differ f rom volum es in that they carry with them thenotion of type. Each tome type, referred to as acodex, ident ifies a unique comb inat ion o f character is t ics andpolicies such as naming, con sis tency, forms of graceful degradat ion, and caching s trategies . Ex amp les of codicesmight be "Unix" , "SQL", " Mpeg video", "Grass" , and so on. Servers do not have to be dedicated to part icularcodices -- tome s of different codices can reside on the same server.

Figure 1 i l lustrates the Odyssey nam e space. Each to me is stored in i ts ent i rety on a server. As in AFS an d Coda,

the name space is locat ion t ransparent and tomes are glued together atmoun t points. Although the roo t o f everytome has a hierarchical name, the name space within a tome need not be hierarchical . An S QL tom e, for examp le,might only support associat ive naming.

Data is typed by i ts locat ion in the name space: for example, video data must be in a video tome, and so on.

5 3

8/8/2019 p52-satyanarayanan

3/4

S

u~

MI

This figure shows a hypothetical Odyssey name space. It has three tomes, each from a different codex. The root tome is fr om a UNIXfile codex. Embedded in it are mount points to an Mpeg tome, with root mo vi es , and an SQ L tome, with root pa yr ol l. The internalname structure of the Mpeg tome is hierarchical: a directory with two movies, ba 2 2. mpg and cal . rapg, is visible. The SQL tome,however, has no internal naming visible at this level.

Figure 1 : Odyssey Name Space

Although this is a larger granularity than one might like, it does obviate the need to provide individual type tags to

Ody ssey objects. This, in turn, preserves upw ard compatibility with existing data.

4 . 2. O d y s s e y A P IThe O dyssey API consists of two classes of extensions to the 4.4 BSD Unix system call interface. One class,pertinent to this paper, is for resource negotiation an d change notification. The other class, not discussed here,supports an abstraction calleddynamic sets [6].

Resources in Odyssey are divided into two classes: generic and codex-speaif ic . Exam ples of generic resourcesinclude disk space, network bandw idth and battery power. An exam ple of a codex-specif ic resource might be thenumb er of R PCs to a s tock-quotat ion server, assuming each user is restr icted to a certain num ber of cal ls per day.

An application can negotiate and register a window of tolerance with Odyssey for a part icular resource. Ifavailabil i ty of that resource r ises above or fal ls below the l imits in the tolerance window , O dyssey wil l notify theapplication. Once notified, it is the application's responsibility to reneg otiate a new toleranc e wind ow and to adapti ts behavior accordingly. The request and notificat ion interfaces are similar to ' those of the s ig n a l faci l i ty in Unix.To place a request , an applicat ion passes a resource identif ier, the lower and upper bounds of the tolerance window,and the address o f an upcall procedure to be invoked if the tolerance window is exceeded.

4.3. Viceroy and W ardensThe vicero y and wardens may be collect ively viewed as a general izat ion of the Coda cache manager, Venus. Theircombined role is to provide the generic and special ized functionali ty and cache management needed by the cl ient .Thus their relationship is collaborative in nature, as shown in Figure 2. Applications are, of course, unaware o f theexistence of wardens and the viceroy; al l they see is the Odyssey and Unix APIs.

The viceroy is responsible for monitoring external events and levels of generic resources, and notifying cl ients whohave placed requests on those resources. I t also provides functionali ty that is comm on to al l tomes, such as

authentication, tome location and system administrat ion. Other operat ions are forwarded by the viceroy to theappropriate warden. Final ly, the viceroy is responsible for type-independent cache managemen t functions.

Type-specif ic functionali ty is delegated to wardens, one per codex. Each warden implem ents caching and nam ingsupport specif ic to i ts codex, and manages codex-specif ic resources. As i ts name implies, a warden o nly has acustodial relat ionship to the resources i t manages -- ul t imate control of these resources always resides with the

5 4

8/8/2019 p52-satyanarayanan

4/4

This figure shows the internal structure of a typical Odyssey client. Applications make requests on Odyssey objects. These requests areredirected through the kernel to the kernel interface of the Odyssey cache manager. The viceroy fields each request, handles genericoperations, and passes all other operations on to individual wardens. Resources, such as cache space, are loaned to wardens by theviceroy. Wh en neces sary, the viceroy notifies applications of changes in resource availability.

Figure 2: Structure of an Odyssey Client

viceroy.

The s tructure of Odyssey has many desirable propert ies . Firs t , i t provides a balanced approa ch to resource

mana geme nt . Althoug h responsibi l i ty is delegated to the wardens, they share a com mo n point of resource control inthe viceroy. This al lows the wardens to work effect ively together, in contrast with current s tate of affairs , whereresource man agem ent across data types is uncoordinated. Second, funct ional i ty is impleme nted wh ere i t is needed:type-specif ic code is contained within the wardens; resource sharing and key interfaces are in the viceroy. Final ly,the system is extensible: adding a new cod ex and i ts warden are relat ively s t raightforward.

5 . Conc lus ionAccessin g shared data from mobile cl ients poses many chal lenges. We bel ieve that nei ther a ful ly t ransparentapproach, nor a purely appl icat ion-by-applicat ion approach can mee t these chal lenges adequately. H ence ourapproach is to expose mobil i ty in a control led and l imited manner to appl icat ions, while reserving ownership andcontrol of key resources to the system. This is the essence of appl icat ion-aware adaptat ion.

The O dysse y archi tecture embodies this phi losophy. I ts goal is to be a f lexible and eff icient base for appl icat ion-aware adaptat ion in mobile computing env ironments . An implem entat ion of this archi tecture is under way, and wehope to be able to report posi t ively on i ts effect iveness in the near future.

References

[1] How ard, J.H., Kazar, M.L., Menees, S.G., Nichols, D.A.,Satyanarayanan, M., Sidebotham, R.N., West, M.J.Scale and Perfor mance in a Distributed File System.A CM Transactions on Computer Systems 6(1), February, 1988.

[2] Kumar, P., Satyanarayanan, M.Supporting Application-S pecific Resolution in an Optimistically

Replicated Fi le System.In Proceedings of the 4th IEEE Workshop on Workstation

Operating Systems. Napa, CA, October, 1993.

[3] Kumar, P., Satyanarayanan, M.Flexible and Safe R esolution of File Conflicts.In Proceedings of the 1995 Usenix Conference. New Orleans,

LA, January, 1995.

[4] Saltzer, J.H., Reed, D.P., Clark, D.D.End-To-End Arguments in System Design.ACM Transactions on Computer Systems 2(4), November, 1984.

[5] Satyanarayanan, M., Kistler, J.J., Kumar, P., Okasaki, M.E.,Siegel, E.H., Steere, D.C.Coda: A H ighly Available File System for a Distributed

Workstation Environment.IEEE Transactions on Computers 39(4), April, 1990.

[6] Steere, D.C., Satyanarayanan, M.A Case for Dynamic Se ts in Operating Systems.November, 1994.In preparation.

5 5