Heterogeneity in Pervasive Computing

1
Heterogeneity in Pervasive Computing
88 Lines about 44 Projects1

• Glenn Glazer
• CS 239,Spring 2003

1With apologies to the Nails.
2
Presentation Purpose

• The question is not so much What is
  Heterogeneity? but Heterogeneity with respect
  to what?.
• Therefore, we need is a taxonomy of the different
  kinds of heterogeneity we face.
• This presentation will introduce a large number
  of projects and papers, but we will not delve
  deeply into any of them. Instead, I will provide
  pointers to papers and websites related to each
  genus.

3
Why the background image?

• When architects build structures, they have many
  choices in both form and function leading to a
  wide heterogeneity of both design constraint and
  design products.
• As architects of a new computing frontier, we do
  the same.

4
Someone Elses Definition
Heterogeneous computing systems are those with a
range of diverse computing resources that can be
local to one another or geographically
distributed. The pervasive use of networks and
the Internet by all segments of modern society
means that the number of connected computing
resources is growing tremendously. Hence, the
opportunity and need for heterogeneous computing
systems to effectively utilize these resources in
new and novel ways is growing concomitantly. This
has given rise, for instance, to the notions of
grid computing and peer-to-peer computing. The
effective implementation of efficient
applications in these environments, however,
requires that a host of issues be addressed that
simply don't occur in "single-chassis" sequential
or parallel machines.
IEEE Heterogeneous Computing Workshop
5
Taxonomy Top Levels
Types of Heterogeneity
Device Migration
Mobile Agents
Networks
Devices
Locations
Responses To Heterogeneity
API Abstraction
Proxy Abstraction
Data Manipulation
Messaging
Heterogeneous Aware Applications
Discovery
Security
n.b. I will now abbreviate heterogenous,eity
as h., for example, h. devices
6
Types of Heterogeneity

• The first step is to identify the sources of
  heterogeneity.
• Then we can categorize them in order to organize
  our thinking about them.
• Damned Things
• Multiple Group Membership

7
Networks

• By far the most explored form, both in breadth
  and depth (h. networks search on CiteSeer returns
  823 references)
• QoS if networks do not vary, QoS is simple.
• Minutae Daedulus is studying h. TCP networks and
  RMX studied h. reliable multicast.
• In the systems end of networks, the BARWAN
  project examined choosing different networks
  based on their h. qualities.

8
Sample Network Bibilography

• QoS
• QoSME http//citeseer.nj.nec.com/477970.html
• TCP
• Daedulus http//citeseer.nj.nec.com/balakrishnan9
  7tcp.html
• Multicast
• RMX http//citeseer.nj.nec.com/chawathe00rmx.html
  
• BARWAN
• http//citeseer.nj.nec.com/259131.html

...And a cast of thousands
9
Locations

• As we have seen from other presenta-tions, this
  is a large and evolving field.
• location can be in the domains of physical space,
  topological, logical, administrative and so on.
• Presents many real world problems, including h/w
  failure and abuse, security, privacy, etc.
• My current research (ACADEME) is here.

10
Location Bibliography

• Survey (Hightower, et al)
• http//citeseer.nj.nec.com/558297.html
• Cricket
• http//citeseer.nj.nec.com/558297.html
• SmartKG (AHLoS)
• http//nesl.ee.ucla.edu/projects/ahlos/
• Nirupama Bulusu Thesis (D. Estrin)
• Self-Configuring Localization Systems
• http//citeseer.nj.nec.com/553642.html
• Error Estimation
• http//citeseer.nj.nec.com/547398.html
• See also Discovery

11
Devices

• Probably the most obvious/naive source of h.
  computing.
• affects all modes of I/O and computation
• Despite this, virtually nobody addresses it as a
  sole problem, viewing it as either
• A launch point for discovery, proxy, MW, etc.
• A constraint on system design, or
• Something to be masked or abstracted away.

12
Device Migration

• Given h. devices, we can switch from changing
  based on networks (BARWAN) to changing based on
  devices.
• First work was done at Olivetti (Now ATT) called
  Teleporting. This eventually became the SunRay
  technology.
• iMASH has extensively studied this issue over
  several years.

13
Device Migration Bibliography

• Teleporting
• http//citeseer.nj.nec.com/richardson95teleporting
  .html
• SunRays
• http//wwws.sun.com/hw/sunray/index.html
• iMASH
• http//pcl.cs.ucla.edu/projects/imash/docs.htm
• Especially
• http//www.cs.ucla.edu/classes/spring03/cs239/l5/p
  apers/imash.pdf

14
Mobile Agents

• Originally, mobile agents required uniform
  platforms on all hosts.
• This is changing due to API Abstractions (see
  next section) and the varying results in these
  projects depends on the API.
• For example, LIME mixes MA with Linda tuples.
• The Mole project at Stuttgart was a recent
  project (1995-2000) in MA which re-examined MA in
  the current context and examined such ideas as MA
  reliability, MA security and mixing Java and
  CORBA in the same system.

15
MA Bibliography

• MA Survey
• Mobility Processes, Computers and Agents,
  Edited by Dejan Milojicic, Frederick Douglis and
  Richard Wheeler. ACM Press, 1999.
• LIME
• http//www.cs.wustl.edu/mobilab/research.html
• Mole Project
• http//mole.informatik.uni-stuttgart.de/

16
Responses to Heterogeneity

• Now that weve identified the major classes, how
  do we generally deal with them?
• Four methods
• API Abstraction, Messaging, Proxy Abstraction and
  Data Manipulation
• Not mutually exclusive
• First three are really programmatic, data
  manipulation is end-user driven.

17
API Abstraction

• One way to deal with h. problems is to abstract
  away the problem.
• Solutions in this mode tend to have a common top
  end and a family of specialized bottom ends
  (dev drivers).
• One style of top end is to have a common API that
  lives on each device and does local translation
  for outbound communication.

18
API BibliographyLanguages and OSs

• Java
• www.java.sun.com
• CORBA
• www.omg.org
• 2K
• http//citeseer.nj.nec.com/296843.html
• DCOM
• www.microsoft.com/com/tech/DCOM.asp
• one.world
• http//cs.nyu.edu/rgrimm/one.world/
• BASE (plug-in µ-kernel)
• http//citeseer.nj.nec.com/550575.html
• Gaia
• http//citeseer.nj.nec.com/roman00gaia.html

19
API BibliographyDSM

• Linda
• http//www.cs.yale.edu/Linda/linda.html
• TSpace (Lindadatabase in Java)
• http//citeseer.nj.nec.com/lehman99spaces.html
• JavaSpaces
• java.sun.com/products/javaspaces/

Here and elsewhere, there is a definite tension
between commercial and/or standards-based
approaches and roll-your-own approaches.
20
Messaging

• We have long observed that the network
  communication protocols can be used to enforce a
  universal Esperanto.
• Essentially an OOP approach
• Two basic techniques
• RPC
• translation provided by language support
• Socket based
• translation either ad hoc or RFC based

21
Proxy Abstraction

• Messaging API leads to having a machine in the
  middle that performs the heavy lifting of
  abstraction.
• So, we move from a middleware layer to a
  middleware machine or service.
• Such machines can provide other services, such as
  discovery, data manipulation and
  so on.
• Trent

22
Proxy Abstraction Bibliography

• Ninja
• http//citeseer.nj.nec.com/gribble00ninja.html
• http//ninja.cs.berkeley.edu/overview.html
• Data AND protocol manipulation
• Most device migration architectures
• BARWAN, Teleporting, iMASH
• NetBlitz (Systematic Multiresolution)
• http//citeseer.nj.nec.com/acharya98systematic.htm
  l
• Also in the data manipulation category
• DSM
• As a bit of stretch.

23
Data Manipulation

• Obviously, some devices are more capable of
  receiving and displaying data than others.
• implies having the device do content adaptation,
  but the ones who most need this are also the ones
  least able to manipulation!
• This takes us back to proxies.
• Another approach is web caching (e.g.,
  http//citeseer.nj.nec.com/547516.html) and
  pre-adaptation by bandwidth.
• To some extent UI (as data) adaption is here too.
  (M-Links)
• http//citeseer.nj.nec.com/schilit01mlinks.html

24
Heterogeneous Aware Apps

• As a sample of where we can go with the problem
  and tools at hand.
• Security is obviously a big concern and harder
  due to lightweight computing components.
• The mobile aspect of h. computing leads to
  discovery techniques which can also be used to
  advertise a devices needs.

25
Security

• h. security has several facets
• different levels of computational capacity
• disconnectivity often plays havoc with block
  chaining cypher algorithms
• differing security requirements
• h. security research can also be found as an
  adjunct to other projects, e.g., iMASH, Ninja and
  Mole.
• Some overlap with FT/HA research.
• Open question can motes be deployed with an ad
  hoc network and be provably secure?

26
H. Security Bibliography

• Vigil (cert/SPKI/distributed trust)
• http//research.ebiquity.org/re/papers.html
• Kotzanikolaou, Burmester, et al
• secure functions signatures for MA
• http//citeseer.nj.nec.com/kotzanikolaou00secure.h
  tml
• ZIA
• http//www.eecs.umich.edu/mcorner/papers.html
• See also Vol. 2, No. 1 of Pervasive Computing

27
Discovery

• With different types of networks, different
  locations and especially with mobility, comes two
  needs.
• Traditionally, you needed to discover your
  environment.
• In pervasive computing, we are coming to the
  point where the environment needs to discover
  you.
• Is there a difference?

28
Discovery Bibliography

• JINI
• http//java.sun.com/products/jini/
• http//www.swzoo.org/documents/presentations/2000-
  04-27_jklm/ (Mindstorms)
• SLP (IETF, UA/SA/DA)
• http//www.iprg.nokia.com/charliep/
• http//sourceforge.net/projects/srvloc/
• SDS (see Ninja)
• MOCA (IBM/Pitt, registry adapter)
• http//www.cs.pitt.edu/mobide/talks/beck/
• ACADEME

29
Conclusion

• Doing h. taxonomy is an inherently conflicted
  task, but still utile.
• Many thing belong in several categories, but
  absences are as telling as presences.
• Ubiquity is not the same as heterogeneity,
  but
• heterogeneity is ubiquitous.

H \subset U ?