hokey@plus5.UUCP (Hokey) (03/10/85)
The whole point of the mapping project is to fix things so individual mail administrators won't have to do anything to support the database. I don't want this to sound like a flame from left field, but I can't understand why the people in charge of the mapping project (Mark and Karen, at the top of the administrative heap, I believe) didn't run the maps through pathalias *before* posting the maps! The whole purpose of this second posting was to provide something cleaner than the first posting. The regional administrators should also have scrutinized the maps better. The local aliases should be removed. The bizzare weights should have been caught and fixed. (The map for usa.mo was a reposting of the original map; the corrected version I sent in was not posted, and the subsequent copy I sent to uucpmap was also never posted.) I was also amazed at the number of missing entries in the maps. My messages to the map folks regarding several of these oversights seem to have been ignored. I can't help but wonder if the maps were posted "as-is" just to "prove" to people that a flat namespace won't work. This doesn't make a lot of sense to me, because if the current administrators can't make these simple tables correct and complete, I don't know how anybody can expect the same bunch to make a domain space work. -- Hokey ..ihnp4!plus5!hokey 314-725-9492
dw@rocksvax.UUCP (Don Wegeng) (03/12/85)
In article <634@plus5.UUCP> hokey@plus5.UUCP (Hokey) writes: >...I can't >understand why the people in charge of the mapping project (Mark and >Karen, at the top of the administrative heap, I believe) didn't run >the maps through pathalias *before* posting the maps! The whole purpose >of this second posting was to provide something cleaner than the first >posting. The most optimal path to a site from all other sites is not unique. It will be different for every site. The uucp mapping project could not possibly generate a pathalias map for every site on the net. My current list contains over 3000 sites! Another thing to consider is that the network topology is in a constant state of flux; the path that is best today may not even work tomorrow. In order to maintain an accurate database of paths each site has to generate their own database, and update it at frequent intervals. /Don -- "Beware the Ides of March..." arpa: Wegeng.Henr@Xerox.ARPA uucp: {allegra,princeton,decvax!rochester,amd,sunybcs}!rocksvax!dw || ihnp4!tropix!ritcv!rocksvax!dw
gregbo@houxm.UUCP (Greg Skinner) (03/12/85)
It was always my belief that auto-routing mail mechanisms should work only on a
host-by-host basis, rather than on a network global basis, due to the fact that
the database required to store all that information is huge, and the data is
never in a constant state.
I pushed a long time ago for a mechanism (like pathalias, but not with whole
netwide databases) which did autorouting on a machine-by-machine basis. What
it would do is scan the From line for a host which it knew how to send to,
and optimize the path from there. For example, if I want to reply to a message
which came to houxm as ...
Path: houxm!allegra!bellcore!decvax!genrad!user
and I know how to speak directly to user, the return-path would be op-
timized to
To: genrad!user
Failing to find a friendly neighbor in the Path:, it would keep a local cache
of neighbors who are likely to know how to get the message to the originator.
In the previous example, were I unable to speak directly to genrad, I would
counsult my L.sys file for my neighbors, and consult for each of them the
likelihood that they will be able to pass the message along to genrad. I could
store the neighbor's neighbors in the cache, or assign numbers to them indi-
cating the level of optimization that they could do. An example of this would
be to assign 1 to something like ihnp4 (high connectivity), 2 to cbosgd (less
than ihnp4 but still pretty high). I think you get the point -- it works like
pathalias, but doesn't have to have ultimate connectivity, nor does it even
have to know about all machines in the network, just has to know something
about its neighbors. When you consider the value of pathalias to a site with
only one news/mail feed, it would be more reasonable to adopt this sort of
strategy. I was reading over Hokey's suggestion and it sounds somewhat like
mine, except he makes the claim that a backbone site can pass messages around
a "ring", so to speak -- I say that cheap routes can be found off the ring, if
adequate connectivity information can be supplied for an individual site's
uucp neighbors.
If you want the original I sent out a year and a half ago (that's when I first
joined USENET, although I've been an ARPAnaut for almost 5 years), let me
know and I'll send you a copy.
Also, let's keep this discussion in net.mail, ok?
--
... hey, we've gotta get out of this place,
there's got to be something better than this ...
Greg Skinner (gregbo)
{allegra,cbosgd,ihnp4}!houxm!gregbo
gregbo%houxm.uucp@harvard.arpalaura@utzoo.UUCP (Laura Creighton) (03/13/85)
The problem with Greg Skinner's mechanism (which is what I use) is that it soon becomes: send all mail through ihnp4...(which is a fairly good approximation of how I send mail to anyone.) As long as ihnp4 is happy with this arrangement, there appears to be no problem. However, if Gary Murakami gets run over by a cement truck tomorrow, I think that we will all be in for a rude surprise. Allegra used to be the mail capital of Bell Labs, but one day I got a note from Phil Karn asking me to stop sending so much stuff through allegra -- and to tell my friends to do the same. Arpa type connectivity is never going to work for Usenet, but I don't think that we can rely on ihnp4, decvax, decwrl, and ucbvax to provide free mail for an ever-increasing number of people. The first step in making their load easier is to move news to stargate, since there is a *lot* of news. But I fear this only postpones the inevitable. Think of this as the golden age of networks.... Laura Creighton utzoo!laura