lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (08/29/89)
[ Followups are in news.admin ... ] I was going to bring this up a while ago, but thought "it's not that big of a problem." The following posting made me change my mind. In article <1989Aug21.124002.11054@robohack.uucp> woods@robohack.UUCP (Greg A. Woods) writes: >#N robohack [ ... ] ># NOTE: I've used DEDICATED to mean those sites who's mail is ># delivered immediately, and DIRECT for those queued 'til the next ># uudemon.hour run. It seems to me that everyone has assigned their own arbitrary definitions to DIRECT, DEMAND, HOURLY, etc., that bear no relation to the definitions in the README file posted to comp.mail.maps. In particular, everyone seems to use DIRECT when in fact they should be using HOURLY. I recently scanned through the Canadian maps, and found this to be the case for about 85% of the sites I am familiar with. It turns out that the "well connected" sites (using Gene Spafford's definition) are the most likely to be guilty of this practise. The result is, I'm starting to see some sub-optimal paths being generated. Take the case where 'a' and 'b' both claim DIRECT connections to 'c', and 'mysite' consider 'a' and 'b' to be HOURLY links. There is a 50% chance that pathalias will generate a route through either of 'a' or 'b' on the way to 'c'. As it turns out, the b!c link is a truly DIRECT connection, whereas a!c is in fact an HOURLY call. You get the idea ... As if that's not bad enough, I now find that on demand local calls are now weighted as DEDICATED. Does that mean that my 9600bps dedicated line between atha and aunro is actually a LOCAL+FAST link? Think about it ... -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA CTIX-USERS has moved to: ctix-users[-request]@cs.AthabascaU.CA
kls@ditka.UUCP (Karl Swartz) (08/31/89)
In article <1059@aurora.AthabascaU.CA> lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) writes: >># NOTE: I've used DEDICATED to mean those sites who's mail is >># delivered immediately, and DIRECT for those queued 'til the next >># uudemon.hour run. >It seems to me that everyone has assigned their own arbitrary >definitions to DIRECT, DEMAND, HOURLY, etc., that bear no relation >to the definitions in the README file posted to comp.mail.maps. >It turns out that the "well connected" >sites (using Gene Spafford's definition) are the most likely to be >guilty of this practise. Perhaps the worst offender of all, in view of its number of links, is uunet. I posted something about this a while back; they list nearly all their links as DEMAND when in fact this bears very little resemblence to reality -- I know of several sites whose connections from uunet are listed as DEMAND yet they poll uunet once a night, at best. Rick Adams' reply: "DEMAND indicates a high quality, reliable path through which the receiving site wants to receive a lot of traffic." For nearly everybody else that I know of it indicates a reasonable degree of expediency, which certainly doesn't match a once-nightly poll. You'd think a site like uunet (and the other well-connected sites) would try to set a *good* example, not a bad one. Rick also said that sites are ALL (Rick's emphasis) told that they will be marked as DEMAND the request otherwise. For one thing, this is a really poor default, and for another, when I asked the postmasters of several sites that had recently gotten uunet links neither one of them had been told anything about map costs. As I said in my earlier article, I'm not trying to pick on uunet, but I think in this case they are very wrong. (Note to fellow map tinkerers: you can't get away with tossing a simple 'dead {uunet}' or 'adjust {uunet(EVENING)}' in your local pathalias input since most international links will then try to go thru obscure backdoor paths.) >As if that's not bad enough, I now find that on demand local calls >are now weighted as DEDICATED. Does that mean that my 9600bps dedicated >line between atha and aunro is actually a LOCAL+FAST link? I still use PC Pursuit for some connections. Since I don't use PC Pursuit for anything other than uucp perhaps I should mark all those links as DEDICATED. 8-) -- Karl Swartz |UUCP uunet!lll-winken!ames!hc!rt1!ditka!kls 1-505/667-7777 (work) |Internet kls@rt1.lanl.gov 1-505/672-3113 (home) |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
cme@cloud9.Stratus.COM (Carl Ellison) (09/05/89)
re. DEDICATED, DIRECT, HOURLY, POLLED, .... It sure does seem ad hoc. Has anyone considered enriching the format definition to include floating point numbers = the number of hours an incoming message could expect to wait before being handed on to the next machine? This could live alongside the current ad hoc English words until they die out. Meanwhile, the actual expected wait time could be measured on each machine and updated measurements provided with every map update -- or triggering a map update if there's a radical change. --Carl Ellison UUCP:: cme@cloud9.Stratus.COM SNail:: Stratus Computer; 55 Fairbanks Blvd.; Marlborough MA 01752 Disclaimer:: (of course)
sms@ficc.uu.net (Stanley M. Sutton) (09/06/89)
In article <7561@cloud9.Stratus.COM>, cme@cloud9.Stratus.COM (Carl Ellison) writes: > > re. DEDICATED, DIRECT, HOURLY, POLLED, .... > Has anyone considered enriching the format definition to include floating > point numbers = the number of hours an incoming message could expect to wait Why not just use minutes? Integers are easier to track than floating. However, the mean time for transfer may not be as useful as some of the terms, if they are consitently used. I.E., once a day would be a mean time of 720 minutes for random calls, but someone who called in 10 mins before the forward every day would only see a 10 min delay. When the software at the site caluclates the mean time, how should it do it? Worst case or calculated? -- Stanley M. Sutton, Service & Test, Ferranti International Controls Corp. uunet.uu.net!ficc!sms, sms@ficc.uu.net, bigtex!texbell!sugar!sms, sms@sugar.hackercorp.com, (713)274-5023, PO 5012, Sugarland, TX, 77487-5012 Opinions may not represent the policies of FICC or Service and Test.
jerry@olivey.olivetti.com (Jerry Aguirre) (09/07/89)
In article <6064@ficc.uu.net> sms@ficc.uu.net (Stanley M. Sutton) writes: >Why not just use minutes? Integers are easier to track than floating. >However, the mean time for transfer may not be as useful as some of the >terms, if they are consitently used. I.E., once a day would be a mean Here is an example of the source of the confusion. Some people are thinking of delays in terms of minutes while others are thinking in terms of seconds or less. Some think a connection should be DEDICATED if it can connect in less than one minute while others think that should be reserved for values less than one second. Without absolute values the terms are subject to individual interpretation. I propose that the "delays" encoded into the pathalias costs be specified. A "DIRECT" or "DEMAND" cost should indicate a connection setup time of about 20 seconds. A "DEDICATED" cost should indicate a setup time of less than 2 seconds. If the setup times were specified the people would be able to assign consistant costs.
cme@cloud9.Stratus.COM (Carl Ellison) (09/08/89)
In article <6064@ficc.uu.net>, sms@ficc.uu.net (Stanley M. Sutton) writes: > Why not just use minutes? Integers are easier to track than floating. Integers are OK, but you'd probably want 1 second resolution rather than minutes. I've seen some hops take only seconds according to the routing histories I've read. > However, the mean time for transfer may not be as useful as some of the > terms, if they are consitently used. You'll have a hard time convincing me of that. The words convey only the frequency of outgoing calls from which mean waiting time is inferred. Routing decisions care only about waiting time. The words are few and therefore, the quantification of waiting times is gross. If there's some reason to make measured waiting times more coarsely quantified, that can be done numerically. If a system administrator wants to lie about connectivity, s/he can do so as easily with numbers as with words. If the desire is to tell the truth, then a real measurement sure beats a numerical guess followed by a guess of a word to match the guessed number. --Carl Ellison UUCP:: cme@cloud9.Stratus.COM SNail:: Stratus Computer; 55 Fairbanks Blvd.; Marlborough MA 01752 Disclaimer:: (of course)
karl@ficc.uu.net (Karl Lehenbauer) (09/08/89)
In article <3872@ditka.UUCP>, kls@ditka.UUCP (Karl Swartz) writes: > Perhaps the worst offender of all, in view of its number of links, > is uunet. I posted something about this a while back; they list > nearly all their links as DEMAND when in fact this bears very > little resemblence to reality -- I know of several sites whose > connections from uunet are listed as DEMAND yet they poll uunet > once a night, at best. One thing about uunet trying to list all of its uucp neighbors with the same value, from fooling around with different values for the link between sugar and uunet and running them through pathalias, if the link is substantially downgraded, you end up generating routes to uunet that are not direct from your site to uunet. uunet could end up routing stuff to you indirectly as well, if they allow that condition to occur. (They will honor a site's request for a value other than DEMAND) Now you might say that's the way it should be, but for a subscriber service like uunet, it is desirable that their customers connect directly, hence paying their own way. -- -- uunet!ficc!karl "Have you debugged your wolf today?"
kls@ditka.UUCP (Karl Swartz) (09/10/89)
In article <47647@oliveb.olivetti.com> jerry@olivey.UUCP (Jerry Aguirre) writes: >In article <6064@ficc.uu.net> sms@ficc.uu.net (Stanley M. Sutton) writes: >>Why not just use minutes? Integers are easier to track than floating. >Some think a connection should be DEDICATED >if it can connect in less than one minute while others think that should >be reserved for values less than one second. Another part of the problem that I haven't seem mentioned is what happens if a line is busy. Let's say I talk to a local site that I call as soon as I have anything for it to do. By the books that's a DIRECT link. But what if their modem is busy? All of a sudden it's an HOURLY link. Some people adjust for this by using DIRECT+LOW or some similar adjustment for sites that are chronically difficult to reach, but that's still rough. The idea of having a link cost being the typical delay in seconds seems like a good, if still imperfect, solution, IMHO. Implementing it is another matter entirely. -- Karl Swartz |UUCP {ames,lll-winken}!pacbell!ditka!kls 1-505/672-3113 |Internet kls@rt1.lanl.gov |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
kls@ditka.UUCP (Karl Swartz) (09/10/89)
In article <6093@ficc.uu.net> karl@ficc.uu.net (Karl Lehenbauer) writes: >One thing about uunet trying to list all of its uucp neighbors with the same >value ... if the link is substantially >downgraded, you end up generating routes to uunet that are not direct from >your site to uunet. That makes perfect sense. It even makes *some* sense that the cost is fairly low, since folks with uunet connections probably want their mail to come that way instead of via backroads. The trouble is that it also affects paths to non-subscribers. I would certainly object if one of my neighbors had a uunet link, marked as DEMAND but only polled every night or so, and consequently caused a great deal of *my* mail to be delayed. The solution to this is simple: the default should be a term- inal link, e.g. uunet <subscriber>(DEMAND) The subscriber encourages mail via the uunet without causing any backup for neighbors for whom better paths really exist and who *want* those better paths to be used. -- Karl Swartz |UUCP {ames,lll-winken}!pacbell!ditka!kls 1-505/672-3113 |Internet kls@rt1.lanl.gov |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
brian@ucsd.Edu (Brian Kantor) (09/11/89)
I set my map costs by examining the monthly summary of uucp traffic and deriving the connection frequency based on actual usage. I fudge that with my knowledge of system problems, phone line outages, and some calling preferences we have, and finally season it with some adjustments based on link speed and system administration quality. - Brian
chip@ateng.com (Chip Salzenberg) (09/12/89)
According to kls@ditka.UUCP (Karl Swartz): >The solution to this is simple: the default should be a term- >inal link, e.g. > uunet <subscriber>(DEMAND) This would be a good solution, except that it doesn't work. If sites that have registered domain names -- like this one -- advertise a terminal link from uunet to the domain gateway, then only mail to the gateway will be delivered via that link. All mail to subdomains will go via some other route. Take us for example: uunet ateng(DEMAND) ateng .ateng.com Now mail to `user@border.ateng.com' is delivered via uunet. But if we do: uunet <ateng>(DEMAND) ateng .ateng.com then mail to `user@ateng.uucp' is delivered via uunet; but mail to `user@border.ateng.com' goes via Podunk. -- You may redistribute this article only to those who may freely do likewise. Chip Salzenberg at A T Engineering; <chip@ateng.com> or <uunet!ateng!chip> "If you push something hard enough, it will fall over." -- Fudd's First Law of Opposition
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (09/12/89)
This discussion is getting split. I've directed followups to news.admin. cme@cloud9.Stratus.COM (Carl Ellison) writes: >Has anyone considered enriching the format definition to include floating >point numbers = the number of hours an incoming message could expect to wait >before being handed on to the next machine? Why not integer minutes? Saves a new version of the software. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA CTIX-USERS has moved to: ctix-users[-request]@cs.AthabascaU.CA
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (09/12/89)
[ note followups are pointed at news.admin ] sms@ficc.uu.net (Stanley M. Sutton) writes: >However, the mean time for transfer may not be as useful as some of the >terms, if they are consitently used. I.E., once a day would be a mean >time of 720 minutes for random calls, but someone who called in 10 mins >before the forward every day would only see a 10 min delay. When the >software at the site caluclates the mean time, how should it do it? >Worst case or calculated? What you're publishing is the average time for YOUR site to deliver to the next hop. When someone else calls you isn't really under your control. (What if he misses that poll? Is it then a 70? or a 35? or a ...) There are scripts available that provide calculated map weightings based on the uucp log information. They could be converted to the new system easily enough. The question is: will this feedback into the map postings induce self-oscillation? [ Death of net predicted :-) ] -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA CTIX-USERS has moved to: ctix-users[-request]@cs.AthabascaU.CA
snoopy@sopwith.UUCP (Snoopy) (09/24/89)
In article <4122@ditka.UUCP> kls@ditka.UUCP (Karl Swartz) writes: | Another part of the problem that I haven't seem mentioned | is what happens if a line is busy. Let's say I talk to | a local site that I call as soon as I have anything for | it to do. By the books that's a DIRECT link. But what | if their modem is busy? All of a sudden it's an HOURLY | link. Obviously, one wants both the mean and the standard deviation. _____ .-----. /_____\ Snoopy ./ RIP \. /_______\ cse.ogc.edu!sopwith!snoopy | | |___| sun!nosun!qiclab!sopwith!snoopy | tekecs | |___| tektronix!tessi!illian!sopwith!snoopy |_________| "You made a woman meow?"