jordan@ucbarpa.berkeley.edu (Jordan Hayes) (04/29/86)
Steve Campbell <steve@dartvax.uucp> writes:
It turns out that the pathalias "cost" of our link to Z is
greater than that of path A!B!C!Z, so the optimizer always
chooses A!B!C!Z. This effectively makes our link to Z useless,
which somehow doesn't seem right.
Change the cost of link Z ... if you don't want to tell the world to
use that route optimally, just use a private copy of your own map ...
it seems to me that if you have all your links (within reason) in your
private copy of your site be the same cost, your reasons for setting
up the link will be realized.
Disclaimer: your mileage may vary
/jordanchris@umcp-cs.UUCP (Chris Torek) (04/30/86)
In article <4509@dartvax.UUCP>, steve@dartvax.UUCP (Steve Campbell) writes: > We run a version of uumail. It optimizes uucp paths by starting > with the last (rightmost) host and working backwards until it finds > a host that our pathalias database knows how to reach. Aside: this is not really the right way to do this; it assumes that UUCP host names are unique, which is demonstratably false. A complete database (not that anyone will ever assemble one) would show what neighbors are required to turn a non-unique host name into a unique one (normally one suffices, of course). But back to the main point: > Among our uucp paths is [the pair {us!Z, us!A!B!C!Z}, where] the > pathalias "cost" of our link to Z is greater than that of path > A!B!C!Z, so the optimizer always chooses A!B!C!Z. This effectively > makes our link to Z useless, which somehow doesn't seem right. But it is right! Either that or the cost metrics you have are wrong. It is difficult to come up with reasonable cost values. Perhaps what is required is a `fuzziness' parameter for each cost: A!B!C!Z is usually 100, but sometimes as high as 1500 and sometimes as low as 10, with some particular statistical distribution; etc. Then the path resolver could toss random numbers to pick the `best' path. It might also (or instead) make sense to have the resolver keep a history of past resolutions, and/or be able to scan the mail queue(s), so that it could distribute the traffic. (Personally, I feel that we have already reached the so-called point of diminishing returns. But who knows---maybe someone else will feel it is worth the effort.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
mark@cbosgd.UUCP (Mark Horton) (04/30/86)
smail has a feature similar to what you describe. In sendmail.cf, it reads in L.sys and turns any mail to systems in L.sys into a direct request to go to that hop next. Thus, if sfmag is in L.sys and mcvax isn't, it will turn user@sfmag.uucp => smail sfmag!user user@mcvax.uucp => smail mcvax.uucp!user smail looks up the latter in the domain database, the former goes direct. This helps for local mail but not if you're trying to reoptimize paths of mail going through your machine. By the way, this feature bit me recently. cbosgd can't dial out (telco has broken our phone lines for the past 6 weeks) so most of L.sys is links to places we can't get to. I redid pathalias to go via datakit, but this overrode it for hosts in L.sys. Here are some related parts of our sendmail.cf: # Preemptive ether and UUCP connections. We prefer these connections # over both designated transport mechanisms and the general depository. FU/usr/lib/uucp/L.sys %s # Preemption: for a host on a known link turn the domain spec into a # mock domain indicating the link. One set of these rules for each of # the F classes listed in the local configuration options. R$*<$*$=U.$D>$* $:$1<$2$3.UUX>$4 uuxhost.mydomain R$*<$*$=U.$=D>$* $:$1<$2$3.UUX>$5 uuxhost.anydomain R$*<$*$=U.$A>$* $:$1<$2$3.UUX>$4 uuxhost.anotherdomain R$*<$*$=U.$=T>$* $:$1<$2$3.UUX>$5 uuxhost.mock-domain R$*<$*$=U>$* $:$1<$2$3.UUX>$4 uuxhost # Designated delivery: R$*<@$=U.UUX>$* $#uux$@$2$:$1$3 known uucphost
jer@peora.UUCP (J. Eric Roskos) (05/01/86)
> It turns out that the pathalias "cost" of our link to Z is greater than > that of path A!B!C!Z, so the optimizer always chooses A!B!C!Z. This > effectively makes our link to Z useless, which somehow doesn't seem right. Alas, this is really just a case where what "seems right" conflicts with what you've more formally defined to *be* right! if the cost of the link to Z is greater than the path of A!B!C!Z, then why wouldn't pathalias (which is really what's doing it) choose the "longer" path? Its optimization is based on the costs, not the number of sites. I find that people around here also comment on that occasionally... "how come the router generated a path with five sites in it when I know of one that has only three?" Because pathalias is trying to get the mail there while minimizing the "cost", where the cost is supposed to be (if you use the constants like LOCAL, DAILY, WEEKLY, etc) a function of how fast it gets there. If you tell pathalias that it's faster to send it the "long" way, then it will send it that way... the only inconsistency is in what intuitively seems to be the "right" path! If, in fact, it would have gotten there faster if you'd gone via the 1-hop path, then you should adjust the weights in the map. (Note that if it's high because your management or administration has a policy of trying to minimize outside traffic through the link -- which would certainly be reasonable if you had some convenient but expensive connection that was funded for some specific purpose other than the general mail -- you could publish a different weight in the published maps than what you use when you generate your pathalias database.) [I know someone will say "the `costs' are not that simple," since the semantics of the cost are sort of arbitrarily assigned -- for example some people may assign higher costs because it is more expensive to use a given link -- I realize that, the above is something of a simplification.] -- E. Roskos
avolio@decuac.UUCP (05/02/86)
We use smail instead of uumail. Smail allows you to set (in an
include file) whether you try to short-cut paths. As Chris pointed
out, this is pretty dangerous to do since hostnames are not unique.
Having said that, let me tell you that on this host, paths containing
hostnames of direct neighbors are shortened before going to smail.
This means I only shorten paths containing hosts immediately next to
us (in our L.sys file). This is done by sendmail.cf. While this is
bad, as Chris pointed out, I am only messing with some things -- not
all. And then the address is passed to smail which looks it up in the
pathalias database.
So...
host1!host2!host3!seismo!fuzzball!cbosgd!other!user becomes
cbosgd!other!user (even though we talk to seismo also) which gets
passed as is through smail (best path is direct to cbosgd from here).
While, host!otherhost!cvl!user goes as cvl!user to smail which makes
it umd5!cvl!user. We talk to cvl directly but only in the evening,
while we call umd5 any old time. Remember -- we are only being
`smart' about hosts in L.sys. It is a compromise.
--
Fred @ DEC Ultrix Applications Center
INET: avolio@decuac.DEC.COM UUCP: {decvax,seismo,cbosgd}!decuac!avoliohoney@down.FUN (Peter Honeyman) (05/02/86)
steve campbell at dartmouth describes pathalias behavior in which hosta!hostb!hostc!hostz is preferred to a direct link to hostz. this is not a bug. why is your cost to hostz so high? if it's because the link is slow, expensive, or unreliable, and the hosta, hostb, and hostc links are fast, cheap, and high quality, then isn't it better to avoid the direct link? peter
ds08393@iscuva.UUCP (David Schmidt) (05/02/86)
In article <4509@dartvax.UUCP> steve@dartvax.UUCP (Steve Campbell) writes: >It turns out that the pathalias "cost" of our link to Z is greater than >that of path A!B!C!Z, so the optimizer always chooses A!B!C!Z. This >effectively makes our link to Z useless, which somehow doesn't seem right. >It would be easy to hack uumail so that if in its right-to-left scan it >finds a host which is an immediate neighbor, it stops there and doesn't >even look in the database for a path. Any thoughts on this situation? It seems to me that the optimizer is working as intended. Either the costs are not accurate or the mail actually should go through A!B!C. If Z is actually cheaper than the data base should be changed. If you decide that you want to use Z anyway (maybe to avoid making A, B and C paying for your mail) than what is the harm in reducing the cost of the link to Z? ----- David Schmidt ISC Systems Corporation ihnp4!tektronix!reed!iscuva!davids Spokane, WA 99206 (509)927-5479
dave@uwvax.UUCP (Dave Cohrs) (05/02/86)
In article <4509@dartvax.UUCP>, steve@dartvax.UUCP (Steve Campbell) writes: > It would be easy to hack uumail so that if in its right-to-left scan it > finds a host which is an immediate neighbor, it stops there and doesn't > even look in the database for a path. Any thoughts on this situation? Using uwvax as an example, we have a number of immediate neightbors, some of which are very reliable, and some which only call us and really don't call very often, for example, ihnp4. Now, if a path optimizer here looked through 'seismo!ihnp4!action' and noticed "Hey, we talk to ihnp4, I'll queue it for them directly", it might never get there. That's why the cost in our map for ihnp4 is so high. If you want to force your optimizer to choose a direct connection, lower it's cost *locally* by adding an entry to your local pathalias input file. This way you can benefit from direct connections, without opening the floodgates wide. Disclaimer: we don't optimize paths -- this is purely hypothetical. -- Dave Cohrs (608) 262-1204 ...!{harvard,ihnp4,seismo,topaz}!uwvax!dave dave@rsch.wisc.edu
avolio@decuac.UUCP (05/04/86)
In article <2124@peora.UUCP>, jer@peora.UUCP (J. Eric Roskos) writes: > > It turns out that the pathalias "cost" of our link to Z is greater than > > that of path A!B!C!Z, so the optimizer always chooses A!B!C!Z. ... > ... Its optimization is based on the costs, not the number of sites. > ... Because pathalias is trying to get the mail there > while minimizing the "cost" And keep in mind that Real Networks do this automatically and dynamically. So, if a machine in a path from one machine to another goes down and alternate path is sought. In Real Networks, this is done without the user's knowledge (except that one might notice the speed being slower today than yesterday or some such thing). We worry about it (whether we should or not) because 1) we notice it -- have to give uucico a host to call and 2) because sometimes we use the wrong COST in our pathalias data. And so someone has to fix this by hand. Unforturnately these things may have to be fixed daily as systems go down for scheduled maintenance, etc. Things that are done automatically in Real Networks. On the other hand you can't beat the ease of setting up a UUCP connection! -- Fred @ DEC Ultrix Applications Center INET: avolio@decuac.DEC.COM UUCP: {decvax,seismo,cbosgd}!decuac!avolio
sob@soma.UUCP (Stan Barber) (05/05/86)
The easiest solution I can think of is to lower the cost to Z in your
uucpmap entry. Alternatively, if you are running sendmail, you can
use something like this to give priority to your directly connected sites.
FU/usr/lib/uucp/L.sys
# this will put the names of directly connected sites into the U macro
.... (skip to Ruleset 0 )
# deal with local uucp connections
R<@$=U.UUCP>:$+ $#uucp$@$1$:$2 route addr
R<@$=U>:$+ $#uucp$@$1$:$2 route addr
R$+<@$=U.UUCP> $#uucp$@$2$:$1 explicit domain
R$+<@$=U> $#uucp$@$2$:$1 known host
# deal with all others
R<@$-.UUCP>:$+ $#uumail$@$1$:$2 route addr
R<@$+>:$+ $#uumail$@$1$:$2 route addr
R$+<@$-.UUCP> $#uumail$@$2$:$1 explicit domain
R$+<@$+> $#uumail$@$2$:$1 known host
Have fun!
--
Stan uucp:{shell,rice,drillsys}!soma!sob Opinions expressed
Olan ARPA:sob@rice.arpa here are ONLY mine &
Barber CIS:71565,623 BBS:(713)660-9262 noone else's.henry@utzoo.UUCP (Henry Spencer) (05/06/86)
> ... Real Networks do this [routing] automatically and dynamically... > if a machine in a path from one machine to another goes down an alternate > path is sought. In Real Networks, this is done without the user's knowledge... > ...Unfortunately these things may have to be fixed daily... Things that > are done automatically in Real Networks. Clearly, then, a Real Network has to have connections live all the time so that it knows when machines go down. Do let us know when you are willing to finance such a network for us. Meanwhile, we will continue to use our unReal but still exceedingly cost-effective network. We will also continue to have a low opinion of people who think that there is something "unreal" about one of the largest networks in the world. -- Join STRAW: the Society To Henry Spencer @ U of Toronto Zoology Revile Ada Wholeheartedly {allegra,ihnp4,decvax,pyramid}!utzoo!henry
taylor@glasgow.glasgow.UUCP (Jem Taylor) (05/08/86)
In article <4509@dartvax.UUCP> steve@dartvax.UUCP (Steve Campbell) writes: >We run a version of uumail. It optimizes uucp paths by starting with the >last (rightmost) host and working backwards until it finds a host that >our pathalias database knows how to reach. It then substitutes its path >to that host for the remaining lefthand portion of the original address. > >It turns out that the pathalias "cost" of our link to Z is greater than >that of path A!B!C!Z, so the optimizer always chooses A!B!C!Z. This >effectively makes our link to Z useless, which somehow doesn't seem right. Sounds like the pathalias cost of A-Z is set up as too large. Two scenarios are possible: 1) A-Z is cheaper than A-B-C-Z fix: alter pathalias costs to reflect true cost. 2) A-Z is not cheaper than A-B-C-Z fix: save money by abandoning direct link. -Jem. JANET: taylor%glasgow.uucp@uk.ac.ed.cstvax -o Jemima UUCP: { uk }!cstvax!glasgow.uucp!taylor (==). Puddleduck -- JANET: taylor%glasgow.uucp@uk.ac.ed.cstvax -o Jemima UUCP: { uk }!cstvax!glasgow.uucp!taylor (==). Puddleduck
joel@gould9.UUCP (Joel West) (05/09/86)
In article <818@soma.UUCP>, sob@soma.UUCP (Stan Barber) writes: > The easiest solution I can think of is to lower the cost to Z in your > uucpmap entry. Alternatively, if you are running sendmail, you can > use something like this to give priority to your directly connected sites. > > FU/usr/lib/uucp/L.sys > # this will put the names of directly connected sites into the U macro I use this solution. It is better than pathalias fudges because then if the link goes down (or turns out to be as flakey as claimed) you can take it out again. I don't suggest using L.sys. The file should be derived from L.sys, but allow certain known sites not to be used (as in the flakey case). -- Joel West (619) 457-9681 CACI, Inc. Federal, 3344 N. Torrey Pines Ct., La Jolla, CA 92037 {cbosgd, ihnp4, sdcsvax, ucla-cs} !gould9!joel joel%gould9.uucp@NOSC.ARPA