[comp.mail.misc] How not to list a network gateway in the maps

sverre@fesk.UUCP (Sverre Froyen) (12/12/87)

After posting the message about the broken bitnet gateway at
super, I got a number of replies asking why I did not simply
use the gateway at psuvax1.  Why indeed.  The reason was, of
course,  that pathalias generated the path from the recently
posted uucp maps.  Still it seemed strange  that  it  should
prefer           a          long          path          like
"boulder!hao!husc6!harvard!gymble!super!%s" rather than  the
shorter  path,  "boulder!hao!rutgers!psuvax1!%s".   A little
studying of the map files revealed the reason:  Super  gives
the  cost  of  the bitnet link as DIRECT whereas psuvax does
not give a cost.  No cost  is  equivalent  to  4000,  rather
higher  than the DIRECT cost of 200, and certainly more than
enough to offset the  (slightly)  higher  cost  of  reaching
super  compared  to  psuvax1.   When I then learned that all
super does, is forward the mail  to  psuvax1,  it  made  the
automatic routing somewhat meaningless.

In conclusion:  (1) Don't list a gateway unless  you  run  a
true,  honest  to god gateway.  And (2), if you list a gate-
way, don't associate a  cost  with  the  gateway.   (Perhaps
pathalias should be modified to ignore gateway costs).

				Sverre
-- 
Sverre Froyen
UUCP:   boulder!fesk!sverre, sunpeaks!seri!fesk!sverre
ARPA:   froyen@nmfecc.arpa
BITNET: froyen@csugold.bitnet

nsadmin@egg-id.UUCP (Linn Hower) (12/13/87)

> A little
> studying of the map files revealed the reason:  Super  gives
> the  cost  of  the bitnet link as DIRECT whereas psuvax does
> not give a cost.  No cost  is  equivalent  to  4000,  rather
> higher  than the DIRECT cost of 200, and certainly more than


> In conclusion:  (1) Don't list a gateway unless  you  run  a
> true,  honest  to god gateway.  And (2), if you list a gate-
> way, don't associate a  cost  with  the  gateway.   (Perhaps
> pathalias should be modified to ignore gateway costs).
> 
> 				Sverre
> -- 
> Sverre Froyen

  I also had bitnet mail bounce and tracked down this same problem.
However I don't agree with the above conclusion.  If I am providing
a gateway service on a single computation node, its `cost' is very
low, approaching zero depending on my cpu horsepower.  Why don't
we use pathalias's input for what its designed for?  Why have a special
case for gateways?  I feel the input from the d.Top file should reflect
the true cost of gatewaying.

  ( I am not arguing the error in super's entry.  Its pretty screwed up.)

--
  Linn
-- 
Linn Hower	usenet@INEL.GOV		Phone: 208-526-9353
		usenet%INEL.GOV@uiucuxc.ARPA

matt@ncr-sd.SanDiego.NCR.COM (Matt Costello) (12/15/87)

In article <567@egg-id.UUCP> nsadmin@egg-id.UUCP (Linn Hower) writes:
>  I also had bitnet mail bounce and tracked down this same problem.
>However I don't agree with the above conclusion.  If I am providing
>a gateway service on a single computation node, its `cost' is very
>low, approaching zero depending on my cpu horsepower.  Why don't
>we use pathalias's input for what its designed for?  Why have a special
>case for gateways?  I feel the input from the d.Top file should reflect
>the true cost of gatewaying.

The definition of gateways should almost always use the default pathalias
cost of 4000.  Even though a gateway is defined as a link (to pathalias)
its real cost is always 0 because that machine IS the gateway.  While the
published maps stick to the default cost for domain gateways I'll be able
to locally override these costs for specific cases.  Right now, for example,
relay.cs.net is listed within NCR as a gateway to bitnet with a cost of 95;
This was done to override super's incorrect map entry.  Our gateway to .MIL
is a nearby machine actually on the MILNET.

Please people, don't put everything out into the USENET map files.  These
files are supposed to be getting smaller as domain mailers become more
common.  I've got systems that are sometimes unable to use the full USENET
database because the user process size limit is only 1 MB.
-- 
Matt Costello	<matt.costello@SanDiego.NCR.COM>
+1 619 485 2926	<matt.costello%SanDiego.NCR.COM@Relay.CS.NET>
		{sdcsvax,cbosgd,pyramid,nosc.ARPA}!ncr-sd!matt