jdd (12/09/82)
Let's consider ways to improve the engineering of the Usenet. Here's one. As we have all seen, news can take an awfully long time to get from one side of the net to the other. This can (help to) cause such unpleasant features as a dozen broadcast responses to the same query, followed by two dozen broadcast flames about the duplication. Increasing the speed with which messages percolate through the network would increase its usability. Usenet has grown up in a distributed fashion, with sites mostly adding themselves to locally convenient places in the net without considering the global topology of the net. This results in a semi-random topology, which we can improve on for the purpose of, say, improving its speed. I've done a simple study to try to understand the topology of the Usenet. All my information comes from the Hortons' 12/1/82 map (hopelessly obsolete by now, of course). This study considers only the pure topology, ignoring different speeds or frequencies of connections; it is also slightly simplistic about the resolution of multiple routing. And now, the results. The farthest corners of the Usenet are (in decreasing order of remoteness): az70, kpno ecn-ed, pucc-i, pur-phy, uiuceml avsdF, avsdS, avsdT princeton win The longest paths through the Usenet are: > >From az70 or kpno: arizona!gi!sytek!zehntel!teklabs!ucbcad!ucbvax!decvax! harpo!ihps3!stolaf!minn-ua!pur-ee!ecn-pa!ecn-pb! ecn-ed! arizona!gi!sytek!zehntel!teklabs!ucbcad!ucbvax!decvax! harpo!ihps3!stolaf!minn-ua!pur-ee!purdue!pucc-h! pucc-i! arizona!gi!sytek!zehntel!teklabs!ucbcad!ucbvax!decvax! harpo!ihps3!stolaf!minn-ua!pur-ee!purdue!pucc-h! pur-phy! arizona!gi!sytek!zehntel!teklabs!ucbcad!ucbvax!decvax! harpo!ihps3!stolaf!minn-ua!pur-ee!uiucdcs! uicsovax!uiuceml! > >From ecn-ed: ecn-pb!ecn-pa!pur-ee!inuxc!ixn5c!ihps3!harpo!decvax! ucbvax!ucbcad!teklabs!zehntel!sytek!gi!arizona! (az70|kpno)! > >From pucc-i: pucc-h!purdue!pur-ee!inuxc!ixn5c!ihps3!harpo!decvax! ucbvax!ucbcad!teklabs!zehntel!sytek!gi!arizona! (az70|kpno)! From: pur-phy pucc-h!purdue!pur-ee!inuxc!ixn5c!ihps3!harpo!decvax! ucbvax!ucbcad!teklabs!zehntel!sytek!gi!arizona! (az70|kpno)! > >From uiuceml: uicsovax!uiucdcs!pur-ee!inuxc!ixn5c!ihps3!harpo!decvax! ucbvax!ucbcad!teklabs!zehntel!sytek!gi!arizona! These are all 16-hop paths. The most central machine on the net is decvax (at most 8 hops to anywhere, which is why 16 hops will get you from anywhere to anywhere). A second center is ucbvax (at most 9 hops to anywhere, a property shared with decvax's other immediate neighbors, although ucbvax can do a lot of this without going through decvax). Now: what next? Well, if we were to try to remedy the particular problems shown above by adding links between, say, arizona and pur-ee (to make a simple and undoubtedly nonoptimal choice), the furthest corners would become: avsdF, avsdS, avsdT princeton ecn-ed pucc-i, pur-phy, uiuceml win hlexa uofm-cv psi The longest path would now be 15 hops. There would now be a three-way tie between decvax, duke and harpo for most central site, each at most 8 hops from anywhere. Keeping in mind the limitations of these particular results, I think that it suggests that a lot can be done with this sort of approach. I would welcome discussion on this topic. Cheers, John DeTreville Bell Labs, Murray Hill
mclure (03/09/83)
#R:allegra:-67400:sri-unix:8200007:000:320 sri-unix!mclure Dec 9 03:34:00 1982 The obvious problem with this, of course, is that cross-country phone calls are expensive and transferring kilobytes per day, even at 1200 baud will run up a large phone bill which many people are unwilling to pay, especially if they feel that Usenet is more of a convenience than a necessity (heaven forbid!). Stuart