From: shearerje_at_comcast.net
Date: Sat Jan 31 2004 - 12:51:57 PST
“Experience with Grapevine: The Growth of a Distributed System” (Schroeder et al, 1984) is presented as a technical assessment of an in-use distributed mail system. However, a closer look shows it is really an assessment of the human factors that inevitably drive such a system. The developers designed the network topology around geographic considerations but found that organizational and human nature considerations were at least as important because they drive much of the routing and loading.
The experience of the use of distribution lists, for example, differed significantly from the developers’ expectations. The system was designed to be extensible on the assumption that the quantity of lists would grow with the user base, but not the size of the lists. It soon became apparent that some frequently used lists (today we would call them company or internal Spam) grow with the network size and cause major congestion. Further, organizations are often split geographically (even more today than when the paper was written in 1984) so their distribution lists need to be managed in a geography-independent way.
Human factors also enters into the goal of making the system behave like a single central post-office, masking from the user the effects of multiple network hops across possibly slow and/or unreliable links. Grapevine was mostly successful at this, but the developers also have some ideas on how to make it better. For example, binding a registrar to a single registry server for the duration of a session rather than allowing writing to one and reading from another would reduce the incidence of propagation delay artifacts.
Continuing on the subject of replication issues, the developers found several hard problems associated with deleting mailboxes, entries on distribution lists, and whole servers because delays in replication of the knowledge of the deletion cause very strange behaviors such as massive remailing events.
Human nature became a factor both with the users and the administrators of the system. When things went wrong, the users wanted to know the details of the problem even though they themselves could not do anything about it. It just makes the user feel better to know. On the other hand, server administrators do not want to be required to understand the internals of Grapevine, they just want to keep their particular server running. Grapevine was provided with utilities that allowed a remote Grapevine expert to perform systemic or Grapevine-specific maintenance so that site administrators did not need to know. One effect was that the Grapevine experts occasionally had to prod the site administrators to let them know that their server was down.
The human element is often underestimated in system design, but the Grapevine experience demonstrates that it can make the difference between a technically good design and a truly successful design.
This archive was generated by hypermail 2.1.6 : Sat Jan 31 2004 - 12:52:04 PST