erik@naggum.se (Erik Naggum) (09/22/88)
I have been following the discussion of active rerouting in comp.mail.uucp and on the info-smail list for a while, and would like to give the following rather longish comment on it. It seems that the arguments against it are as follows: 1. The UUCP maps are out of date, so we act on old (=wrong) data 2. UUCP has _explicit_ routing, so leave a user's choice alone 3. Nodes don't always register properly, so the maps are incomplete Case 1. is the fault of the map builders and distribution medium/mode. When map updates are sent in to the "responsible person" (in quotes, since he might not exist), maps _should_be_ updated immediately at all backbones or "active rerouters". Why not make this automatic? If you're demanding manpower, why not charge a small fee for this? (I think it would be possible to make daemons do this kind of work.) Case 2. is clearly wrong. Time for a reality check, here. How did the bang-paths originate? By someone decreeing that "my address is foo!bar!heaven!hell!zot!machine!user, as seen from machine xctptlr, which you must find for yourself"? Nooo. The whole point with bangpath addresses is that they are based on neighbors talking to each other, and you are making a list of neighbors that you know will help land a message in your mailbox when you give it away. Preferably the first node is a well-known one. (Which speaks for going to make it a domain, and let the domain entry point worry about what's inside it.) No-one "explicitly" routes anything, it's just "_a_ known way to get here, at least the last time I checked". With the bangpath universe being in state of flux (that's your argument, anyway), how dare anyone use a bangpath without checking that it still works? (Can you expect people to send their message on the basis that they will be testing the network connectivity by doing so?) An explicit route to me is a way to _force_ a message to travel along this route, and the only place I've seen it is in the Return-Path field, but I don't even find it useful even here, since a fast route one way is not necessarily a fast route back. What an "explicit route" entails is that the sender knows how the whole set of neighbors that his message will be passing through are talking to each other. This is so blatantly in contradiction with the dictum that the bangpath universe is changing constantly, that I wonder why it hasn't been mentioned before. You scream and shout because active rerouters "know more about me than I do", but YOU know more about a whole lot of nodes and neighbors than THEY do if you think of the bangpath as an "explicit route". How can you DO that? Why should YOU be allowed to do something you disallow others to do? Case 3. is a problem which has to do with sloppy system managers and people who can't be trusted to do their job right. It's most emphatically NOT the fault of either pathalias, uucp maps or "active rerouting" that some jerks prefer to stay in the dusk and send mail at people. Stomp on those jerks instead of at the "active rerouters" if you think stomping on people is so great. They are the reason behind the arguments _against_ rerouting; they choose node names some people already have; they don't understand how this game works and that's their fault, too. I'd much rather return mail from nodes I don't know about to the sender (Return-Path and explicit routing comes in handy here!) than childishly marking "active rerouters" DEAD. The last method only propagates the mess by excusing the real offenders. I have based my arguments on the following terse premises: 1. All nodes in the network should be registered 2. We're going to move to domain notation, anyway 3. People want mail from A to B, to which a path is the _means_, not the _end_. 4. Pathalias is great, and relieves us all of a lot of drudgery to get our mail systems work I also have abstracted your (collective) arguments as follows 1. A mail sender can be demanded to know the network topology of the world when he wants to send mail to someone 2. Registration is just a way to make it harder for people to get on the net 3. It doesn't matter that people use expensive routes; it's not their money, anyway 4. It's impractical or impossible to know the network topology of the world at the backbone sites Of course, point 1 refers to a much narrower context than does point 4, but still, if 4 is true, how can 1 be true to any degree at all? At my site, I do the following things with incoming mail: 1. If it has a bangpath in the headers, I convert it to <user>@<lastnode>.uucp, and store the bangpath away for future use. 2. If I know how to route to an address in the envelope, I rewrite it to what I know. If I don't know, I let my backbone take care of it, or the first hop if I know it. 3. If the last component of the address is a domain name, I clip it there and convert it to <user>@<domain>, while storing the path away for future use. 4. For domains that I know how to route to, I convert '%' to '@' and throw away the relay node. (Presently, this is only ".uninett", a Norwegian joke.) (Rationale: If people haven't bothered to register their little domain, that's just stupid. Also, there may be other, better ways to get into that domain than via the relay node. I don't know this is true from any machine, but certainly from a lot.) 5. For nodes that I talk to directly, or are a known path away, I convert their paths to domain notation, if relevant. 6. For unknown nodes that appear "behind" a known node to me, except if that is my backbone, I send a mail to postmasters at the following machines: my own, the offending node's, and the immediately preceding node's, and return the message to the user, telling him that mail service in unavailable. The mail to the postmasters do not include the message, but only the paths or addresses of the sender. 7. I respect RFC822 source routes, btw. 8. Minor point: I rewrite "bang!path!user (J Random User)" to "J Random User <user@path.uucp>", and add quotes around the user name iff it contains delimiters. I'd like just to route messages from unknown nodes to /dev/null, so that I don't have to pay for returning it, or so that no-one has to pay for the return message. I couldn't just send it out, either, given that I'm such a hardnosed proponent of registrating nodes. One way to do it, is of course for the immediate neighbor to convert it to user%unknown, and I don't make any fuss with such addresses. (Although some jerks think that '%' is just a variant of '@', and break things when parsing, I refuse to consider jerks as important enough to do anything about.) When mail gets bounced or people complain, I look at the things I did to a message, and sees if that was all right, and the fault is with the destination node. Otherwise, I send a test message to postmaster at the offending node routed as explicitly as I can make it, and look at what I get back. (If "postmaster" is "unknown user", the case is resolved. :-) To sum up, and make statements you can quote (instead of all the text above), when you want to attack my views: 1. A node which is not registered does not exist. 2. Non-existent (unregistered) nodes can't send mail. 3. A bang path is the means, the delivery the end. 4. The maps should be updated as soon as a change occurs. 5. We should get away from bangpaths, and switch to domains. 6. Address parsing is not difficult. 7. Rewriting is OK, since it only transforms something which works, but is outside the standard to something which is inside the standard (and still works). I do not ignore the fact that a lot of manpower may be required to get things right, but that this would be a one-time effort. I do not ignore the fact that some nodes only speak bang-paths, but they'd better get a neighbor than can function as a gateway for them. No need to bother the whole world just because some people are traditionalists. Thank you for reading my long note. I hope I have managed to express myself, not necessarily to your liking, but unambigously and clear. --Erik -- +----+ +----+ Email: erik@naggum.se --or-- erik@naggum.uio.no === | === / Snail: Naggum Software; POB 1560 VIKA; OSLO 0118; NORWAY === | === / Phone: +47-2-384-400 (office), +47-2-549-163 (home) +----+ +----+ "These are my opinions, and not those of my employees."
dtynan@sultra.UUCP (Der Tynan) (09/24/88)
I've been watching all this stuff on re-routing, and am in two minds whether
or not it's a good thing. One the one hand, I don't want stuff going off into
space because of poorly maintained maps or otherwise. On the other hand, a
lot of times I haven't got the foggiest idea how to get mail to a given site,
and would appreciate a relay along the way cleaning up my routing (as an
exercise, pick a site in Ireland, and send them mail from California -- this
never works for me - I've tried it -- the routing is unwieldy). I would
suggest that we generate a new line for the mail header, called "Options:".
This would contain some sort of options list, including whether or not the
mail should be re-routed. I know, I know, no-one wants to do anything more
to RFC822, but it seems to me, that this could be extremely useful. Some other
possible options could limit bouncing (A mail server about 400 miles from here
had one of its files bounced back by our mail-daemon, because there was a lock
on the mailbox (stupidly) -- why send ~50K of data back to its source? What
did the mail-server care whether or not I got the data). An option could say
route to /dev/null if undeliverable. Also, what about auto-acknowledge. Every
once in a while I get paranoid about routing and other stuff, when I send a
message to someone, and *nothing* happens. I mean, I go through this soul-
searching, about whether to re-send or not. If the recipient didn't get it,
then good - re-sending and/or checking the path will help. If he did, and
hasn't had a chance to respond, re-sending the message will guarantee nasty
replies :-). There are probably hundreds of good idea's for an Options: line,
and if the actual options are kept OUT of RFC822, it could be easy to maintain.
Furthermore, to aid in backwards/forwards/in/out compatibility, mail systems
which receive options they don't understand, would just put a note in any
bounce, or acknowledgment, saying such-and-such an option was ignored, instead
of getting sick all over the carpet. Anyway, these are the ramblings of a
System Administrator, late on a Friday afternoon who is *still* waiting to
hear back from Richard Stallman (Are you listening, Richard???). Regards...
- Der
--
Reply: dtynan@sultra.UUCP (Der Tynan @ Tynan Computers)
{mips,pyramid}!sultra!dtynan
Cast a cold eye on life, on death. Horseman, pass by... [WBY]kls@ditka.UUCP (Karl Swartz) (09/26/88)
In article <2540@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes: > >a lot of times I haven't got the foggiest idea how to get mail to a given site, >and would appreciate a relay along the way cleaning up my routing (as an >exercise, pick a site in Ireland ... Ok, let's say I wanted to get mail to user@uujmvx, a site the maps claim to be in Northern Ireland. Running smail on ditka tells me this would be routed as follows: emoryu1!gatech!ncar!oddjob!mimsy!uunet!mcvax!ukc!uujmvx!user Hypothetically speaking, let's say uunet was a rerouter. (It is not, to the best of my knowledge.) If I had wanted uunet to "clean up my routing" I would have let it do the routing in the first place, by mailing to emoryu1!gatech!ncar!oddjob!mimsy!uunet!uujmvx!user or even just let ditka figure out how to get to uunet uunet!uujmvx!user Presumably, I did not add the extra three hops to the address because my fingers needed the exercise. Therefore, unless there is some serious problem with those links (such as uunet not talking to mcvax anymore) uunet should assume I had some reason for putting them in and leave its bloody paws off them. (Which it does, as far as I can tell.) -- Karl Swartz |UUCP {gatech!emoryu1,uunet!dasys1}!ditka!kls 1-505/667-2402 (work) |ARPA rt1!ditka!kls@hc.dspo.gov 1-505/672-3113 (home) |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
lear@NET.BIO.NET (Eliot Lear) (09/27/88)
Sorry, Karl. ihnp4 and seismo are the best examples that sites go away and mailing lists DON'T get updated. Routing is not a thing for humans should have to waste their time doing. -- Eliot Lear [lear@net.bio.net]
chip@ateng.ateng.com (Chip Salzenberg) (09/27/88)
I think I've finally figured out what makes active-routing proponents tick. According to lear@NET.BIO.NET (Eliot Lear): >Sorry, Karl. ihnp4 and seismo are the best examples that sites go away >and mailing lists DON'T get updated. Routing is not a thing for humans >should have to waste their time doing. ^^^^^^ The active routing people are optimists. They start with correct premises: "People _shouldn't_ have to make routes by hand; the maps _should_ always be accurate." They then optimistically conclude: "Therefore we _should_ always believe the maps instead of source routes." Every postmaster should have this sign over her/his desk: +---------------------------------------+ | What should be is not always what is. | +---------------------------------------+ To clarify, here is a table: Things Should be Are ------ --------- --- Usenet maps accurate inaccurate Human-written routes unnecessary occasionally necessary Active routers helpful evil and rude Passive routers half a solution the best compromise Any questions? -- Chip Salzenberg <chip@ateng.uu.net> or <uunet!ateng!chip> A T Engineering My employer may or may not agree with me. The urgent leaves no time for the important.
lear@NET.BIO.NET (Eliot Lear) (09/28/88)
Chip calls active rerouters optimists. Chip, I think you are close, BUT no cigar. Chip says, ``Well you assume the data is good.'' I say, ``Well I know there is bad data out there, and my solution will be to discover/research(/divine;-) better methods of update and propagation.'' And, in fact, I am working just on such a method. I'll let you all in on it when it's finished. -- Eliot Lear [lear@net.bio.net]
vixie@decwrl.dec.com (Paul Vixie) (09/29/88)
I've just discovered that Brian Kantor has put me in his KILL file for this group. This is muchly sad; I don't think of myself as a flamer. Various of this groups readers have sent me notes of appreciation in the past, and I like to think I cause more pleasure than frustration. Are there more of you out there who are thinking of KILLing me? If I am being widely perceived as a destructive and irritating presence, I'd like to know about it. Anyway, on with the topic. Today, we see Eliot still trying valiantly to save rerouting from a well-deserved Thunk in the Network Bit Bucket: # I say, ``Well I know there is bad data out there, and my solution will # be to discover/research(/divine;-) better methods of update and # propagation.'' And, in fact, I am working just on such a method. # I'll let you all in on it when it's finished. Eliot, please include in your divine plans a way for all active rerouters to know which advertised remote links I don't want my mail to go through on the day-by-day basis I make that selection; also, you should divine the list of UNadvertised links I DO wish to use, even though I don't want anyone but me and a small group of other sites to use them and which I therefore don't ever write down in anyone's map entries. This ought to be an interesting plan. -- 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
kls@ditka.UUCP (Karl Swartz) (09/29/88)
In article <Sep.27.23.33.16.1988.13499@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) writes: >I say, ``Well I know there is bad data out there, and my solution will >be to discover/research(/divine;-) better methods of update and >propagation.'' And then you add that to your local pathalias input. Now you send a message out and a rabid rerouter (thanks, Paul) gets its filthy paws on it and trashes your hard-earned knowledge, sending your innocent little message to bit-hell. Unless, of course, your methods identify *all* the rabid re-routers lurking in the darker corners of uucp-land, in which case we will all very eagerly await your "better methods". -- Karl Swartz |UUCP {gatech!emoryu1,uunet!dasys1}!ditka!kls 1-505/667-2402 (work) |ARPA rt1!ditka!kls@hc.dspo.gov 1-505/672-3113 (home) |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
mohamed@hscfvax.harvard.edu (Mohamed Ellozy) (09/29/88)
In article <6@jove.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes: > If I am being widely perceived as a >destructive and irritating presence, I'd like to know about it. > >-- >Paul Vixie Destructive, no. Irritating in the sense that a broken record is, yes I fear.
lear@NET.BIO.NET (Eliot Lear) (09/30/88)
Paul, I aim to please. Eliot -- Eliot Lear [lear@net.bio.net]
mouse@mcgill-vision.UUCP (der Mouse) (10/01/88)
In article <8809212215.AA21035@naggum.se>, erik@naggum.se (Erik Naggum) writes: > I have based my arguments [against aggressive rerouting] on the > following terse premises: > [four premises] > I also have abstracted your (collective) arguments as follows > 1. A mail sender can be demanded to know the network topology of the > world when he wants to send mail to someone I don't think even Paul Vixie has claimed this. But the sender may know something specific about the topology and want to express it. > 2. Registration is just a way to make it harder for people to get on > the net I don't recall anyone saying registration is *just* that. > 4. It's impractical or impossible to know the network topology of the > world at the backbone sites It's impractical or impossible for anyone to know the network topology of the world, period. In the time it's taken me to compose this letter, the network topology has most likely changed somehow. How do you propose to distribute this change to all the aggressive rerouters before my letter I sent an hour ago works its way over there and gets rerouted through a now-nonexistent link? > At my site, I do the following things with incoming mail: > 1. If it has a bangpath in the headers, I convert it to > <user>@<lastnode>.uucp, and store the bangpath away for future use. Hang on a moment while I mark naggum DEAD....there. > To sum up, and make statements you can quote (instead of all the text > above), when you want to attack my views: > 1. A node which is not registered does not exist. > 2. Non-existent (unregistered) nodes can't send mail. This is a dreadfully narrow-minded view of the world. How about this: you disconnect from the rest of the net, then you won't be bothered by all us unregistered machines who happen to want to talk to one another. > 3. A bang path is the means, the delivery the end. Usually, though explicit paths have their place: for testing, or to avoid a machine for whatever reason.... > 4. The maps should be updated as soon as a change occurs. They should be, but can't possibly be. And they certainly can't be distributed immediately. > 5. We should get away from bangpaths, and switch to domains. I think I disagree. From what I've heard, this switch would turn the net from a graph with links all over the place into a tree (or something close to it). This is very vulnerable to failure, particularly of a machine near the center of the tree. (I wonder what would happen if, say, uunet got hit by lightning....) The point-to-point nature of uucp makes a flat namespace very desireable; unfortunately, there are simply too many machines for that! > 6. Address parsing is not difficult. True, most of the time. So? > 7. Rewriting is OK, since it only transforms something which works, > but is outside the standard to something which is inside the standard > (and still works). If your reason were true, your conclusion would be. Unfortunately, aggressive rewriting often transforms something which would work into something which doesn't work. For example, suppose someone sends a letter to mcgill-vision!spock!joesmith. If this were treated sensibly, it would be routed as necessary to reach mcgill-vision, who would then look at spock!joesmith and send it over the Ethernet here to our machine spock. This is a perfectly valid bangpath and always has been. However, if it hits an aggressive rerouter it'll end up at a high school in Connecticut instead. Or get dropped on the floor somewhere. Or will you try to tell me that spock - our spock - doesn't exist? I'm sure the people who use it every day will be interested to hear that. > Thank you for reading my long note. I hope I have managed to express > myself, not necessarily to your liking, but unambigously and clear. For the most part, you have been. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
jbd@virgin.UUCP (J. Bruce Dawson) (10/01/88)
In article <383@ditka.UUCP> kls@ditka.UUCP (Karl Swartz) writes: >In article <Sep.27.23.33.16.1988.13499@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) writes: >>I say, ``Well I know there is bad data out there, and my solution will >>be to discover/research(/divine;-) better methods of update and >>propagation.'' > >And then you add that to your local pathalias input. > >Unless, of course, your methods identify *all* the rabid re-routers I frequently end up modifing the pathalias data manually to compensate for known bad links. However, this is a pain to do everytime I get a new pathalias database. What's wrong with a "pathalias search list"? This would work something like: 1) Look in local site's list of paths (say, /usr/lib/uucp/localpaths). If not found, then: 2) Look in network's list of paths (say, /usr/lib/uucp/paths). If not found, then issue a message. Comments? -- J. Bruce Dawson (603)880-1517 office (603)880-6629 home 33 Cortez Drive, Nashua, NH. 03062
lear@NET.BIO.NET (Eliot Lear) (10/02/88)
In article <1319@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: > > Or will you try to tell me that spock - our spock - doesn't exist? I'm > sure the people who use it every day will be interested to hear that. Maybe they would be very interested to hear that because their system isn't registered, it is very possible that mail bound for them will be lost. Knowing that, don't you think you should do something about it? -- Eliot Lear [lear@net.bio.net]
chip@ateng.ateng.com (Chip Salzenberg) (10/04/88)
I think we're getting somewhere now. According to lear@NET.BIO.NET (Eliot Lear): >Chip calls active rerouters optimists. [...] >I say, ``Well I know there is bad data out there, and my solution will >be to discover/research(/divine;-) better methods of update and >propagation.'' And, in fact, I am working just on such a method. >I'll let you all in on it when it's finished. Finally! As many have noticed, Eliot Lear is one of the most consistent supporters of active rerouting. Yet even he admits that the _current_ method of generating and distributing map info is _not_ good enough for reliable re-routing! My conclusion: If and when Eliot comes up with a scheme that really provides a way for active rerouters to work reliably, then active rerouting may become viable option. But with the _current_ method of map propagation, active rerouting is a Bad Thing (not to mention Evil and Rude). (Eliot may not agree with my conclusion, but I find my reasoning sound. :-]) -- 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.
allbery@ncoast.UUCP (Brandon S. Allbery) (10/07/88)
As quoted from <6@jove.dec.com> by vixie@decwrl.dec.com (Paul Vixie): +--------------- | I've just discovered that Brian Kantor has put me in his KILL file for this | group. This is muchly sad; I don't think of myself as a flamer. Various of +--------------- Figures. I bet rutgers!postmaster has you KILLed too, if he/she/it even reads this newsgroup; idealists aren't known for accepting the real world.... +--------------- | # I say, ``Well I know there is bad data out there, and my solution will | # be to discover/research(/divine;-) better methods of update and | # propagation.'' And, in fact, I am working just on such a method. | # I'll let you all in on it when it's finished. | | Eliot, please include in your divine plans a way for all active rerouters to | know which advertised remote links I don't want my mail to go through on the | day-by-day basis I make that selection; also, you should divine the list of | UNadvertised links I DO wish to use, even though I don't want anyone but me | and a small group of other sites to use them and which I therefore don't ever | write down in anyone's map entries. +--------------- Also include a method of getting them into use without requiring sites like ncoast to run pathalias every day. We don't all have four-digit Vaxen. (I say this because if active rerouting becomes the accepted way to handle mail, ncoast will probably do it as well, being that we pass lots of mail.) ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to <backbone>!sources-misc comp.sources.misc is moving off ncoast -- please do NOT send submissions direct "So many articles, so little time...." -- The Line-Eater
dboyes@uoregon.uoregon.edu (David Boyes) (10/09/88)
>Figures. I bet rutgers!postmaster has you KILLed too, if he/she/it even >reads this newsgroup; idealists aren't known for accepting the real world.... Sigh. Give Mel a break -- he's trying to make something good happen, whether everyone else thinks so or not. >[a rather hostile comment about map update schemes...] >Also include a method of getting them into use without requiring sites like >ncoast to run pathalias every day. We don't all have four-digit Vaxen. (I >say this because if active rerouting becomes the accepted way to handle mail, >ncoast will probably do it as well, being that we pass lots of mail.) Having dealt with networks that are totally map-driven (BITNET, for example), it *IS* possible to have reasonably* up-to-date maps, PROVIDED someone takes the time and effort to do so. With BITNET, where if you aren't in the routing tables, you CAN'T communicate, it's a matter of necessity. The scheme developed is simple, and I think someone already suggested it -- a base file and small update files applied on a periodic basis, usually monthly. To give you a sense of what's involved, the current routing information files are approximately 40,000 records long (card images -- this is IBMland remember). The monthly update files are usually 250-700 records and take approximately 15 seconds of CPU on a 4341 (roughly equivalent to a 11/780) to apply. It's significant, but not overwhelming. As far as the issue of private or local links go, if you don't want problems with them and don't want to register them, nothing showing those links should ever leave your site. >++Brandon -- David Boyes | Internet: dboyes@drizzle.cs.uoregon.edu | (503) 686-4394 | BITNET: dboyes@uoregon | DECnet mail addresses -- just say no.
moore@cygnusx1.cs.utk.edu (Keith Moore) (10/10/88)
In article <2947@uoregon.uoregon.edu> dboyes@drizzle.UUCP (David Boyes) writes: >Having dealt with networks that are totally map-driven (BITNET, for >example), it *IS* possible to have reasonably* up-to-date maps, >PROVIDED someone takes the time and effort to do so. With BITNET, >where if you aren't in the routing tables, you CAN'T communicate, it's >a matter of necessity. The scheme developed is simple, and I think >someone already suggested it -- a base file and small update files >applied on a periodic basis, usually monthly. One of the reasons this works for BITNET is that each node only routes messages as far as the next node in the path. This means that a computer center with several machines can get away with rearranging its local network (to cope with broken machines, etc.) as long as its BITNET links with the outside world do not change. There's no inherent reason that the UUCP world could not be handled similarly, but it would require substantial changes in almost everyone's mailer, and more discipline as to how routing table updates were handled. What if the standard way of handling mail addressed to luser@foo.UUCP were - if 'foo' is your machine, deliver it locally, else - deliver the mail to luser@foo.UUCP in care of the next node in the path to 'foo', as determined by your local node's routing table. If that node were 'bar', then the command issued by your machine would be something like uux "bar!rmail luser@foo.UUCP !message" thus trusting each node to perform part of the routing rather than choosing the entire path at any point? [as I put on my ring of flame resistance...] Keith Moore UT Computer Science Dept. Internet/CSnet: moore@utkcs2.cs.utk.edu 107 Ayres Hall, UT Campus BITNET: moore@utkcs1 Knoxville Tennessee 37996-1301 Telephone: +1 615 974 0822
peter@ficc.uu.net (Peter da Silva) (10/10/88)
In article <2947@uoregon.uoregon.edu>, dboyes@uoregon.uoregon.edu (David Boyes) writes: > Having dealt with networks that are totally map-driven (BITNET, for > example), it *IS* possible to have reasonably* up-to-date maps, BITNET has a central authority. Usenet doesn't. Usenet isn't BITNET. BITNET isn't Usenet. Speaking Italian in Rome doesn't help if it's 55 AD. -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net
chip@ateng.ateng.com (Chip Salzenberg) (10/11/88)
According to moore@cygnusx1.cs.utk.edu (Keith Moore): >One of the reasons this works for BITNET is that each node only routes messages >as far as the next node in the path. [...] > >There's no inherent reason that the UUCP world could not be handled >similarly, but it would require substantial changes in almost everyone's >mailer, and more discipline as to how routing table updates were handled. Not to mention infinite loop detection. (Incidentally, active routers also have the potential for infinite loops.) -- 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.
lear@NET.BIO.NET (Eliot Lear) (10/11/88)
Peter da Silva writes: > Speaking Italian in Rome doesn't help if it's 55 AD. And if man were meant to fly, he'd have wings. -- Eliot Lear [lear@net.bio.net]
chip@ateng.ateng.com (Chip Salzenberg) (10/13/88)
According to lear@NET.BIO.NET (Eliot Lear): >Peter da Silva writes: >> Speaking Italian in Rome doesn't help if it's 55 AD. >And if man were meant to fly, he'd have wings. And if comp.mail.uucp were meant for stupid non-sequiters, it would have been named differently. Please, folks, let's keep it technical and objective. Literary allusions are fine, but *explain* them. -- 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.
lear@NET.BIO.NET (Eliot Lear) (10/13/88)
For the intellectually impaired: For some reason, many people seem to believe that what is should be. Thus, the old argument, if men were meant to fly... -- Eliot Lear [lear@net.bio.net]
chip@ateng.ateng.com (Chip Salzenberg) (10/14/88)
According to lear@NET.BIO.NET (Eliot Lear): >For some reason, many people seem to believe that what is should be. >Thus, the old argument, if men were meant to fly... I thank Eliot for the clarification. However, he misunderstands the arguments against active routing. I attempt here to clarify myself. Proponents of active routing believe in the power of positive thinking. For example, the fact "the maps *should* be accurate" becomes, in their minds, "let's assume the maps *are* accurate." If they wish to thus deceive themselves, that's fine. However, active routers subject all mail passing through their system to the effects of their personal delusions, and that is *not* fine. It is a fact that, *given the current method of map generation*, active routing is Evil and Rude. Even Eliot has admitted as much, by retreating to the position his New and Improved map generation scheme will heal all wounds. For now, passive routing is the best compromise. It's not perfect, but it's the best we can do *today*. -- 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.
aad@stpstn.UUCP (Anthony A. Datri) (10/17/88)
In article <2947@uoregon.uoregon.edu> dboyes@drizzle.UUCP (David Boyes) writes >Having dealt with networks that are totally map-driven (BITNET, for >example), it *IS* possible to have reasonably* up-to-date maps, As I remember, most of BITnet is done with 9600 baud, always-connected lines. Propagation delay is orders of magnitude different in the uucp world. > | BITNET: dboyes@uoregon | >DECnet mail addresses -- just say no. I heartily say no to DECnet mail addresses (Run PMDF and fake it:-), but BITnet addresses aways annoyed me too. 8 char limits are pretty bad, and I've seen all too many BITnet machines where user names are just numbers (Hi! My name is 5.) -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, or my 11/34) beak is@>beak is not Anthony A. Datri @SysAdmin(Stepstone Corporation) stpstn!aad
dg@lakart.UUCP (David Goodenough) (10/18/88)
From article <2947@uoregon.uoregon.edu>, by dboyes@uoregon.uoregon.edu (David Boyes): >>Figures. I bet rutgers!postmaster has you KILLed too, if he/she/it even >>reads this newsgroup; idealists aren't known for accepting the real world.... > > Sigh. Give Mel a break -- he's trying to make something good happen, > whether everyone else thinks so or not. > >>[a rather hostile comment about map update schemes...] >>Also include a method of getting them into use without requiring sites like >>ncoast to run pathalias every day. We don't all have four-digit Vaxen. (I [ Who said anything about a 4 digit vaxen - see below: lakart is only a 16MHz 68020, comparable in power to 386 machines currently available to run XENIX / SYSV / whatever else is out there in 386 land] >>say this because if active rerouting becomes the accepted way to handle mail, >>ncoast will probably do it as well, being that we pass lots of mail.) > > Having dealt with networks that are totally map-driven (BITNET, for > example), it *IS* possible to have reasonably* up-to-date maps, > PROVIDED someone takes the time and effort to do so. With BITNET, > where if you aren't in the routing tables, you CAN'T communicate, it's > a matter of necessity. The scheme developed is simple, and I think > someone already suggested it -- a base file and small update files > applied on a periodic basis, usually monthly. Let's look at a script: lakart!dg(work/lk/src)[61]-> cat /usr/lib/uucp/uumap/[ud].* | wc 109269 426979 2783156 [i.e. there are about 3 megs of map data input] lakart!dg(work/lk/src)[62]-> wc /usr/lib/uucp/uumap/UUPATH 16147 32294 840512 /usr/lib/uucp/uumap/UUPATH [and a shade over 8/10 meg of map output data] lakart!dg(work/lk/src)[63]-> grep dopath /usr/lib/crontab 0 7 * * * root /usr/local/dopath [looking at three stars tells a great deal] lakart!dg(work/lk/src)[64]-> cat /usr/local/dopath #! /bin/sh # PATH=.:/bin:/etc:/usr/bin:/usr/local # # first get the new map stuff from comp.mail.maps # umask 022 cd /usr/spool/maps ln /usr/spool/news/comp/mail/maps/* . unshar -c * 2>&1 >/dev/null cp [ud].* /usr/lib/uucp/uumap rm -f * # # Next get the temp stuff out of news.config # cd /usr/lib/uucp/uumap rm -f d.Temp getcon /usr/spool/news/news/config/* >d.Temp # # now build the path file # rm -f UUPATH pathalias u.[A-Z]* d.* u.[a-z]* 2>/dev/null | pathfilt | sort -u > UUPATH # # finally make the index # rm -f Index bm "#N" [du].* | sed 's/:#N/ /' | tr -s '\011, ' ' ' | \ awk '{ for (i = NF; i > 1; --i) printf "%s\t%s\n", $i, $1 }' | \ sort -u > Index # chown uucp * chmod 644 [ud].* UUPATH Index [Well - this does a fair pile of work collecting map data, a pathalias, two sorts, an awk, a bm (highspeed grep), and a whole mess of other work.] lakart!dg(work/lk/src)[65]-> time /usr/local/dopath 245.9u 43.7s 7:22 65% 3+79k 1775+2268io 6pf+1w [But it still only spends 7:22 doing it - and this is only a 68020 machine. I would expect this to really fly on a VAX 780, or one of these high speed RISC machines: Note that this process is quite CPU bound: out of 7:22 (442 seconds) it spends over 1/2 that time running in user mode.] The question I have after the last fifteen minutes of messing around is "Why are people so unwilling to run pathalias on a nightly or even weekly basis?" We do it here on all the maps, on a medium to low end machine, and it still does it all in less than 10 minutes. Conclusion - as was stated above Re: BITNET addressing "IT CAN WORK" but only if people are prepared to put in a little work. For the extreme, running on PC's I'd suggest doing it once a month, (careful with your expires) while eating breakfast on Saturday or something. For my machine at home I don't worry - since I just about have a smart (and very agressive) re-router installed on lakart I don't need it: I just send to lakart!wherever!user, and it gets there. P.S. - for the weak hearted, I doubt if anything will ever be routed via lakart, since it costs DAILY * 2 to jump from any of our neighbours to any other via us, and in all cases there are cheaper paths. However on the subject of routing I would ask the following: when you drop a letter in a mailbox, you just put the address on it. You don't really give a wet slap how the Post Office gets it there, as long as it arrives. Hence, by all means provide a bang path, but what is the paranoia about someone else looking at and saying "I know a better way". As long as your letter gets there what do you care? -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@harvard.harvard.edu +---+
dg@lakart.UUCP (David Goodenough) (10/18/88)
Chip Salzenberg sez: > Not to mention infinite loop detection. > > (Incidentally, active routers also have the potential for infinite loops.) > -- > 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. Consider the following. Each message has a unique Message-ID (or is it Message-Id) field. As a solution to a programming problem where my mailer at home (pallio) kept sending out duplicate copies of letters (Always two, never three or one) I hung a 300 line front end on in front of rmail. Basically it does one of the Inews jobs: it maintains a record of all messages that have passed through lakart in the last 30 days. When it sees a message id for a second time it returns the letter to sender, and flags that it has done so (it is left as an exercise to the reader to figure out why it is flagged). -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@harvard.harvard.edu +---+
dg@lakart.UUCP (David Goodenough) (10/18/88)
Chip Salzenberg sez: > Proponents of active routing believe in the power of positive thinking. For > example, the fact "the maps *should* be accurate" becomes, in their minds, > "let's assume the maps *are* accurate." If they wish to thus deceive > themselves, that's fine. However, active routers subject all mail passing > through their system to the effects of their personal delusions, and that is > *not* fine. I invite comments on the notion of taking yet another step back, and asking ourselves "WHY are the maps inaccurate?" After having seen the speed with which a new machine appears in the map database, coupled with the option of sending high speed fixes out in news.config, the only reason (IMHO) I can see, is that individual site admins are not sending their updates out. Incidentally for those who are interested I could post the source of getcon(1) - the program I use to cull temporary updates from news.config It may be the case (as was mentioned) that a location has 30 - 40 (or more) machines, BUT IF THE ADMINISTRATOR OF EACH keeps his part of the bargain, there might be a chance. (puts on +6 fing of fire resistance :-) ) -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@harvard.harvard.edu +---+
chip@ateng.ateng.com (Chip Salzenberg) (10/20/88)
According to dg@lakart.UUCP (David Goodenough): >Chip Salzenberg sez: >>[active routers can cause/allow infinite loops] > >I hung a 300 line front end on in >When it sees a message id for a second time it returns the letter >to sender, and flags that it has done so. Return to sender exactly once. Nice. Nevertheless, detection of infinite loops is a poor excuse for continuing to run software (active router) that can *cause* loops. -- 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.
chip@ateng.ateng.com (Chip Salzenberg) (10/20/88)
According to dg@lakart.UUCP (David Goodenough): >I invite comments on the notion of taking yet another step back, and >asking ourselves "WHY are the maps inaccurate?" That's easy. Admins get busy, quit, or go on vacation. Hardware dies. New circumstances reveal latent software problems. Etc, ad nauseum. >BUT IF THE ADMINISTRATOR OF EACH keeps his part of the bargain, >there might be a chance. Problems may arise and persist without the admin's knowledge. In the absence of foreknowledge, the maps will never be accurate. -- 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.
vixie@decwrl.dec.com (Paul Vixie) (10/22/88)
Chip says... # Problems may arise and persist without the admin's knowledge. In the # absence of foreknowledge, the maps will never be accurate. ...and that's true, but it's not important. The maps could accurately reflect the territory, with instantaneous all-points updates which were never mistaken and which tracked broken UUCP connections hour by hour -- -- and rerouting would STILL be a bad idea. "Bad" as in morally incorrect, as well as simply wrong-headed with overtones of fascism and stupidity. -- 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) (10/25/88)
According to vixie@decwrl.dec.com (Paul Vixie): >Chip says... ># Problems may arise and persist without the admin's knowledge. In the ># absence of foreknowledge, the maps will never be accurate. > >...and that's true, but it's not important. Yes, it is important. Once a person has acknowledged the truthfulness of that statement, he no longer feels any need to search for a technical solution to make active routing reliable, since that search has been proved to be pointless. Those of you who believe that there is a solution, consider this a challenge: Find it. But until you do, don't reroute. Please. (By the way, the tone of Paul's comment was uncalled for. I agree with his conclusion, but not his reasons.) -- 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.
vixie@decwrl.dec.com (Paul Vixie) (10/26/88)
Mr. Chip Salzenberg writes:
# Once a person has acknowledged the truthfulness of that statement, he no
# longer feels any need to search for a technical solution to make active
# routing reliable, since that search has been proved to be pointless.
That's exactly my point. The maps should be made as correct as possible, in
order to maximize their usefulness (_whatever_ use that may be). But if the
goal is to make active rerouting better, this isn't going to do it: there are
problems with active rerouting that run a lot deeper than inaccurate maps.
# (By the way, the tone of Paul's comment was uncalled for. [...])
I think I agree. Shows what too little sleep can do to one's manners. My
apologies to all who were offended.
--
Paul Vixie
Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600
Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013allbery@ncoast.UUCP (Brandon S. Allbery) (10/27/88)
As quoted from <295@lakart.UUCP> by dg@lakart.UUCP (David Goodenough): +--------------- | From article <2947@uoregon.uoregon.edu>, by dboyes@uoregon.uoregon.edu (David Boyes): | >>Also include a method of getting them into use without requiring sites like | >>ncoast to run pathalias every day. We don't all have four-digit Vaxen. (I | | [ Who said anything about a 4 digit vaxen - see below: lakart is only a | 16MHz 68020, comparable in power to 386 machines currently available to | run XENIX / SYSV / whatever else is out there in 386 land] +--------------- Wonderful. We run AT&T System III, 2MB RAM, 68000 processor; pathalias takes 2 hours to run and if you try to do ANYTHING else the system thrashes: pathalias takes every last byte of user memory. In that 2 hours I can usually expect two or more calls from hal, and often calls from our other UUCP neighbors. Not to mention calls to my apartment or Rich's house by irate users. Now, if you know of a nice fast 8-user system for $1000, please let us know... and where were you when we sent out our plea? We're still looking but the best we've been offered is any number of used PDP-11's (so much for pathalias...). +--------------- | The question I have after the last fifteen minutes of messing around is | "Why are people so unwilling to run pathalias on a nightly or even weekly | basis?" We do it here on all the maps, on a medium to low end machine, and | it still does it all in less than 10 minutes. Conclusion - as was stated +--------------- See above. Try the room down the hall; we're not buying. It doesn't take *work*, it takes *money*. Unless you're buying us a computer to do it on, don't tell us to run pathalias daily, or even weekly. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allbery@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
brisco@pilot.njin.net (Thomas Paul Brisco) (10/27/88)
> <12855@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon S. Allbery) > Wonderful. We run AT&T System III, 2MB RAM, 68000 processor; pathalias takes > 2 hours to run and if you try to do ANYTHING else the system thrashes: > pathalias takes every last byte of user memory. In that 2 hours I can > usually expect two or more calls from hal, and often calls from our other > UUCP neighbors. Not to mention calls to my apartment or Rich's house by > irate users. > [...] > > See above. Try the room down the hall; we're not buying. It doesn't take > *work*, it takes *money*. Unless you're buying us a computer to do it on, > don't tell us to run pathalias daily, or even weekly. It seems obvious to me ... If you speak to hal so frequently, why aren't you using them as a router? I use an InterGraph InterPro 32C, and while it's not hurting for CPU, I'd just rather not have the maintenance and would prefer to use the disk space for other things. I can't think of any reason they might find it objectionable (but you should probably inquire first). Of course, they would need to be doing re-routing of some sort ...;-) Tp. -- ...!rutgers!brisco (UUCP) brisco@pilot.njin.net (ARPA) brisco@ZODIAC (BITNET) 201-932-2351 (VOICE)
jc@heart-of-gold (John M Chambers) (11/05/88)
> # Problems may arise and persist without the admin's knowledge. In the > # absence of foreknowledge, the maps will never be accurate. > > The maps could accurately reflect the territory, with instantaneous all-points > updates which were never mistaken and which tracked broken UUCP connections > hour by hour -- It's worse than that. Suppose I, as a totally conscientious system admin (:-), discover that all my mail links are down, and I can't get them fixed right now for some obscure reason or other. So I go and update my uucp.map file, and try to send it off. Ooops! It just sits there, because the mail links are down. If you know a way that I can do what is demanded of me in this situation, I'd sure like to know about it. (Perhaps the same technique could be used to keep my users happy when the system is down. ;-) > -- and rerouting would STILL be a bad idea. "Bad" as in morally incorrect, as > well as simply wrong-headed with overtones of fascism and stupidity. No, it's not fascism. I think the term is "Pollyanism". There are many people who act as if they truly believed that this is the best of all possible worlds. And in an election year, yet. -- From: John Chambers <mitre-bedford.arpa!heart-of-gold!jc> From ...!linus!!heart-of-gold!jc (John Chambers) Phone 617/217-7780 [Send flames; they keep it cool in this lab :-]
vixie@decwrl.dec.com (Paul Vixie) (11/05/88)
# No, it's not fascism. I think the term is "Pollyanism". There are many # people who act as if they truly believed that this is the best of all # possible worlds. And in an election year, yet. I've since retracted my statements in that article, and among the reasons was that "fascism" was both too strong a term and was not technically correct. However, "pollyamism" doesn't completely describe the attitude I've been yelling about. Let's try "paternalism". There are people on the net, who run large and busy machines, who feel that neither you nor your router can find your (its) way out of a paper bag without help from them and their rerouters. Or that you might auto-route something along what they feel to be a suboptimal path. Or whatever -- other reasons have been put forth, and I'm not going to list all of them here. But the bottom line, is: They Are Going To Do You A Favor, Whether You Want Them To Or Not; It's For Your Own Good, And They Know What's Good For You Better Than You Do. Pfaa. -- 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