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
woods@robohack.uucp (Greg A. Woods) (08/29/89)
In article <1059@aurora.AthabascaU.CA> lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) writes: > [ Followups are in news.admin ... ] Which didn't work too well, I had to chop news.config from the Newsgroups line. :-) > 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. I nearly started a discussion on this topic a long while back (2 years or so) as well. > 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. Most of my connections are what one would philosophically call DEMAND. I guess with respect to the README, they are DIRECT. First off, my uucp polling scheme has no concept of hourly (in the bigger picture). Second, with respect to mail delivery, my system will attempt to punch through on a tight polling schedule once work is queued to go. For the best rated sites this is every 20 mins. Remember that with HDB, work cannot be queued till the next regular poll (without adjusting the time field in Systems), but is only queued until the next run of uusched. If you look at my map entry, you will find one site labeled HOURLY, and that's 'cause they call me at least once per hour except from 9 to 5, but do not accept calls. In order to fudge my paths generation, I want some sites to be a bit less than DEMAND. Perhaps DAILY/4 or EVENING/2 or something would have been closer. The problem turns out to be a conflict between both the real world and the README, and between the README and smail2.5. I suppose I could change the #define in smail such that mail will only be queued with a cost of HOURLY or more (i.e. >=500), but that would also be misleading. All in all, I have achieved the desired result in my own pathalias output, and that's what counts, no? :-) > 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 ... Of course this would be easy if we all used the same definitions. However, what I'm saying, both here, and by explicitly commenting upon my actions in my map entry, is that the definitions are no longer sufficient. They are also very misleading, unless you also read the numbers. In fact, if you use the definition of cost: "measured very roughly in elapsed time"; the costs I have defined in my map are more than likely very nearly right, if not pessimistic, except for adjustments made manually to keep the load down on certain links. There have always been sub-optimal paths generated from the map data, no matter where you are, unless you connect to 1/2 the known universe. -- Greg A. Woods woods@{robohack,gate,tmsoft,ontmoh,utgpu,gpu.utcs.Toronto.EDU,utorgpu.BITNET} +1-416-443-1734 [h] +1-416-595-5425 [w] Toronto, Ontario; CANADA
mason@tmsoft.uucp (Dave Mason) (08/29/89)
In article <1989Aug29.130347.10673@robohack.uucp> woods@robohack writes: >also be misleading. All in all, I have achieved the desired result in >my own pathalias output, and that's what counts, no? :-) Not sure exactly what the smiley is for here, but you should tune your Path.local file (or whatever) to get the pathalias output you want. Your published maps should reflect the real costs, downgraded perhaps to avoid paths you don't want the whole world to use. (I.e. if I did lots of work with Australia I might have: tmsoft munnari(DIRECT) in my Path.local file, but tmsoft munnari(HOURLY*2) in my published map entry, because I don't want all North American and European traffic siphoned off through my site, though I might be willing to carry a bit of local traffic bound that way). ../Dave (Disclaimer: I do not have any real or imagined link to munnari, so don't go & change your routing tables :-)
woods@eci386.uucp (Greg A. Woods) (08/31/89)
In article <1989Aug29.155304.2026@tmsoft.uucp> mason@tmsoft.UUCP (Dave Mason) writes: > In article <1989Aug29.130347.10673@robohack.uucp> woods@robohack writes: > >also be misleading. All in all, I have achieved the desired result in > >my own pathalias output, and that's what counts, no? :-) > > Not sure exactly what the smiley is for here, but you should tune your > Path.local file (or whatever) to get the pathalias output you want. > Your published maps should reflect the real costs, downgraded perhaps > to avoid paths you don't want the whole world to use. That's what I hope I've done, though I've used the numbers, not the names to describe the costs for my node. I don't want to have to make local adjustments to my own map entry. > (I.e. if I did lots of work with Australia I might have: > tmsoft munnari(DIRECT) > in my Path.local file, but > tmsoft munnari(HOURLY*2) > in my published map entry, because I don't want all North American and > European traffic siphoned off through my site, though I might be > willing to carry a bit of local traffic bound that way). In that case, I wouldn't even want my paths file to see the low cost link either in case someone was using me as a smart-host. I would use explicit bang routing if I wanted to use my own link without regard to cost. > (Disclaimer: I do not have any real or imagined link to munnari, so > don't go & change your routing tables :-) I should hope not, as that would screw up any local round-the-world backup schemes! -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft,gpu.utcs.UToronto.CA,utorgpu.BITNET} +1-416-443-1734 [h] +1-416-595-5425 [w] Toronto, Ontario CANADA