🚀 go-pugleaf

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