jc@minya.UUCP (John Chambers) (11/24/88)
For several days, my main newsfeed has been disabled, and due to rerouting by other machines, I have been unable to send messages along paths that should have worked. I consider this an object lesson in why rerouting is not a good idea in general. Note that I'm not objecting to routing, just rerouting. That is, if I submit some mail to foo@bar.dom.ain, I expect that mailers will figure out a route for me. But if I send mail to x.uucp!y.bitnet!bar!foo, I prefer that the mailers deliver it along exactly that route, or bounce it back to me. Oh, yes, my example. For several days now, all calls to my main newsfeed (adelie) have failed with the following in the uucp log file: | mail adelie (11/23-4:36:16,6064,0) SUCCEEDED (call to adelie ) | mail adelie (11/23-4:36:21,6064,0) HANDSHAKE FAILED (REMOTE HAS A LCK FILE FOR ME) | mail adelie (11/23-6:36:09,6111,0) SUCCEEDED (call to adelie ) | mail adelie (11/23-6:36:16,6111,0) HANDSHAKE FAILED (REMOTE HAS A LCK FILE FOR ME) | mail adelie (11/23-7:39:14,6136,0) SUCCEEDED (call to adelie ) | mail adelie (11/23-7:39:19,6136,0) HANDSHAKE FAILED (REMOTE HAS A LCK FILE FOR ME) It appears that uucico aborted without freeing the lockfile, and adelie doesn't have one of the recent (hdb) uucps that delete the lockfile if its creating process has died. So until the administrator cleans up, or uucp's garbage collector gets to it, the minya!adelie link is dead. I'd like to send mail to the administrator to tell him about it. Obviously, I can't send mail to adelie!postmaster. I do have several other neighbors, and the uucp maps show several alternative paths. I've tried sending mail along several of them, but you might guess what happens. Right. Each path includes a "smart" mailer that decides it knows a better path--going back here and across minya!adelie. Sigh. Changing the network maps isn't appropriate. The problem will clear up as soon as the lockfile goes away. In fact, I ran my "uunudge" script just before typing "postnews", and while typing this article, a call got through successfully, and the modem's RXD light is lit up solid. So the problem has just now fixed itself. But for several days, the link was down, and alternative paths all failed due to smart re-routing. Dumb mailers would have gotten the job done right. The way I like to think of this is that it's a debugging problem. Routing is fine for "normal" situations. But when things aren't normal, and the software is screwed up somehow, it isn't often correct to depend on the failing software to correct the problem. It's failing, after all. The job of debugging almost always depends on using various backdoors, spies, and out-of-band data paths to poke around in the systems innards. The major use of explicit mail paths is to diagnose and correct mail problems. A few years ago, they worked just fine for uucp. Now they don't. If we can't use them, then we won't generally be able to make email work right. The last few years of widespread smart mailers have provided us with a long list of examples, which my mailer has just extended by one. BTW, I find my "uunudge" script to be a useful debugging tool. What it does is hunt down and remove all the locks and status files blocking a given uucp link, and then starts up a "uucico -r1 -s$1" to force a call. It usually clears up any congestion caused by problems on this end. What would be really handy would be if it were installed at each of my neighbors sites, and I could say something like (uux "x!y!adelie!uunudge 'minya'"). This would have cleared up the problem without my having to contact adelie's administrator (who has better ways to spend his time than babysitting uucp, and anyhow, it's a holiday here in the USA). Unfortunately, with all the various variants of uucp around, I don't know if I could write a general, portable version of this script. Anyone interested in trying to make this a generally-available remote command? -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]
matt@oddjob.uchicago.edu (Matt Crawford) (11/26/88)
Here's my opinion on uucp path-munching, which may be no better than anyone else's opinion. If pass-through mail has a fully-qualified domain name in the destination bang path, as rutgers!mimsy.umd.edu!elsewhere!eddie.mit.edu!somewhere!user has, then the mailer takes shortcut to the rightmost fully-qualified name. Otherwise it either delivers to the first node on the path, if it is a neighbor, or bounces it if it is not. To the return-path on outgoing mail, I prepend "oddjob!" if there already is a fully-qualified name in the path or "oddjob!oddjob.uchicago.edu!" if there isn't. This seems to work quite well. Matt
lear@NET.BIO.NET (Eliot Lear) (11/26/88)
I don't understand why you didn't contact the site administrator doing the rerouting and tell him that your link was down. -- Eliot Lear [lear@net.bio.net]
vixie@bacchus.pa.dec.com (vixie) (11/26/88)
Another victim of the active rerouters. Sigh. You have my sympathy, but it seems that the decision has been made and since no facts were taken into account originally, I don't see that announcing more facts now is going to change anything. People reroute because they want to, and it seems to give them endless pleasure to see other folks complain about it. There's an ambiguity in your article; I'd like to resolve it: # Note that I'm not objecting to routing, just rerouting. That is, if I # submit some mail to foo@bar.dom.ain, I expect that mailers will figure # out a route for me. But if I send mail to x.uucp!y.bitnet!bar!foo, I # prefer that the mailers deliver it along exactly that route, or bounce # it back to me. I feel that x.uucp is justified in trying to find a route to y.bitnet, but that if y.bitnet (really: the "next hop") is not reachable via routing, the message should be returned. Under no circumstances should a site peek ahead (to "bar", in this example). Well, maybe as matt@oddjob suggests, one could peek ahead to fully qualified domains. But even that I'd tend to argue against (anybody want to? I doubt it...). This is the distinction between "routing" and "rerouting" -- no peeking. One more thing: could you tell me who those neighbors were? The ones that rerouted and sent the fixit request back toward you? I am building a list of rerouters that those who care about such things will be able to mark as "dead" when they build their paths database. The rerouting sites themselves seem largely to want to remain undiscovered, though one of them finally did send me a list of sites. Anyway, anyone who runs or knows of a site who peeks, please send me mail so that my paths database can avoid it. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
chip@ateng.ateng.com (Chip Salzenberg) (11/27/88)
According to lear@NET.BIO.NET (Eliot Lear): >I don't understand why [John Chambers] didn't contact the site >administrator doing the rerouting and tell him that [his] link was down. Step back and take a deep breath, Eliot; and think again. If the site in question hadn't been an active rerouter, there would have been no need to contact anyone. And no problem. Active routing loses. Why is this so *hard* for some people to understand?! -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.
werner@utastro.UUCP (Werner Uhrig) (11/27/88)
Subject: Why everyone, and especially Postmasters, should have 2 addresses. Summary: was Re: Another example why not to re-route > For several days, my main newsfeed has been disabled, and due to rerouting > by other machines, I have been unable to send messages along paths that > should have worked. I consider this an object lesson in why rerouting > is not a good idea in general. picking up the phone and calling might well be the "obvious" solution ... ...still, John's story of not being able to raise a Postmaster of a site with mail-problems reminds me to, once again, ask that every author of a map-entry include, at least, one alternate and reasonably independent email-address on some other machine, if at all possible (and to check the alternate mailbox(es) for mail !!!) In the research community it is quite common to exchange guest-accounts with "neighboring" site-admins; and while at commercial sites this might not be quite that easy to arrange, it should be easy enough to make an agreement with the admin of a net-neighbor to be named as alternate recipient in the map-entry of your site, and to relay any messages by phone or print-out - if all else fails .... An account on a Public Access or Commercial site, even if long-distance, may well be THE easiest/simplest solution for most ... It's too bad that even those of us with several mail-addresses to offer mostly fail to indicate this in the .signature-file ... -----------------> PREFERED-RETURN-ADDRESS-FOLLOWS <--------------------- (ARPA) werner@rascal.ics.utexas.edu (Internet: 128.83.144.1) (INTERNET) werner%rascal.ics.utexas.edu@cs.utexas.edu (UUCP) ..!utastro!werner or ..!uunet!rascal.ics.utexas.edu!werner -- --------------------> PREFERED-RETURN-ADDRESS-FOLLOWS <--------------------- (ARPA) werner@rascal.ics.utexas.edu (Internet: 128.83.144.1) (INTERNET) werner%rascal.ics.utexas.edu@cs.utexas.edu (UUCP) ..!utastro!werner or ..!uunet!rascal.ics.utexas.edu!werner
rsalz@bbn.com (Rich Salz) (11/28/88)
:For several days, my main newsfeed has been disabled, and due to rerouting :by other machines, I have been unable to send messages along paths that :should have worked. I consider this an object lesson in why rerouting :is not a good idea in general. Unh, err, did you try using your phone without a modem attached? I mean, like, calling? All map entries have contact information, and if you don't keep the maps on-line, you should at least have a name and phone number for everyone listed in your L.sys (Systems) file... /rich $alz -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
romkey@asylum.sf.ca.us (John Romkey) (11/28/88)
I've also been screwed by active rerouting more times than I want to think about. I KNOW what I'm doing when I send a message with a contorted path, and I sometimes send them to test the path, or see what headers I get back. Having an active rerouter in the path makes it impossible for me to test certain routes. There are also still some sites with duplicate site names that aren't registered - for instance, uworld (Unix World) seems to talk to a system called sirius, but it's not the one in the maps. Yes, this is a bad idea, but it's a situation that exists, and I SHOULD still be able to explicitly route a message there. If there's an active rerouter in the path, like my neighbor bionet, I lose. Given these problems, I'm very opposed to active rerouting. If there were a way to force certain messages through, I'd be less opposed to it (perhaps a header field, "X-REROUTE: NO", which the rerouting mailer saw), but there's not. -- - john romkey romkey@asylum.uucp romkey@xx.lcs.mit.edu romkey@asylum.sf.ca.us Find the cost of freedom, buried in the ground Mother Earth will swallow you, lay your body down.
dg@lakart.UUCP (David Goodenough) (11/29/88)
I can maybe understand WHY some sites will actively re-route. (I am not saying
I am in favour of it or against it, merely why it may be happening). Take
as an example the path Mr. Vixie's posting took to reach lakart from decwrl:
lakart!cfisun!ima!spdcc!bloom-beacon!husc6!purdue!decwrl!vixie
as opposed to the "optimal" path from lakart to decwrl:
lakart!xait!garp!decvax!decwrl!vixie
Now, if I'm footing the bill for transferring this information, which path
do you think I'm going to use. From the point of view of people who spend
quite a bit of money moving other people's mail around, they want to shorten
up paths as much as possible to save their (& other sites) costs. At least
that is one possible hypothesis. As to whether they are acheiving anything
(vis a vis lost mail bouncing around uucp land) I cannot comment upon that.
One suggestion would be to post to news.config saying:
dead {adelie!minya}
dead {minya!adelie}
And when the maps get updated your problem goes away. (For those that are
interested, and for the personal edification of Mr. Albery at ncoast) I am
currently working on a pathalias version that is A: runnable on (maybe)
a big PC, (i.e. 8086, 640K), and B: admittedly somewhat slower than
the regular pathalias (the data conversion alone takes over 10 mins
on lakart, against a straight 7 mins for running pathalias). However once
it is posted I will personally flame out of existance anyone who complains
that they can't afford to update their maps at least once a week. (PDP/11
users excepted - I don't think I can fit it in 64K)
You have been warned :-)
--
dg@lakart.UUCP - David Goodenough +---+
| +-+-+
....... !harvard!xait!lakart!dg +-+-+ |
AKA: dg%lakart.uucp@harvard.harvard.edu +---+vixie@decwrl.dec.com (Paul A Vixie) (11/29/88)
[Romkey] # Given these problems, I'm very opposed to active rerouting. If there # were a way to force certain messages through, I'd be less opposed to # it (perhaps a header field, "X-REROUTE: NO", which the rerouting # mailer saw), but there's not. John, I agree with everything you say here, and I hope someone among the rerouters will try to answer you. I don't promise not to toast them, but I do promise to be gentler about it than I was last time. One problem with this final suggestion of yours: rerouting _must not_ be the default case. A header that said "X-REROUTE: YES" with the default for all sites being "NO" would be fine. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
dtynan@sultra.UUCP (Der Tynan) (11/30/88)
Just a quick thought on the psychology of active-rerouting...
It seems to me, that there are two kinds of rerouters;
a) "That's a pretty poor way to route it, I can do better than that"
b) "Hmm. I don't want to use that link unless I have to"
As for the first case, this is fairly obnoxious, and should be discouraged
at all costs. On the other hand, I can think of fairly valid reasons for
rerouting in the second case. For example, a site connects to UUNET at
300 baud (yeuch!). It also connects to a big machine on the Internet by
local call. In the maps, the site would penalize the UUNET connection.
All mail to UUNET would be through the big neighbour. However, if someone
wants to cost this particular site a lot of money, they could hand-route a
whole pile of large mail directly to UUNET. The 'active' rerouter in this
case, would simply insert an extra component in the bang-path, which
redirected the mail to the Internet site. Comments?
- Der
--
dtynan@zorba.Tynan.COM (Dermot Tynan @ Tynan Computers)
{apple,mips,pyramid,uunet}!Tynan.COM!dtynan
--- If the Law is for the People, then why do we need Lawyers? ---vixie@decwrl.dec.com (Paul A Vixie) (11/30/88)
[Goodenough] # Take as an example the path Mr. Vixie's posting took to reach # lakart from decwrl: # # lakart!cfisun!ima!spdcc!bloom-beacon!husc6!purdue!decwrl!vixie # # as opposed to the "optimal" path from lakart to decwrl: # # lakart!xait!garp!decvax!decwrl!vixie # # Now, if I'm footing the bill for transferring this information, which path # do you think I'm going to use. From the point of view of people who spend # quite a bit of money moving other people's mail around, they want to shorten # up paths as much as possible to save their (& other sites) costs. In various past articles I have answered this. Basically, you should NOT be using a netnews Path: line to send mail. At one point I went so far as to recommend that the character chosen to separate the hostnames in the "Path:" line be changed to something other than a "!" since it looked so much like a UUCP path that it was confusing a lot of people. It is NOT a UUCP path and if you send mail along a "Path:" and it works, you are lucky. In times past there have been many "news only" links. I think I might make my home machine into a netnews hub for my area and not run mail on it, just to get lots and lots of articles into the bitstream that cannot be replied to via the "Path:" line. This is in the spirit of "making things worse so they'll get better," though, and it's a sad victory if it works at all. There is NO REASON to use a "Path:" line to mail a reply to an author. If you want to run a full pathalias-based auto-router, you can get smail and uuhosts and pathalias from a comp.sources.unix archive -- they're all free. If you want to run a smail with no local database, you don't need pathalias or uuhosts, you just use a "smart-host" in your paths file. All your out- bound traffic that you don't know the full route for will go to some smart neighbor or near-neighbor. Quoting myself: # There is no problem solved by re-routing that cannot be solved otherwise; # there are problems CAUSED by re-routing that cannot be solved at all. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
matt@oddjob.uchicago.edu (Matt Crawford) (12/01/88)
More opinion: Anyone who even attempts to use the news-path as a mail address should question their own sanity. Anyone who attempts to have their news system preserve the validity of the news-path as a mail address should receive a pat on the head and a kick in the pants. Matt Crawford
gmp@rayssd.ray.com (Gregory M. Paris) (12/01/88)
In an article vixie@decwrl.dec.com (Paul A Vixie) writes: > In various past articles I have answered this. Basically, you should NOT Long ago I put Mr. Vixie in my KILL file for comp.mail.uucp because he seems to post incessantly on this one topic: Do not reroute. I'm not sure how many times we have to suffer the diatribe, but now I see it's begun to infect this group too. Please folks, if you want to argue this until the cows come home, feel free, but please do it in the appropriate group, comp.mail.uucp. Even better, create a new group, talk.reroute, and bash each other there. Thank you. Now to add to my KILL file... -- Greg Paris <gmp@rayssd.ray.com> {decuac,garp,gatech,necntc,spdcc,sun,uiucdcs,ukma}!rayssd!gmp I find your lack of faith disturbing. [Lord Vader]
dtynan@sultra.UUCP (Der Tynan) (12/01/88)
In article <VIXIE.88Nov29011054@bacchus.pa.dec.com>, vixie@decwrl.dec.com (Paul A Vixie) writes: > [Romkey] > # Given these problems, I'm very opposed to active rerouting. If there > # were a way to force certain messages through, I'd be less opposed to > # it (perhaps a header field, "X-REROUTE: NO", which the rerouting > # mailer saw), but there's not. > > the default case. A header that said "X-REROUTE: YES" with the default > > Paul Vixie I suggested in the past (and yes, I suggesting it again), that instead of a special purpose header, we use something like: X-OPTIONS: REROUTE. This way, other options could be added without having to change the basic RFC822. Speaking of which, I don't think that the X- should be in front, because if you put that there, people will ignore it. If, on the other hand, you put it as part of '822, then everyone has to sit up and take notice. I mean, the basic idea behind X-ANYTHING, is that the mailer software will ignore it. That's really not what we want. Another example, someone asked me recently, to mail them a copy of a program (>33K in length). Guess what. 'ames' bounced it back to me, complete with a little note about a bad path. It would be great if there was another option something like; OPTIONS: NOBOUNCE which meant that the bouncing site just returned the header. Comments? - Der -- dtynan@zorba.Tynan.COM (Dermot Tynan @ Tynan Computers) {apple,mips,pyramid,uunet}!Tynan.COM!dtynan --- If the Law is for the People, then why do we need Lawyers? ---
chip@ateng.ateng.com (Chip Salzenberg) (12/02/88)
According to dtynan@sultra.UUCP (Der Tynan): >It seems to me, that there are two kinds of rerouters; > a) "That's a pretty poor way to route it, I can do better than that" > b) "Hmm. I don't want to use that link unless I have to" These already have names: a) Active routing b) Passive routing >As for the first case, this is fairly obnoxious, and should be discouraged >at all costs. On the other hand, I can think of fairly valid reasons for >rerouting in the second case. Quite. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.
dg@lakart.UUCP (David Goodenough) (12/02/88)
From article <989@tank.uchicago.edu>, by matt@oddjob.uchicago.edu (Matt Crawford): > More opinion: > > Anyone who even attempts to use the news-path as a mail address should > question their own sanity. For us who know better, Mr. Crawford's comments hold up. But even I have sent E-mail using a news path in the days before I knew better. Just today, I received mail from New Jersey (lakart is in Mass) that went from Jersey to Ohio to Mass to California to Indiana to California to Mass to me. I just wonder how much that letter cost to reach me - I estimate it travelled 12000 miles across 20 sites before reaching me, from a site that is no more than 400 miles away. > Anyone who attempts to have their news system preserve the validity of > the news-path as a mail address should receive a pat on the head and a > kick in the pants. > Matt Crawford We know better, but THERE ARE STILL IDIOTS OUT THERE WHO WILL TRY IT. I agree that totally agressive rerouting is not clever, but I ask comments on the (re-)routing done here. (N.B. lakart has four neighbours: cfisun, xait, mirror and pallio) Step 1. if lakart appears "further down" the path, ditch the intervening portion: xait!harvard!adelie!cfisun!lakart!mirror!..... becomes: mirror!..... Step 2. if any of my immediate neighbours appear further down, then ditch the intervening portion: xait!harvard!adelie!cfisun!ima!.... becomes: cfisun!ima!.... OK SO FAR. (?) THIS IS THE IMPORTANT STEP vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv >>>>>>>>IF I CAN REACH THE FIRST HOP, SEND IT THERE.<<<<<<<< ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If I can't (and here is where Mr Vixie & others will disagree) find the LAST hop I can get to, and send it there with the tail intact: snarf!harvard!foo!portal!blurf!decwrl!hiccup!user becomes: xait!garp!decvax!decwrl!hiccup!user For people who say I should route from the other end (i.e. try to find a route to snarf, if that fails try for harvard etc.) I ask the following. In either case I have to add some routing information (either to harvard to decwrl) from my local idea of what the maps look like. THESE TWO ROUTES ARE EQUALLY LIKELY TO BE INCORRECT, so what is the advantage of sending to harvard as opposed to decwrl. In both cases, since I've rerouted, I may have introduced an error into the route. As an aside, if my route to decwrl IS bad, but the site (say garp) that "can't" do the uucp (i.e. garp!decvax is down) applies this same methodology the message will get thru, AS LONG AS THEY APPLY THE "IF I CAN GET IT TO A NEIGHBOUR, DON'T MESS WITH IT" bit. N.B. Just in case the message DOES start looping (e.g. garp thinks the cheapest way to decwrl is thru lakart, with a broken path out of here) I keep a check on message ID's for all letters passing thru, on the fourth time of seeing, they are returned to sender, along the reply path that came in originally. i.e. the data file looks like: XX00010030@pallio.UUCP 1 pallio!dg where the 1 is the count of times I've seen the message. Note that if the message path was garp!harvard!xait!lakart!cfisun!..... (which will be cfisun!..... by the time I see it) then I'm not going to mess with it, because I can just give it to cfisun and let them send it on, hence the risk of "looping" is almost nil. The point of this system is that a valid (even if hand-crafted) path is left alone, which is basically what everyone is screaming about, but it still allows me to use lakart as a router for pallio. This I have to do, because I can't ever see fitting pathalias onto a CP/M machine :-). Of course, as soon as we all follow killer's lead, and lakart becomes lakart.boston.ma.us, and pallio becomes pallio.lakart.boston.ma.us then bang paths become a thing of the past. Now if someone could tell me how to do this ..... -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@harvard.harvard.edu +---+
vixie@decwrl.dec.com (Paul A Vixie) (12/02/88)
[Tynan] # b) "Hmm. I don't want to use that link unless I have to" Simplest solution to this is: don't advertise the path in your map entry. # However, if someone wants to cost this particular site a lot of money, they # could hand-route a whole pile of large mail directly to UUNET. If they knew about the unadvertised link, and if they had dark intentions. If and when this ever happened, I think an active response is better than the passive response of rerouting. Active in what way? Yelling, screaming, complaining, pulling links, public flamage, etc. This assumes that sending the person private e-mail doesn't work. It gets pretty far fetched, but even this contrived example doesn't make a case for limited rerouting. I rerouted "decwrl!ucbvax!foobar.berkeley.edu!user" into the more direct "user@foobar.berkeley.edu" because ucbvax is a Vax 750 and it can route packets more easily than it can route mail messages. I didn't want to advertise decwrl as a domain server to the .berkeley.edu domain, but in fact _any_ directly connected Internet host could be considered such since Berkeley allows external IP traffic to all machines on its internal net. _That_ is an example of limited rerouting to address a specific need. It wasn't a single individual, noone had any dark intentions, and noone came up with a way to tell the world that "decwrl!foobar.berkeley.edu!user" would work without bogusly registering "decwrl .berkeley.edu". -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
john@jetson.UPMA.MD.US (John Owens) (12/02/88)
In article <2692@sultra.UUCP>, dtynan@sultra.UUCP (Der Tynan) writes: > Just a quick thought on the psychology of active-rerouting... > It seems to me, that there are two kinds of rerouters; > a) "That's a pretty poor way to route it, I can do better than that" > b) "Hmm. I don't want to use that link unless I have to" Ah, but only the first is what we've been calling active rerouting, while the second, which deals only with the *next* link in the path, is what we've been calling "routing", and which most of us have agreed is just fine. To use the terms Paul (I think) introduced recently: the first involves "peeking"; the second doesn't, so it's ok (and isn't "active rerouting"). So, I certainly agree with your conclusion that the first is obnoxious and the second quite reasonable.... -- John Owens john@jetson.UPMA.MD.US uunet!jetson!john +1 301 249 6000 john%jetson.uucp@uunet.uu.net
roy@phri.UUCP (Roy Smith) (12/03/88)
dtynan@sultra.UUCP (Der Tynan) writes: > It would be great if there was another option something like; > OPTIONS: NOBOUNCE > which meant that the bouncing site just returned the header. Absolutely a great idea. A few years ago somebody around here decided to get rn running. I told him to get the source on tape but the turkey decided to go ahead and have somebody halfway across the country email it to him. Well, the other turkey (the guy who mailed it) got our turkey's name wrong so we, of course, bounced the whole friggin' 800 kbytes of it. To make life worse, when it got to the other end, the site that sent it was down for a a few days so the return mail eventually timed out in somebody's uucp queue and came back to us again. Bad enough we paid to mail 800 kbytes in the first place, we also paid to bounce it around the country another two times! I don't remember the details of the path, but it included allegra!ihnp4. I'm sure allegra!mp remembers this one. I think he said that when he did the uucp stats for that month, lowly little phri showed up at the top of the list for non-AT&T sites. Had the various mailers involved only bounce the headers instead of the whole files, a lot of money would have been saved all around. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"
cik@l.cc.purdue.edu (Herman Rubin) (12/03/88)
In article <989@tank.uchicago.edu>, matt@oddjob.uchicago.edu (Matt Crawford) writes: > More opinion: > > Anyone who even attempts to use the news-path as a mail address should > question their own sanity. > > Anyone who attempts to have their news system preserve the validity of > the news-path as a mail address should receive a pat on the head and a > kick in the pants. I have sent mail to reply to many news articles. Due to a local situation, I frequently have to edit the address. Even with this, the MAILER-DAEMON frequently barfs it back. What I try then, and sometimes even try first, is the tail of the news path. Surprisingly, this often works. If it doesn't, and I consider it important enough, and I cannot find an address somewhere else, I consult the systems people. That doesn't alway work, either. Considering that I have been able to reach people by using the news-path to get a mail address more easily than by other means, I resent Matt's attack on my sanity. I know enough to leave out parts of the path, but I cannot see the use of a full news-path by a less experienced user of email as insane. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)
pcg@aber-cs.UUCP (Piercarlo Grandi) (12/04/88)
In article <360@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: N.B. Just in case the message DOES start looping (e.g. garp thinks the cheapest way to decwrl is thru lakart, with a broken path out of here) I keep a check on message ID's for all letters passing thru, on the fourth time of seeing, they are returned to sender, along the reply path that came in originally. i.e. the data file looks like: XX00010030@pallio.UUCP 1 pallio!dg where the 1 is the count of times I've seen the message. The problem with dynamic routing (because rerouting, peeking, or what else you call this hideous sin :-> is dynamic adaptive routing) is that it requires a cooperative, distributed adaptive routing algorithm, just like old ARPAnet. And devising one that fits the UUCP mould is not easy. And having it adopted by everybody is even less easy. As all rerouters always say: "if only we kept up to date maps everywhere" (read: distributed routing database maintenance in realtime), and "if only we had a good algorithm to avoid loops, losses, etc..." (read: distributed dynamic adaptive routing with local knowledge). To make dynamic routing possible you have to have a way to ensure that all sites have the same software, all sites cooperate in the distributed updating of the routing database, all sites cooperate in running the distributed adaptive routing algorithm. This may be possible on the internet (maybe :->). It cannot be done, by definition, on USENET, which is a loose band of independent sites. In article <360@lakart.UUCP> dg@lakart.UUCP (David Goodenough) also writes: Of course, as soon as we all follow killer's lead, and lakart becomes lakart.boston.ma.us, and pallio becomes pallio.lakart.boston.ma.us then bang paths become a thing of the past. Now if someone could tell me how to do this ..... This is again the old, tired confusion, apparent in another part of your article as well, between names and routes. First of all, domainization, I will repeat here for the NTH time, is only a way to help have unique names, and, even in its limited purpose, requires some central administration. Thank goodness this is lightweight enough that USENET can live with it. Domainization can also be extended to imply name service where b.a is the holder of the map for *.b.a, and route service where b.a is the gateway to *.b.a; note that often both choices are appallingly inefficient, as proximity in the domain space does not imply any proximity in the connectivity space. A bang path, and this is something that very few people realize, is BOTH a NAMING device and a ROUTING device. It is NOT JUST A ROUTING DEVICE. In particular, since host names need not be unique, a given host is named by a bang path, not by the host name alone. It is just a coincidence that a bang path can be also used as a route, just as it is a coincidence that a domain name can be used as a route. Given this, your rules of clipping a bang path if you find your site name or one of your neighbours' in the path are quite wrong, because there might be MANY sites with the same host name. What would you do with a message reaching you with a further path like "uunet!enea!lakart!carlsson"? In other words bang paths are just like unix filesystem paths, but there is no root. Domain based names at least have a root (well, approximately) and therefore ambiguities cannot exist. Note that in a sense domain based names are paths, paths in the name space, just like bang names are; if one assumes that the connectivity space is shaped like the name space, both may be used as routes, The differences between domain and bang paths are first that the former have a tree shaped namespace (arguably a DAG shaped namespace, but many frown at allowing this), the latter are paths through an arbitrary unrooted graph, and second that normally domain paths are good for naming and bad for routing, and bang paths viceversa. routespace paths, and bang paths viceversa. The complete solution is: use domain names for unique identification of hosts, use bang paths for routing, do generate bang routes at the source, statically, do not do dynamic routing (unless among consenting sites that can be relied upon to maintain among them consistent distributed map databases and distributed adaptive routing algorithms, i.e. within the internet), and do not rely on domain names to locate map servers or to do routing. -- Piercarlo "Peter" Grandi INET: pcg@cs.aber.ac.uk Sw.Eng. Group, Dept. of Computer Science UUCP: ...!mcvax!ukc!aber-cs!pcg UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)
dtynan@sultra.UUCP (Der Tynan) (12/06/88)
Here's some more food for thought. I received a message from a site over the
weekend, which had the following path:
From: uunet!pyramid!mips!original-site!root
What's so interesting about this? My machine talks directly to pyramid.
However, pyramid sent the mail to uunet instead. OK, that's not too fatal,
a common mistake. But Wait! There's More! My machine ALSO talks directly
to mips! The only thing I can surmise is that the original-site hand-routed
the message. However, I don't think it would have been a henious sin on the
part of mips (or pyramid) to dump the rest of the path, and drop the mail onto
my site directly. Comments?
- Der
--
dtynan@zorba.Tynan.COM (Dermot Tynan @ Tynan Computers)
{apple,mips,pyramid,uunet}!Tynan.COM!dtynan
--- If the Law is for the People, then why do we need Lawyers? ---dg@lakart.UUCP (David Goodenough) (12/06/88)
From article <321@aber-cs.UUCP>, by pcg@aber-cs.UUCP (Piercarlo Grandi): > The problem with dynamic routing (because rerouting, peeking, or what > else you call this hideous sin :-> Didn't you read the rest of my article? AGAIN I SAY: IF I CANT REACH THE FIRST HOP, I'LL PEEK, AND JUSTIFY IT THUSLY: I've got to go to my maps WHETHER I GO FOR THE FIRST SITE OR THE LAST. HENCE WHICHEVER SITE I CHOSE TO AIM FOR, IF IT'S PATH FROM HERE IS WRONG I'M DEAD. SO I MIGHT AS WELL BE DEAD "efficiently" Or to put it another way, peeking in the case when I can't get to the next site is not making the situation worse, because: THE SITUATION DIDN'T "GET BAD" WHEN I PEEKED, IT GOT BAD WHEN I WAS FORCED TO ROUTE, Because the "errors" creep in not when I decide which site I'm going to shoot for, but when I decide how to get there. The problem with agressive re-routers (i.e. those that peek when they don't have to) is that they can break a good path. I'm not breaking a good path BECAUSE THE PATH I WAS GIVEN WAS ALREADY BAD. On the subject of duplicate names, I say the following. Duplicate names will die out "genetically", because as I have said in mail to a couple, take an example like edsel on the west coast. I tried mailing them, got re-routed, and bounced from edsel in New Jersey (the real one). My reaction was pity for the sysadmin of west coast edsel that he (or she) didn't have the smarts to pick a unique sitename. I just wonder how much more lost mail it's going to take before the message gets home. Whether people care to admit it or not, .uucp is becoming a domain (albeit an unofficial one) Look at my signature for proof (last line in particular). >>>>>>>>>>>>>> SARCASM ON <<<<<<<<<<<<<< Yeah sure, we don't have a nameserver (let's leave harvard.harvard.edu out of the equation for a while) Yeah sure, we don't have a central authority. But an increasing number of people know how to deal with .uucp sites and anarchy is better than no form of government at all. >>>>>>>>>>>>>> SARCASM OFF <<<<<<<<<<<<<<< -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@harvard.harvard.edu +---+
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (12/10/88)
>> It would be great if there was another option something like; >> OPTIONS: NOBOUNCE >> which meant that the bouncing site just returned the header. > > Absolutely a great idea. A few years ago somebody around here In the mean time, you can just bounce the first 100 lines (or whatever) of the message. Small messages are complete, large ones are clipped. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Support ISO 8859/1 zeeff%b-tech.uucp@umix.cc.umich.edu Ann Arbor, MI umix!b-tech!zeeff
john@jetson.UPMA.MD.US (John Owens) (12/13/88)
In article <370@lakart.UUCP>, dg@lakart.UUCP (David Goodenough) writes: > IF I CANT REACH THE FIRST HOP, I'LL PEEK, AND JUSTIFY IT THUSLY: > > I've got to go to my maps WHETHER I GO FOR THE FIRST SITE OR THE LAST. > > HENCE WHICHEVER SITE I CHOSE TO AIM FOR, IF IT'S PATH FROM HERE IS > WRONG I'M DEAD. No, you're still missing the essential point. In the path a!b!c!d you can't be sure that the "c" known to "b" is the same "c" as is in your maps. You are, however, justified in looking for "a" in your maps, because the path you!a!b!c!d wants the "a" that "you" know, the "b" that "a" knows, the "c" that "b" knows, etc. As a practical example, I've received a couple of failed mail messages intended for a site named "jetson" in West Germany. The failure message was sent from (if I remember correctly) ifistg!MAILER-DAEMON to unido!somewhere!jetson!user Someone, perhaps unido, did "peeking" and sent it to the jetson in the maps (me), causing two transatlantic crossings (one for the original failure message and one for my failure message back to the MAILER-DAEMON). If no one had "peeked", it would have gone to "somewhere", which would have sent it to its "jetson", and everything would have been fine (and cheaper). -- John Owens john@jetson.UPMA.MD.US uunet!jetson!john +1 301 249 6000 john%jetson.uucp@uunet.uu.net
vixie@decwrl.dec.com (Paul A Vixie) (12/14/88)
[Owens] # As a practical example, I've received a couple of failed mail messages # intended for a site named "jetson" in West Germany. The failure # message was sent from (if I remember correctly) # ifistg!MAILER-DAEMON # to # unido!somewhere!jetson!user # Someone, perhaps unido, did "peeking" and sent it to the jetson in the # maps (me), causing two transatlantic crossings (one for the original # failure message and one for my failure message back to the # MAILER-DAEMON). Unido's policy is to reroute based on the facts that (a) they have to pay lots of money for the transatlanctic crossings -- and in fact they charge this back to other German sites, and (b) the German namespace is totally controlled and there can be no duplicate host names. Though why they reroute things bound for non-German sites and send them to other non-German sites, I cannot fathom. <pcsbst!jkh> was trying to send mail to <unido!uunet!vixie!smegma!mdg> for a while, but since unido insisted on sending it to <uunet!ames!uport!smegma!mdg> and because <uport!smegma!> was down and <uport!portmaster> was brain dead, we finally solved it by changing <smegma> to <noe> and creating <pctbst!pyramid!>. I have a message for those of you who think you know a better route. But I cannot repeat it in polite company. If the postmaster of unido would like to speak to me in person, I will be in Germany from 16-December to 5-January; send mail to <pcsbst!jkh> to arrange an appointment. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
jep@fantasci.UUCP (Joseph E Poplawski) (12/16/88)
In article <2696@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes: >In article <VIXIE.88Nov29011054@bacchus.pa.dec.com>, vixie@decwrl.dec.com (Paul A Vixie) writes: >> >> the default case. A header that said "X-REROUTE: YES" with the default > >I suggested in the past (and yes, I suggesting it again), that instead of a >special purpose header, we use something like: X-OPTIONS: REROUTE. This >way, other options could be added without having to change the basic RFC822. .. .. >path. It would be great if there was another option something like; > OPTIONS: NOBOUNCE I think the X-REROUTE: or OPTIONS: field should have reroute defaulted as YES so that novices who don't know what they are doing can hope the rerouters and smart mailers can figure out the best way to get it there, while the experts and other proficient mail users can change it if they desire. -Jo ------------------------------------------------------------------------------- | Joseph E Poplawski (Jo) US Mail: 1621 Jackson Street | | Cinnaminson NJ 08077 | | UUCP:..!rutgers!rochester!moscom!telesci!fantasci!jep | | ..!princeton!telesci!fantasci!jep | | ..!pyrnj!telesci!fantasci!jep Phone: +1 609 786-8099 home | -------------------------------------------------------------------------------
pcg@aber-cs.UUCP (Piercarlo Grandi) (12/18/88)
In article <VIXIE.88Dec14065701@bacchus.pa.dec.com> vixie@decwrl.dec.com (Paul A Vixie) writes:
Unido's policy is to reroute based on the facts that (a) they have to pay
lots of money for the transatlanctic crossings -- and in fact they charge
this back to other German sites, and (b) the German namespace is totally
controlled and there can be no duplicate host names.
In essence, they don't run a USENET, they run an INTERNET type of thing, i.e
a controlled environment in which "relative addressing, source routing" can
be replaced by "abolute names, dynamic routing".
The european uucp network is entirely based on these assumptions.
Unfortunately, these and other factors tend to make the european uucp
network tree shaped as well, with choke points at the non leaf nodes.
--
Piercarlo "Peter" Grandi INET: pcg@cs.aber.ac.uk
Sw.Eng. Group, Dept. of Computer Science UUCP: ...!mcvax!ukc!aber-cs!pcg
UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)vixie@decwrl.dec.com (Paul A Vixie) (01/09/89)
[Vixie] # Unido's policy is to reroute based on the facts that (a) they have to pay # lots of money for the transatlanctic crossings -- and in fact they charge # this back to other German sites, and (b) the German namespace is totally # controlled and there can be no duplicate host names. [Grandi] # In essence, they don't run a USENET, they run an INTERNET type of thing, i.e # a controlled environment in which "relative addressing, source routing" can # be replaced by "abolute [sic] names, dynamic routing". This explaination has been advanced previously by a EUUG person, by a UUNET person, and by a UNIDO person. I explained to all three of them that they are of course free to reroute any mail which is bound for a host which is inside of their domain of control. My complaint against UNIDO's rerouting is that they feel justified in rerouting when the destination host is NOT in their domain of control. Jordan tried for a long time to send mail to <unido!uunet!vixie!smegma!mdg>, which was a perfectly valid path. UNIDO decided to send it to <...!uport!smegma!mdg>. But the uport!smegma link was broken, as in completely dead, no-workee, zonked. And <uport!postmaster> was not answering their mail; they had never corrected their UUCP Map entry and since they weren't answering their mail there was no way to ask them to correct the problem. We asked UNIDO to please stop rerouting since the hosts they were rerouting among were NOT UNDER THEIR CONTROL. We were told, effectively, to piss off. <unido!postmaster> absolutely insisted that they were doing us a favor and that we should contact <uport!smegma>. No other options were given. Finally we changed the host name of "smegma" to "noe", which had no old links advertised. Jordan also set up a pcsbst!pyramid link and he now avoids UNIDO on all of his outgoing mail. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013