gam@amdahl.UUCP (G A Moffett) (07/04/85)
Some sites are sending their site configurations to cbosgd!uucpmap
using the ``DIRECT'' cost value for uucp connections that are not really
DIRECT (or DEDICATED) lines, but just ``very good'' DEMAND connections.
This causes a certain grief to their neighbor sites, who get the
misleading impression that going thru these ``DIRECT'' lines is better
than even the neighbor sites' ``DEMAND'' connection to the same site.
Because of this I have been forced to change some of my connection
cost values to neighboring sites from ``DEMAND'' to ``HOURLY'', or
resort to re-editing these ``DIRECT'' connections to ``DEMAND''.
There really isn't any need to have these cost bonuses for call-on-
demand links. If the connection is really good, DEMAND+HIGH
(or DEMAND+HIGH+HIGH) should be adequate.
--
Gordon A. Moffett ...!{ihnp4,cbosgd,sun}!amdahl!gamhoney@down.FUN (Peter Honeyman) (07/05/85)
pathalias lacks a distinction between local and long-distance calls. of late, DIRECT has been used to represent local calls. for what it's worth, this meets with my approval. something pathalias has never had is a clear criterion for optimality. for the most part, pathalias attempts to minimize delay, but there are other considerations, e.g., dollar cost, shunning ambiguous addresses, avoiding traversals through closed networks, etc., etc. anyone with the latest version (for instance, you, gordon) might peek at the heuristics in mapit.c. i get grossed out (and i wrote it!). peter
gam@amdahl.UUCP (G A Moffett) (07/05/85)
It has been brought to my attention that the meaning of DIRECT
is ``local call'' while DEMAND means ``long distance call''.
(This isn't very mnemonic....).
Even so, there are several instances of DIRECT connections
being used for non-local calls, which produces the same confusion
I noted in my previous article.
Meanwhile, you can change all your local, on-demand connections
to DIRECT, I guess.
--
Gordon A. Moffett ...!{ihnp4,cbosgd,sun}!amdahl!gamroy@phri.UUCP (Roy Smith) (07/05/85)
gam@amdahl (Gordon A. Moffett) says: > [...] using the ``DIRECT'' cost value [...] not really DIRECT (or > DEDICATED) lines, but just ``very good'' DEMAND connections. I take this to mean that other people are just as confused as I am about what the various costs mean. To quote the pathalias man page: DIRECT 200 (local call) DEMAND 300 (normal call) HOURLY 500 (hourly poll) EVENING 1800 (time restricted call) DAILY 5000 (daily poll) Can somebody who *really* knows what these are supposed to mean (i.e. one of the implementors) give some examples of situations that fall into the various catagories. To make this more concrete, this is how I came up with my path costs; did I do it right? Should the allegra and philabs costs be DEMAND and DEMAND+LOW? Is a long-distance call that you are willing to make any time of the day a "normal" call? Am I correct in assuming that LOCAL means on an Ethernet or similar LAN and DEDICATED means an RS-232 hard-wired connection between 2 machines in the same building (i.e. not a phone call)? phri timeinc(DIRECT), cubsvax(DIRECT), allegra(DIRECT+LOW), philabs(DIRECT+2*LOW), pesnta(EVENING) Timeinc, and cubsvax are in my area code. Once an hour, if I have traffic for them, I call them. In addition, every other hour I call whether or not I have any traffic for them. Allegra and philabs are both (relatively short) toll calls. I call them both hourly if I have traffic, once a day in the middle of the night regardless. The LOW penalty for allegra indicates the higher-cost phone call. The double LOW penalty for philabs is because we seem to have a bit more trouble with that link than we do with the others. Pesnta is way the hell in California. We will only call them in the middle of the night, and then only if we have traffic bound for them. -- allegra!phri!roy (Roy Smith) System Administrator, Public Health Research Institute
smb@ulysses.UUCP (Steven Bellovin) (07/11/85)
> gam@amdahl (Gordon A. Moffett) says: > > [...] using the ``DIRECT'' cost value [...] not really DIRECT (or > > DEDICATED) lines, but just ``very good'' DEMAND connections. > > I take this to mean that other people are just as confused as I > am about what the various costs mean. To quote the pathalias man page: > > DIRECT 200 (local call) > DEMAND 300 (normal call) > HOURLY 500 (hourly poll) > EVENING 1800 (time restricted call) > DAILY 5000 (daily poll) > > Can somebody who *really* knows what these are supposed to mean > (i.e. one of the implementors) give some examples of situations that > fall into the various catagories. Back when I wrote pathalias, DIRECT was intended to refer to a direct cable between the tty port on machine A that was connected to a tty port on machine B, where machine B was running a getty. That is, unless the target machine was down or someone was cu'd over this direct wire, the connection should *always* succeed. I rated this as better than demand-dialed, which could fail if the autodialer was busy, all ports on the target machine were busy, the phone system was in some strange state, etc. Given the rather strange phone system in Chapel Hill at the time (a long story I'll tell some other time) and the even stranger autodialer we were using (an even longer story I probably won't tell), plus the fact that one of our primary correspondent machines had only one dial-in line, all of these constraints were very real. So that's the official word on what DIRECT meant *then* -- Peter's probably right about using it for local calls today, though my original intention was to use something like DEMAND+3*HIGH or some such. I also agree with Peter that pathalias has never had a clearly-defined goal it was optimizing towards. The reason is quite simple: no two people could agree. I decided that the primary goal was to get mail through quickly and reliably, which in turn meant using observed frequencies of calling and reliability as the best indicator of (a) the willingness of someone to pay for forwarding mail and news; and (b) the willingness and ability of the system administrator to hold uucp's hand(sic) enough. I made up the initial numbers by defining an important subnet that I knew well (North Carolina plus major backbone sites plus a few hanging off of them), and playing with the values till I got paths that matched what I felt was optimal (given the definition cited above). The net is far larger now, with greater fanout but more sensitivity towards costs; my numbers may no longer be optimal, but I do suggest caution in adjusting them -- the output is very sensitive to minor perturbations in costs. --Steve Bellovin