I am looking for full time graduate students to work on any of these projects:
  1. I have developed file system techniques for keeping a user's working set of files in ``flash EEPROM,'' which is solid state non-volatile storage like that used in digital cameras. Access to flash EEPROM is much faster than access to disk and consumes much less power. A single file system is spread across both flash and disk, with periodic reorganizations to keep the working set in flash. This technique is valuable for portable computers, giving the user both the performance and power efficiency of flash for the majority of accesses while retaining the large storage capacity of disk. Since the disk is rarely accessed, it is usually turned off, becoming something akin to a traditional tertiary storage device. Furthermore, directing most file accesses to a constant-access-time medium opens the possibility of completely rethinking file system data structures. Existing file system data structures are governed by the fact that, on disk, following a pointer is likely to require a seek. This is typically not true for a file system that keeps the working set in flash, making it practical to consider new data structures that optimize other characteristics such as performance or robustness.

  2. How to provide location-dependent services? Technology and government regulatory decisions make it a near certainty that networked mobile devices such as phone and computers will have access to GPS information that allows them to know their physical location (outdoors) to within a few tens of meters. There is keen commercial interest in developing location dependent services based on this technology, such as advertising targeted to persons who are passing a nearby store. This is a wide open area: there are NO existing software and protocols to enable such services.

  3. How to solve the proxy-location problem using mobile code. Many, including myself, have proposed placing an intermediary on the path between a mobile host and a correspondent host. The motivation is that, because a mobile host moves, it may encounter varying network conditions during the lifetime of a single connection or session. (Examples of varying conditions include: different bandwidth; asymmetric versus symmetric bandwidth; different cost/payment models; different privacy assumptions; and vastly different error rates.) The idea is that the intermediary would be under control of the mobile host and would act on the mobile host's behalf to delay, suppress, or alter traffic to/from the mobile host, in response to the current network conditions that the mobile host is experiencing. This is an attractive idea but it has several drawbacks: (1) the intermediary is an extra point of failure; (2) either encrypted traffic is opaque to the intermediary thereby limiting the actions it can take, or else the encryption keys must be shared with the intermediary, creating a security hazard; and (3) passing traffic through the intermediary, assuming it is not mobile, probably results in sub-optimal routing most of the time.

    Making the intermediary itself mobile, written using ``mobile code'' might help to solve the final problem.

  4. More generally, it would be interesting to tackle all the abovementioned problems through development of a toolkit for ``intermediary technology.''

  5. Intermediaries are used in more than just mobile settings. There is a strong trend toward deploying transparent proxies or gateways for security (firewalls), to convert among differing protocols (e.g., WAP) to bridge among pre-existing networks, to transcode, and to perform Web caching and/or load balancing. There is also a trend toward tunneling for security (e.g., IPSec) and re-routing (e.g., Mobile IP). With so many gateways and tunnels, the original concept of the Internet comprising end-to-end IP connections between only two corresponding hosts -- with routing determined only by a single universal hop-minimizing routing algorithm -- may be obsolete. Does a ``Discrete Internet'' composed of ``pieces'' such as tunnels, subnetworks with gated entry, and proxies that should be able to see all packets of a particular connection require new architectural concepts?