Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!munnari.oz.au!manuel!cmf851 From: cmf851@anu.oz.au (Albert Langer) Newsgroups: comp.society.development Subject: Re: How Usenet grew (Was Re: Low-cost Usenet (Re: usenet in Nepal) Message-ID: <1991Jun21.215004.24276@newshost.anu.edu.au> Date: 21 Jun 91 21:50:04 GMT References: <1991Jun15.023819.5589@newshost.anu.edu.au> <1991Jun18.065605.6955@zorch.SF-Bay.ORG> <1991Jun19.055256.14960@cbnewsh.att.com> Sender: news@newshost.anu.edu.au Organization: Computer Services Centre, Australian National University, Canberra, Australia. Lines: 143 Thanks for the historical background Bill, in article <1991Jun19.055256.14960@cbnewsh.att.com> wcs@cbnewsh.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs) Maybe I'm prejudiced but I see most of the history as confirming my earlier assertion that the Usenet design is heavily influenced by the environment it grew up in (research/academic) and in particular that extending far beyond that environment, especially to developing countries, needs to focus on providing the network management and systems administration. Technology trends since Usenet started have continued to be in the direction of declining costs for everything, with disk space and CPU power continuing to decline much faster than communications bandwidth (and all these declining relative to sysadmin labor). The early architecture was based on terminals hanging of multi-user computers (sometimes even using X.25 networks to connect the terminals to a central mainframe). That no longer makes sense and a modern architecure should make use of both the CPU power and mass storage capacity commonly available on desktop computers, treating each user as a network node rather than as a user of a much smaller number of network nodes. Traffic can be expected to continue growing exponentially or faster and filtering is a major issue. Classification into "newsgroups" (with cross-posting) and further selection at the newsreader level through kill files is already becoming inadequate. Multi-media, groupware and other extensions beyond simple email and news text are becoming important. (However for developing country purposes the prime focus should be on cheap and reliable email and news while keeping the future extensions in mind.) Flooding algorithms and other inefficiencies that have resulted from lack of centralized network administration are luxuries that developing countries are unlikely to be able to afford. But neither can they afford the overheads and delays of establishing central bureaucracies or waiting for the existing PTT administrations to take on the job. Going through some specific points in your article: >There have been some experiments with satellite broadcast, >including the Stargate project run by Usenix in the mid-1980s, >which used spare broadcost capability on a major cable-tv system. >The distribution technology was relatively inexpensive, >and satellite dishes have since become much cheaper and more common. Seems to me this should be kept under review as DBS continues to become cheaper (I've even seen ads for using alfoil tape on window blinds to pickup TV broadcasts in Europe using fresnel patterns, and 9600 baud SCPC satellite receivers are available as PC cards for less than high speed modems). But modems on the PSTN will still be needed for the uplink and most aspects of the system can be designed without much reference to what the actual communications carrier will be (even carrier pigeons with floppy disks). Let's focus on designing the email and news system rather than the communications carrier. >ECONOMICS >--------- >I've alluded to some of the economic issues above, and I won't say much more. >Some fundamental issues are that >1) If it's easy and cheap to connect, decentralized decision-making > lets lots of people connect and the network grows fast. Requirement 1. Must be easy and cheap to connect (and to use). >1A) If somebody implements a good-enough system, and gives it away "free", > lots of people will take it, like Usenet or Prodigy. Requirement 2. Give away "freely available" software. >2) If it's easy and cheap to add traffic to an existing network, > without getting much permission, people will. Requirement 3. Exploit any available opportunities to add traffic easily and cheaply to existing email and news networks such as Usenet e.g. by providing transparent gateways. Requirement 4. Provide adequate metering and accounting facilities, both for gateways to other systems and internally so that: a) It is easy for people to offer and use available communications links without bureaucratic overheads keeping accounts and arranging permissions. (e.g. Clarinet's Dynafeed software to automatically add and remove groups when users subscribe to them, without "operator" involvement, but with associated logging and charging for traffic). b) (Also a security related requirement). People offering access to communications links need not fear them being abused or ending up paying other peoples bills. Note: A full development of these requirements could be critical if the inefficiencies of duplicated traffic, use of low speed and expensive links when a high speed modem is available at another site, inability to provide a high speed modem or leased line or satellite broadcast individually when costs would be reduced for all if it was provided collectively etc etc are to be avoided. Design should also avoid the costs and other difficulties of a bureaucratic organization to administer the accounting etc. This requirement is itself a consequence of requirement 1 for cheap and easy connection and use, and of requirement 5 below. >3) If you have to wait for the government telephone company to decide >something, you may have to wait a long time. Requirement 5. Don't rely on any single source of sponsorship. If funds are needed for development, seek them widely, perhaps including commercial uses. (May require careful reconciliation with requirement 2 for "freely available" software.) >4) Network management is a relatively difficult, and systems work > much better if someone does it, especially if they can make money. > The problem is how to do this in a decentralized environment > (UUNET did it well.) Requirement 6. Provide all network management for the decentralized network. Design the architecture from the ground up with this problem in mind since there may be NO local "sysadmins". (Tough one, focus on it). >5) If your system is sucessful, traffic will grow far beyond your plans. > It will probably grow far beyond your ability to manage it. > If you're managing it centrally this is a problem. Requirement 7. Design architecture to cope with massively larger traffic than currently contemplated. Especially consider filtering issues. These of course are just notes about requirements, not properly analysed and measurable requirements ready to hand over to specification and design. My point is we should be thinking now in terms of developing a requirements statement. -- Opinions disclaimed (Authoritative answer from opinion server) Header reply address wrong. Use cmf851@csc2.anu.edu.au