From: James.Kistler@cs.cmu.edu
Newsgroups: comp.os.research
Subject: Re: CODA
Date: 6 Oct 1992 02:28:43 GMT
Organization: University of California, Santa Cruz
NNTP-Posting-Host: ftp.cse.ucsc.edu
Originator: osr@ftp

> Excerpts from netnews.comp.os.research: 3-Oct-92 CODA Eric
> Kolotyluk@cs.sfu.ca (1966)

> Efforts in the CODA project at CMU have recently come to my attention
> as both a graduate student and as a systems manager,.. As such, I have
> a number of (hopefully not too naive) questions...

> 1. CODA seems to deal well with the issues of `connected' vs
> `disconnected'
>    operation.  There seems to be, however, a more continuous relationship
>    between `connected' and `disconnected' status in distributed file
> systems:
>    At one end of the spectrum 0 may represent totally disconnected
> status,
>    and any value > 0 might represent the bandwidth between the client
> apppli-
>    cation.  For example, those of us on an ethernet, `n' might be
> 10,000,000.,
>    but for those of use at the other end of a V.32bis modem n might =
> 14,400.

>    The point is, for those of us with portable and remote computers, can
> we
>    `expect' a ditributed file system in the future that can `adapt' to
> our
>    prefered live-styles (10BASE-x, 100-DDI, x.32bis, ISDN, SMDS, ATDM,
> etc).

>    Examples: I disconnect my `system' from the network, but later
> reconnnect 
>    over a lower bandwidth link: how is re-integration and hording
> handled?
>    I work at the office over a 10,000,00 or 100,000,000 bps link, and
> over a
>    64.000 bps  or 128,000 link: will it do `what I want?'

I agree with your basic assesment that ``connected'' and
``disconnected'' are only two possible states in a broad spectrum. 
Disconnected state is certainly one endpoint, but the definition of
connected state varies according to the underlying technology of your
network.

Characterizing connectivity by bandwidth is a good start, but is
incomplete in my view.  I think you need to consider at least three
dimensions:  bandwidth, latency, stability.  (Stability refers vaguely
to the reliability of the network:  how frequently does a network
terminal's view transition between working/not-working.  Think about
wireless networks to understand this one.)

So far, Coda has addressed only distinctions and transitions between
disconnected and ``well-connected'' states (you gotta start somewhere). 
The next step is to consider cases where either ``not-well-connected''
is the norm, or where fallback to an inferior channel is possible when a
primary channel fails (e.g., switching to a 9.6kbaud cellular modem when
the ethernet goes down).  We are referring to these modes of operation
as ``weakly-connected.'' Another Coda student, Lily Mummert, is
investigating weak-connectivity as part of her thesis work.  As you
suggest, having the system ``do what you want'' may well mean different
things under different connectivity scenarios.  Lily will be tackling
this sort of issue in her work.  You may want to contact her directly
(lily@cs.cmu.edu) to exchange ideas and find out what she's up to.


> For those of your who don't yet know about CODA: way cool!

Thanks for the plug!  We're hoping that our thesis committees find it
way cool too ;-).  By the way, the best reference for disconnected
operation in Coda is:  Kistler and Satyanarayanan, ``Disconnected
Operation in the Coda File System,"  ACM Transactions on Computers, Feb.
1992.


Jay Kistler (jjk@cs.cmu.edu)
School of Computer Science
Carnegie Mellon University
Pittsburgh, PA  15213