Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/15/85; site fear.UUCP
Path: utzoo!linus!decvax!decwrl!amdcad!cae780!weitek!fear!robert
From: robert@fear.UUCP (Robert Plamondon)
Newsgroups: net.mail
Subject: Re: Mail overload and so-called "smart" mailers
Message-ID: <317@fear.UUCP>
Date: Tue, 7-Jan-86 15:27:53 EST
Article-I.D.: fear.317
Posted: Tue Jan  7 15:27:53 1986
Date-Received: Thu, 9-Jan-86 05:39:11 EST
References: <17623@styx.UUCP> <3080@sun.uucp> <313@fear.UUCP> <219@gould9.UUCP> <393@packard.UUCP>
Distribution: net
Organization: Weitek Corp. Sunnyvale Ca.
Lines: 56
Summary: Conflicting interests...

In article <393@packard.UUCP>, gjm@packard.UUCP (Gary J. Murakami) writes:

> 
> While some individuals may argue (somewhat justifiably) that routing
> (optimization) on ihnp4 is arbitrary, the decisions have been carefully
> weighed to try to provide the most benefit for both internal company use
> and for many friends and even competitors AT NO COST.

I never claimed that ihnp4's pathalias file was arbitrary, just that
it's inaccurate.  I agree with your reasons for setting it up the way
you did, by the way.  The idea of routing mail through a
"sacrificial" VAX with no users to spare the VAXen with users is a
good idea, if you can afford it.

But while I agree with both your motives and methods, I feel no
corresponding obligation to route my mail through ihnp4 and suffer
both low delivery speed and occaisional misrouting that this entails.

> Many people have
> expressed their gratitude via mail for the services provided by ihnp4,
> but some individuals appear to be ungrateful.

I'm appreciate the efforts of all the people who are maintaining and
paying for the net.  I thought that went without saying, but I guess
not.

> 	changes in pathalias costs also affect your neighbors.
> 
> An increase in ihnp4's pathalias costs would shift more burden to some
> of its neighbors.  We've cranked the data through pathalias before, and
> even the recent pathalias errors point to the drastic effect that can be
> caused by changes in input data.  We've seen many scenarios (e.g.
> allegra, cbosgd, packard, or topaz flooded, ucbvax bypassed).

I've run combinations, too. My results indicate that the shift would
be to other AT&T machines, and that this is largely an effect of
having very similar connectivity and path costs for these machines.
This suggests that you could downgrade ihnp4's numbers to reflect
reality, and then downgrade the other systems' numbers enough to
prevent them from being flooded.

Anyway, There are several ways to look at the problem.  I mostly
approach it from the perspective of a user trying to get mail safely
and quickly form one place to another.  When looking at things this
way, sites like ihnp4, with its unbelievable mail load, and dual
(which has been characterized as "well-connected, but the phones are
always busy") are more of a hazard than help.  I mean no slight on
the people running these sites -- but the fact is, mail moves through
them very slowly, and they are best avoided if you want your messages
delivered quickly.

-- 

		Robert Plamondon
		UUCP: {turtlevax, resonex, cae780}!weitek!robert
		FidoNet: 143/12 robert plamondon