miker@laidbak.UUCP (Mike Roth) (08/22/86)
[ shoes for industry ] I have encountered a major problem with routing mail through ihnp4. ihnp4 has a tendency to bounce mail with a message about failing to contact the remote machine. Usually this only happens when I send from ihnp4 to seismo, but will also happen occasionally with other machines. I wouldn't consider this too much of a problem except that the failure rate is quite high (about 1/3 of my mail gets bounced). I realize email isn't completely reliable, but even the post office does better than this. ---------- Mike Roth - ihnp4!laidbak!miker
news@seismo.CSS.GOV (UseNet News) (08/24/86)
seismo stopped sending mail through ihnp4 months ago. It was unreliable. ihnp4 still calls us with incoming mail. Everytime I brought the problem to someones attention, it was promptly fixed. However, I don't have time to keep pointing out that ihnp4 is wedged again. (I usually noticed it when there were 4 or 5 hundred messages queued up for ihnp4). Gary, we miss you. ---rick
dhp@ihlpa.UUCP (Douglas H. Price) (08/25/86)
> > > seismo stopped sending mail through ihnp4 months ago. It was unreliable. > ... > Gary, we miss you. > > ---rick All too true. Currently, ihnp4 as NO funding support, and is limping along day-to-day on the largesse of the department that 'owns' it. Some of us attempt from time to time to unwedge it from whatever new fiasco has overtaken it, but lack of offical attention, old hardware and a flakey semi-experimental kernel have all taken their toll. I would NOT recommend depending on ihnp4 for mail delivery these days, since np4 has an annoying habit of tossing its cookies quite regularly on its spool file system. -- Douglas H. Price Analysts International Corp. @ AT&T Bell Laboratories ..!ihnp4!ihlpa!dhp
gjm@packard.UUCP (Gary J. Murakami) (08/26/86)
In article <782@laidbak.UUCP> miker@laidbak.UUCP writes: >... ihnp4 has a tendency to bounce mail with a message about >failing to contact the remote machine. ihnp4 is doing its best to deliver huge amounts of mail and news with limited cycles, modems, administration, etc. It's often the case that it can't get around to a site simply due to lack of resources. Some neighboring sites have small windows for availability. If ihnp4 doesn't get them during that period, you get increments of 24 hour delays to the next time window. Many neighboring sites change their access and failed to notify ihnp4. Out of 1400 or so links, 100-200 appear defective. A couple of years ago, I used to fix a few links daily by tracking down errant system administrators, but you can guess how fun this was. >... I wouldn't consider this too much of a problem >except that the failure rate is quite high (about 1/3 of my mail >gets bounced). I realize email isn't completely reliable, but even >the post office does better than this. >---------- >Mike Roth - ihnp4!laidbak!miker I'm sure ihnp4 could do better if everyone donated $.22 or so for each piece of mail (or news) that they routed through ihnp4. I wonder how well USnail would run if you didn't have to pay for it. -Gary
miker@laidbak.UUCP (Mike Roth) (08/26/86)
[ Food for thought ] When I posted my comment on my problems with ihnp4, I was well aware that the service was being provided for free. I did not mean to sound like a cheap selfish user. I was just hoping that there may be some way to help clear up the problems. Just pipe dreams, I guess. I also did not mean to imply that the problem was completely ihnp4's fault. I figure that the current state of affairs cost the network more than if the problem were fixed due to resendings, which also increases overall load through ihnp4. Sort of a snowball effect. Even failed uucp connection attempts cost in processor time. Just thought I'd put my initial posting into perspective. -------- Mike Roth - ihnp4!laidbak!miker
werner@ut-ngp.UUCP (Werner Uhrig) (08/26/86)
In article <1727@ihlpa.UUCP>, dhp@ihlpa.UUCP (Douglas H. Price) writes: > > All too true. Currently, ihnp4 as NO funding support, and is limping along > day-to-day on the largesse of the department that 'owns' it. Some of > us attempt from time to time to unwedge it from whatever new fiasco has > overtaken it, but lack of offical attention, old hardware and a flakey > semi-experimental kernel have all taken their toll. I would NOT recommend > depending on ihnp4 for mail delivery these days, since np4 has an annoying > habit of tossing its cookies quite regularly on its spool file system. 1) given that we have "smart mailers" these days, that do auto-routing where the user does NOT determine the path of the message, the question begs: HOW CAN THE AVERAGE USER AVOID IHNP4? IS ANYONE DOING ANYTHING TO UPGRADE THE TABLES TO AVOID IHNP4? 2) maybe avoiding ihnp4 may alleviate the problem anyway as the load will become manageable and problems will nearly all go away. 3) while the largesse of the department that 'owns' it is, basically, appreciated, I do not consider that any favour is being done to the net by allowing a machine with "old hardware and a flakey semi-experimental kernel" to become the de-facto net-hub for Email. A job, badly done, can be worse than a job not done at all. There is nothing worse in communications than UNRELIABLE COMMUNICATIONS. Maybe someone should simply pull the plug on ihnp4, or rename it, or whatever. Maybe someone should post some names and addresses of people at AT&T to which the net can appeal with convincing arguments why it is in AT&T's advantage to support net-mail. Remember that every message going through ihnp4 FREE also, usually, goes through several other sites creating revenue for AT&T (or someone else ...well, I didn't say I had any good arguments ready (-:) I depend on Email a lot, and would rather know that it *DEFINITELY* doesn't work and finding alternatives for communications, rather than wasting my time generating messages to be gobbled up by "black holes" and not knowing that my communication channels are broken. BTW, 99% reliability may not be good enough until the mailer-software includes some kind of automatic mail-progress and 'lack-of-reply' alarm features. To put it in words: I AM APPALLED OF WHAT I'M BEING TOLD HERE EXPLICITLY about the ihnp4 situation, which so far I only had reason to suspect but had not been able to confirm to be broken.
werner@ut-ngp.UUCP (Werner Uhrig) (08/26/86)
I consider the problem to be so grave of nature and most users to be rather unaware of it, that I request - no, demand - that someone 'fess up in a posting to mod.announce, which will, hopefully, have the effect that people will remove recommended paths through ihnp4 from their signatures. I'd consider it a grave failure to the net-community if something isn't done about this pronto. This seems to be another case of where "the ones in the know" are perfectly aware of a problem and able to work around it, but where the "rest of them/us" are left in the frustration and darkness caused by lack of information. The fact that ihnp4 is failing under the load is not really surprising, what surprises is the fact this educated and enlightened community of "communicators" seem to be unable to spread the "bad news" as well (it should be BETTER) as reputation is at stake here - we should do better, really.
gds@sri-spam.ARPA (The lost Bostonian) (08/27/86)
I would like to thank Mr. Uhrig for his concern over the situation. This problem has come up before, but no one seemed to be concerned. Now that it is revealed to be serious, perhaps a new policy for uucp mail should be set. In article <3880@ut-ngp.UUCP>, werner@ut-ngp.UUCP (Werner Uhrig) writes: > 1) given that we have "smart mailers" these days, that do auto-routing > where the user does NOT determine the path of the message, the > question begs: > > HOW CAN THE AVERAGE USER AVOID IHNP4? > > IS ANYONE DOING ANYTHING TO UPGRADE THE TABLES TO AVOID IHNP4? I have held, ever since I found out that certain sites were munging my headers to make my messages go elsewhere, that uucp mail autorouting is a no-no, because no site should be using static tables to determine routing. I don't want to get into an argument about "real networks" here (hi, henry!) but as a person who has had some experience with routing protocols, routing based on static, and possibly out-of-date information is bound to get you into trouble. If I specify a full-path source to destination address (I use address here as meaning the To: line, please lets not start an argument about addresses vs. routes), which has a high confidence of success, there is no need for an intermediate to provide a different, perhaps less reliable route for me. I feel the only acceptable rerouting of such paths would be if the next hop was not a neighbor, then the routing tables should be consulted for the most likely hop which will get you to your destination. If one particular link is lossy, the mail should be queued until the link is good, if the time for the link being good is exceeded, the mail should be returned, or dropped. If uucp routing could be done more dynamically, perhaps autorouting would be acceptable, because the finding of reliable routes would be much more timely. In answer to the first question, because of the presence of smart mailers, there's not much you can do if their tables are configured to route through ihnp4 even if the path is complete. Best thing to do is find a complete path to your destination that you know works (if your destination can only be reached through ihnp4 you are out of luck), and hope that your mail won't be rerouted. In answer to the second question, perhaps an ihnp4 map update would be in order. In the meantime, sites which poll, or are polled by ihnp4 can set their value for ihnp4 to something greater than DEMAND. * begin philosophical mode * Two things might be done to alleviate this problem in the future. One would be to add a header to each message saying something like Routing: level where level 0 indicates the path should be interpreted as a strict source route. Failure to deliver the mail over a uucp link should result in dropping or returning the mail. Higher levels could accomodate various types of rerouting, the highest being "do whatever you think is necessary to get the mail to its destination". Of course, sendmail will have to be modified to interpret the header and do the appropriate modification (or non-modification) of the To: line. The other thing would be to take pathalias-generated routes out of sendmail, unless the next hop in the To: line is not a uucp neighbor. I consider it somewhat presumptuous for sites to reroute mail based upon what they think an appropriate route to a destination is, if a full path has been specified. I can understand the needs of certain sites to cut costs and so forth, but if they do not wish to communicate with certain neighbors, they should not advertise map entries for them, or they should return or drop mail addressed to certain places. * end philosophical mode * This should not be considered as a knock on ihnp4's or anyone else's uucp service -- the fact that they dedicate their machines to the passing of other companies' mail is laudable. However I don't feel it is in certain sites' best interests to reroute mail, and it is certainly not in the sender of mail's best interests for it to be rerouted. Autorouting has possibly caused more problems for sites like ihnp4 in that they take on a lot of mail which was not intended for them. They have enough problems handling the mail that is. --gregbo
edw@ihopa.UUCP (Ed Windes) (08/28/86)
> In article <1727@ihlpa.UUCP>, dhp@ihlpa.UUCP (Douglas H. Price) writes: > > I would NOT recommend > > depending on ihnp4 for mail delivery these days, since np4 has an annoying > > habit of tossing its cookies quite regularly on its spool file system. In article <3880@ut-ngp.UUCP>, ut-ngp!werner (Werner Uhrig) writes: > A job, badly done, can be worse than a job not done at all. > There is nothing worse in communications than UNRELIABLE COMMUNICATIONS. > Maybe someone should simply pull the plug on ihnp4 . . . Ha! Now that's what I call constructive criticms! I've got an idea, Werner. Why don't you set up an alternative system for us and let the whole world use it for free? Oh, and don't forget, it has to be perfect! ;-) Seriously, if you want reliability, pay somebody to deliver your mail and then you'll have somebody to complain to. TANSTAAFL - there ain't no such thing as a free lunch. -- ############################################################################# # Edwin D. Windes [...!ihnp4!ihopa!edw] (312)979-0978 # # AT&T Bell Labs, IH 6G-330, Naperville-Wheaton Rd, Naperville IL 60540 # #############################################################################
jeffs@quad1.UUCP (Jeff Sonstein) (08/28/86)
> Keywords: ihnp4 seismo mail > Xref: psivax net.news:2481 net.news.adm:706 > > [ shoes for industry ] > > > I have encountered a major problem with routing mail through > ihnp4. ihnp4 has a tendency to bounce mail with a message about > failing to contact the remote machine. Usually this only happens > when I send from ihnp4 to seismo, but will also happen occasionally > with other machines. I wouldn't consider this too much of a problem > except that the failure rate is quite high (about 1/3 of my mail > gets bounced). I realize email isn't completely reliable, but even > the post office does better than this. > > ---------- > Mike Roth - ihnp4!laidbak!miker [ shoes for defense... ] it seems like ALL my mail thru them gets bounced...
gds@sri-spam.ARPA (The lost Bostonian) (08/29/86)
I did some additional thinking and research about the problem. There is an acceptable rerouting scheme I failed to mention earlier -- path optimization. Example: To: a!b!c!d!e!user passes through a and b ok, arrives at c. c has both d and e as neighbors. It is acceptable for c to send the mail direct to e. If the originating machine has tables that show c has links to d and e, it is conceivable that a might rewrite the To: line to a!b!c!e!user, but questionable that it should (after all, this is based on possibly old data). However, it is not OK for b to deliver to something like f!g!e!user, because c!d!e is fully specified. I believe this is the problem we are discussing. By the way, I read RFC 976 to see if it sheds any light on these scenarios. It makes no specific comments on whether a fully-specified To: line should be rerouted, however To: lines with domain forms in them can (and probably are) being rerouted. I don't have a copy of smail, but I am assuming that it works according to RFC 976. [RFC 976 -- UUCP Mail Interchange Standard, written by Mark Horton] --gregbo
miker@laidbak.UUCP (Mike Roth) (08/29/86)
In article <381@ihopa.UUCP> edw@ihopa.UUCP (Ed Windes) writes: >In article <3880@ut-ngp.UUCP>, ut-ngp!werner (Werner Uhrig) writes: >> A job, badly done, can be worse than a job not done at all. >> There is nothing worse in communications than UNRELIABLE COMMUNICATIONS. >> Maybe someone should simply pull the plug on ihnp4 . . . > >Ha! Now that's what I call constructive criticms! I've got an idea, Werner. > Why don't you set up an alternative system for us and let the whole world > use it for free? Oh, and don't forget, it has to be perfect! ;-) >Seriously, if you want reliability, pay somebody to deliver your mail and > then you'll have somebody to complain to. >TANSTAAFL - there ain't no such thing as a free lunch. And Ed is really contributing to the solving of this problem with his response. My postings, and I suspect Werner's also, are meant to try to help make the net more reliable. Ed seems to be quite happy with the status quo. I'm not sure why. When communications become unreliable, only traffic which doesn't NEED to get through will use that communications line. The company then will consider keeping the line up as a waste of money. Then the line goes away. Sounds like a self-fulfilling prophesy to me. Whether you like it or not, ihnp4 affects a large area of the net. If it can't handle it, maybe we need to look for some alternatives. -------- Mike Roth - {ihnp4 | uiucdcs | allegra}!laidbak!miker
dianeh@ism780c.UUCP (Diane Holt) (08/30/86)
In article <6571@sri-spam.ARPA> gds@sri-spam.ARPA (The lost Bostonian) writes:
[Very sensible presentation suggesting that autorouting by "smart
mailers" should either be reconsidered or allow for a way of
overriding.]
I agree wholeheartedly. I just experienced my first toss-my-message-across-
the-country--hold-it-trying-to-contact-an-uncontactable-machine--toss-a-
message-back-across-the-country-telling-me-it-can't-go-through--and-do-it-
all-again game. Now, I knew my message's destination was only about 300
miles north of here, so I specifically looked for a full path routing that
would keep it in CA. When I got a message from ihnp4 telling me it couldn't
contact wb2, my first reaction was "How the hell did my message end up at
ihnp4?", so I did some checking around and found out about autorouting
("optimizing"). It is difficult for me to imagine that sending my message
from the West coast to the East coast and then a message back to me
(actually, it happened twice, because the first time it happened I figured
I'd just try to resend it with the same routing and hope for the best)
doesn't seem like much of an "optimization" to me -- and when I found out I
*couldn't* override it, I was incensed...there should NEVER be an
"automation" that can't be manually overridden -- GPs! Well, I finally found
a routing that would avoid the machine (sdcrdcf) that was autorouting, but
the whole process of getting my message from Santa Monica, CA to Palo Alto,
CA took two weeks!
Now, I'm not against autorouting per se, but for it to be truly efficient
it should either 1) guarantee that it's rerouting will in fact be the most
optimal (and a successful) path (which seems unlikely due to the maintenance
overhead of the database it uses), or 2) it should allow for users to
*override* it. I vote for #2 in any case.
P.S. I used to offer a return mail path in my signature that included ihnp4;
I don't think I'll be doing that from now on, now that I know about the
problems that inhp4 is having. That information should be made more generally
available.
Diane Holt
Interactive Systems Corp.
Santa Monica, CA
decwrl!sequent!ism780c!dianeh
"You depend on it for so much, but are any of you really its master?"
(Originally said in reference to language, but the way things are going it
looks like it could start being applied to technology.)werner@ut-ngp.UUCP (Werner Uhrig) (08/30/86)
>Ha! Now that's what I call constructive criticms! I've got an idea, Werner. > Why don't you set up an alternative system for us and let the whole world > use it for free? Oh, and don't forget, it has to be perfect! ;-) >Seriously, if you want reliability, pay somebody to deliver your mail and > then you'll have somebody to complain to. >TANSTAAFL - there ain't no such thing as a free lunch. I can't offer a replacement service for ihnp4, but I offer anyone who works on ihnp4 free breakfast, if we can discuss current short-comings, without getting bent out of shape. Well maybe, that does not count as Free Breakfast ....
gjm@packard.UUCP (Gary J. Murakami) (09/03/86)
Folks, I'm sorry that I no longer have physical access to the hardware and consoles of ihnp4 and its communication equipment. I've done some poking around on ihnp4. Part of the problem is that the old data PBX system at Indian Hill was retired recently. This removed 8 inbound lines (AT&T use) and about 8 outbound lines (including our 2400 bps dialers). So the remaining inbound ports are more congested than ever. There is also a possibility of a flow control problem on the new outbound lines. I've made a few phone calls to try to get the current configuration examined... -Gary
rs@mirror.UUCP (09/03/86)
I have slight trouble with ihnp4, but am generally able to get a
work-around if necessary (unix1, where are you...). I get called
by them once in a while, and call them a couple of nights a week,
on the average. I have always been very grateful for the free
service they provide for my site. I've been in contact with the
SA's there once or twice, when I had problems, and have always
found them courteous and helpful.
When new mod.map data comes in, I unpack it with John Quarterman's
uuhosts package, and feed it to Peter Honeyman's pathalias
program. This is used by Mark Horton's smail system to route mail
for my site in the most efficient manner. What do all these things
have in common with ihnp4? They're wonderful things that I get
*for free!*
If you're not doing something similar, then you are depending on
the kindness of strangers, and you pretty much deserve what you get.
If you *can't* do this (e.g., pathalias doesn't run on a 16-bit
machine), and you've been unable to find someone nearby to help you,
then maybe you should accept that fact that participation in this
network requires a bigger investment than you've made. *If you want
to be in charge of your own fate.*
If you *are* doing these things, and still find that site 'foo'
is rerouting things contrary to what the published mod.map data
leads you to believe is the optimal route, then get in touch with
the postmaster at foo and work things out.
----
Rich $alz {mit-eddie, ihnp4, wjh12, cca, cbosgd, seismo}!mirror!rs
Mirror Systems 2067 Massachusetts Avenue Cambridge, MA 02140
Telephone: 617-661-0777 "Hi, mom!"henry@utzoo.UUCP (Henry Spencer) (09/04/86)
> To: a!b!c!d!e!user > > passes through a and b ok, arrives at c. c has both d and e as > neighbors. It is acceptable for c to send the mail direct to e... Not necessarily. Life would be much simpler if all links were of equivalent quality -- certainly pathalias wouldn't have to work so hard -- but that's not the way it is. It's not uncommon for the c!d!e path to be *much* better than the c!e path, so large or time-critical mail might not want to be gratuitously rerouted through a poorer link. If one must reroute, the right criterion is that the c!e route should be at least as fast and, if the mail is large, that it should have comparable bandwidth. It would be nice to factor some measure of reliability into this as well, but getting the data for that is hard. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry