shibumi@farcomp.UUCP (Kenton A. Hoover) (10/26/89)
During hurricanes, earthquakes and other natural disasters, one item that always becomes at a premium is PHONE SERVICE. News of the problems quickly increases the strain on phone services, due to emergency use, welfare inquiry (i.e. calling the folks to say "I'm fine!") and sell orders to your broker (:-). Often, power gets knocked down, and the local telco must fall back on their own, limited battery resources to run the phone system. However, computers, provided there is power and phone service running them, still continue calling other USENET sites, relaying mail and news. Each connection costs a phone call, which can be an expensive phone cal for other, in terms of power and perhaps, a needed bit of CO switching time. I doubt that anyone really questions the need for uninterrupted "rec.humor.funny" service during a period of local emergency. I propose that there be an disaster plan for USENET that entails its being "turned off" in local areas during periods when utility services are suffering excessive loading. Flame on, people. -- | Kenton A. Hoover | | Postmaster General shibumi@farcomp.UUCP | | Farallon Computing Inc. +1 415 849 2331 | | "Evil will always triumph over good because good is dumb" |
chuq@Apple.COM (Chuq Von Rospach) (10/26/89)
>I propose that there be an disaster plan for USENET that entails its being >"turned off" in local areas during periods when utility services are >suffering excessive loading. >Flame on, people. No flames, but a counterpoint. I agree that it's silly to ship lots of USENET data around during an emergency. But I think shutting off the nets during emergencies is a bad idea. One of the things the network has allowed us to do is reduce the amount of panic-phoning that was going on. Case in point: One of the SFWA members on the Outside immediately organized the various SFWA on-line contingents into an information gathering unit. As people were found to be okay, this data was passed to everyone involved and spread through the grapevine, reducing by a large amount the number of phone calls necessary to get that information out. It also allowed me to make a single phone call outside the emergency area and pass along status information to someone who would then use their phones to call people I wanted to know I was okay -- wtihout me having to do it directly. End result: a lot less overall phone time. Also, people on the Outside who were unable to contact people on the inside would queue up messages, whcih would be picked up in a batch (single phone call, maximize the efficiency). Being Inside, we'd have a better chance of getting phone calls through while not utilizing the over-stretched long-distance wires. Once we made contacts, we could queue that information back out with another single phone call. I know of a number of people and groups who did this. If you simply shut down the nets for the duration, you've immediately cut off information flow from Inside to Out (and in the other direction). A single message on USENET saved me a hundred phone calls by letting me broadcast status information. Seems like a good tradeoff. A reasonable analog would be what the Hams do during an emergency. We're not nearly as well organized as they are, but nobody would consider telling the hams to shut up until the emergency was over. Better would be to consider how to properly use the network in times of emergency. What we can do, what we should do and how to implement it. They can be very useful and important -- if we choose to. It definitely makes sense cut out the flow of trivial information, but that isn't as easy as it sounds. Worth looking into, though. -- Chuq Von Rospach <+> Editor,OtherRealms <+> Member SFWA/ASFA chuq@apple.com <+> CI$: 73317,635 <+> [This is myself speaking] Trust Mama Nature to remind us just how important things like sci.aquaria's name really is in the scheme of things.
tneff@bfmny0.UU.NET (Tom Neff) (10/27/89)
Kenton's quite right, this is a serious issue.
I agree with Chuq that the net shouldn't turn off completely because of
disasters. But it's still a good point that telephone and other
bandwidth resources become precious in emergencies and we shouldn't
waste them.
To that end it makes sense to have "emergency versions" of such key
files as B news "sys" and HDB UUCP "Systems", specifying important
hierarchies or newsgroups to pass on, and modified calling schedules
for emergency affected areas.
These would be easy to "swap in" on sites actually in the areas.
It would be a more complex operation for well connected sites to
selectively modify their Bay Area feeds, for instance, to handle
an earthquake without touching other areas. (I assume it would be
undesirable to throw the entire world net onto emergency status
every time ANY regional emergency occurs.)
One approach to solving this would be to chop up the country and world
into emergency management zones (emz's) and assign zone ID's to existing
and new nodes. Then you could support selective zone control directly
within the net software. If a hurricane hit Hawaii for instance, a
master control message placing that zone on Emergency status could be
issued. Perhaps this could be done with existing state and country
subnets once those are in place, or maybe they'll never be sufficient.
The other thing to add would be an "emergency broadcast system" (ebs)
hierarchy, to be used only in emergencies. This hierarchy would
obviously lead the list in any abbreviated "sys" file.
--
I'm a Leo. Leos don't believe * * * Tom Neff
in this astrology stuff. * * * tneff@bfmny0.UU.NETjxxl@acrux (John Locke) (10/27/89)
In article <14806@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: > The other thing to add would be an "emergency broadcast system" (ebs) > hierarchy, to be used only in emergencies. It could only work better than the real EBS which, in the recent quake, failed completely and was switched off to avoid further annoyance. It was blasting out a tone in anticipation of information about which radio station to tune to. But the info never came. The observation that interested me most was that the EBS was designed to work best when the government has more info than the people, i.e. missles are on the way. The quake was the opposite situation: the people in the field had better info and could get it to the radio stations. The net, it seems to me, leans toward that side of the distinction. We are in the field. However, in the recent quake there were wide-spread power outages. Many installations, including this one, were without power. We were down for almost 24 hours-- so I'm not sure what practical purpose a net facility for emergencies would serve in the event of a serious, debilitating disaster.
tneff@bfmny0.UU.NET (Tom Neff) (10/27/89)
I would think that posting to ebs.* would proceed under the assumption that some or most of the affected area would be unable to receive it for a while. But * the queueing and "flood" algorithm for news distribution ensures that when sites do come on line eventually they'll get it; this would be the first or only info they did get in this case. As an admin I would find it most comforting. * setting up an alternate EBS "net" as defined in Sys files and so forth, could include vastly increased redundant connectivity (for ebs.* only) in the event of emergency. For instance, I might have only five UUCP connections under normal conditions, but my backup EBS "sys" file might connect me to dozens of area machines to feed ebs.* only. This maximizes the chance that a partially restored regional net would get vital stuff passed around. * Disruption of national connectivity could still leave well connected regional "pockets" which could then run on EBS. These are just ideas to kick around. -- Hey, where'd the Colombian Coffee ads go all of %8 Tom Neff a sudden! Is Juan Valdez hiding in Panama? 8% tneff@bfmny0.UU.NET
bzs@world.std.com (Barry Shein) (10/27/89)
Obviously the concern here is tying up public telephone network
resources during disasters (private lines don't make much
difference...yet.)
What is needed is to inform the people who actually are tracking an
emergency situation first-hand (AT&T, Civil Defense, FEMA, Pentagon)
of contacts who might be able to get bandwidth freed if and when
needed (CERT comes to mind as a primary point of contact.)
All that remains is to structure those thoughts into actions:
1. Who are the first level contact points (CERT?)
(assuming they're willing, of course)
2. Who should be told how to contact these people? What
should they be told (e.g. explain that this network
has often been the only thing that does get thru in
in an emergency due to its redundancy and stubborness,
it's *not* obvious that the reaction to every emergency
is to shut down the network!)
3. What *exactly* would the procedure be once contacted
(probably post to a few groups like announce.important,
e-mail to some pre-prepared list of individuals etc.)
4. What, if anything, should be policy (e.g. do we shut down
merely because someone asked us to? do we indemnify anything
or anybody [no]? is every site anarchically responsible for
deciding their response to a request to shut down [yes]?)
I think that about sums it up.
--
-Barry Shein
Software Tool & Die, Purveyors to the Trade | bzs@world.std.com
1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzseps@toaster.SFSU.EDU (Eric P. Scott) (10/27/89)
In article <103@farcomp.UUCP> shibumi@farcomp.UUCP (Kenton A. Hoover) writes: >During hurricanes, earthquakes and other natural disasters, one item that >always becomes at a premium is PHONE SERVICE. Ok. >I propose that there be an disaster plan for USENET that entails its being >"turned off" in local areas during periods when utility services are >suffering excessive loading. > >Flame on, people. At your service. The MAJOR news flows in the USA are *not* uucp-over-switched lines. They're NNTP over Internet, and shutting them down can only aggravate things. Go ahead--turn off your transport, but keep your "good intentions" off MINE. -=EPS=-
henry@utzoo.uucp (Henry Spencer) (10/27/89)
In article <103@farcomp.UUCP> shibumi@farcomp.UUCP (Kenton A. Hoover) writes: >... Often, power gets knocked down, and the local telco >must fall back on their own, limited battery resources to run the phone >system. The telcos have about as much faith in the power company as in the Easter bunny. The battery resources are indeed limited, but they are backed up by emergency generators capable of running the system for days. The telcos may have problems with damaged cables and massive call congestion, but the system keeps running. For the most part, only the military is more paranoid than the phone company. >However, computers, provided there is power and phone service running >them, still continue calling other USENET sites, relaying mail and news. >Each connection costs a phone call... Let us look at numbers. The only real expense of those phone calls is the contribution they make to congestion. How many Usenet sites were trying to call the Bay area after the quake? Be generous and call it 1000. Now, how many *people* were trying to call the Bay area after the quake? Right. Numerically, our contribution to the problem is insignificant. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (10/27/89)
In article <1989Oct26.232947.9679@world.std.com> bzs@world.std.com (Barry Shein) writes: >What is needed is to inform the people who actually are tracking an >emergency situation first-hand (AT&T, Civil Defense, FEMA, Pentagon) >of contacts who might be able to get bandwidth freed if and when >needed ... Before getting excited about this, figure out how much of the total phone bandwidth we amount to. It's not worth the trouble. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
brad@looking.on.ca (Brad Templeton) (10/27/89)
USENET is not an essential service, of course, but computer calls are actually a more efficient use of the phone system. One call can send 100 "I'm ok" mail messages in a minute or so, or distribute info to thousands of people, while a voice call gets one message to one person. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
cdr@amdcad.AMD.COM (Carl Rigney) (10/27/89)
Innumeracy strikes again.
1) At its peak the PacBell phone system in the Bay area was switching
1 million calls a minute. "grep u.usa.ca.[024680] | wc -l" shows
517 sites. Even assuming every site spent every minute on the phone
(far from true, since many of them are small), that's 0.05% load.
2) A minute of conversation is about a page of dialogue; call it
2 kilobytes. A Trailblazer can send 2KB (compressed) in less than
a second. Nearly a 100 to 1 reduction in phone bandwidth, plus MORE
IMPORTANTLY, as Chuq noted computers batch messages, and so many
messages are sent with one connection, reducing the amount of
phone switching required.
If you really want to have significant impact on disaster recovery
communications, buy them a UNIX box and some Trailblazer modems,
and let them get as many UUCP connections as possible.
Next subject.
--
Carl Rigney
cdr@amdcad.AMD.COM {ames att decwrl pyramid sun uunet}!amdcad!cdr
MS 167; AMD; 901 Thompson Place; Box 3453; Sunnyvale, CA 94088
408-749-2453lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (10/28/89)
In article <103@farcomp.UUCP> shibumi@farcomp.UUCP (Kenton A. Hoover) writes: >I propose that there be an disaster plan for USENET that entails its being >"turned off" in local areas during periods when utility services are >suffering excessive loading. Well, the first thing we did was shut down our link with decwrl. This is just plain old common sense. It turned out that decwrl survived and continued polling us through most of the aftermath, even though we couldn't get a line in to them. My understanding is that Pacbell simply disabled the incoming LD trunks to ensure local bandwidth would be available in the affected area. Something similar happened in Edmonton a couple of years ago when we were hit by The Tornado. In that instance, nearly all of the system administrators had the foresite to shut their modems off as well. What would you propose as a disaster plan? and how would you ensure the majority of sites were aware of it? Do you expect a "global" plan to be applicable in the majority of cases where the disaster is (relatively) local in scope? I feel that such planning is a good activity to be undertaken at the local "users group" level, since the vast majority of uucp connections are made with sites inside a local toll area. You should take into account the existance of sites with leased line connections outside the potentially affected area that might survive the disaster. These sites could become hubs capable of feeding other sites during the wee hours of the night when the load on the telephone network is substantially reduced (0100-0500). You would probably want to shut down all news except for regional groups, and perhaps have one or two people near the affected area post regular updates to the mainstream groups to try to cut down on the number of "what's going on out there" requests that inevitably flood the net. Most of this problem is due to propogation delay; As the updates flow out, they pass the sea of incoming queries. The UUCP Mapping Project was also very much on the ball during the earthquake. As sites were verified as non-operational, they were marked as dead in the d.AProject file, and updates were forwarded into comp.mail.maps on a regular basis. This allowed the well connected sites to rapidly reconfigure their routing tables. Of course, the mail had to eventually bottleneck *somewhere* (I would be interested in hearing from anyone who had this problem). Hopefully someone from the Bay area can summarize what actions were taken. This should give us a good base to start working from. I'm sure the people in Vancouver would be willing to beta test whatever we come up with in a year or two :-) -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA The Connector is the Notwork.
tneff@bfmny0.UU.NET (Tom Neff) (10/28/89)
In article <27932@amdcad.AMD.COM> cdr@amdcad.amd.com (Carl Rigney) writes: >Innumeracy strikes again. With rudeness swift on its heels it would seem... :-/ >1) At its peak the PacBell phone system in the Bay area was switching >1 million calls a minute. "grep u.usa.ca.[024680] | wc -l" shows >517 sites. Even assuming every site spent every minute on the phone >(far from true, since many of them are small), that's 0.05% load. Several things wrong with this. First, there are lots more sites out there UUCP'ing than list themselves individually in the UUCP Map Project lists. Within subnets (which may well use the telephone system, not just LANs) the minor sites are positively discouraged from listing. Second, each UUCP connection may take one, two, several or dozens of ATTEMPTED dials to succeed. In times of emergency, the average dials/success can only rise. Each failed attempt is roughly as significant in its impact on the phone system as a successful connection. Human voice customers with "redial" buttons on their new style phones would be equally troublesome, but human patience is low compared to that of uucico and uupoll and cron. Finally, if I really *must* point this out -- just because other people clogged the lines irresponsibly after an emergency does not mean that we in the Net community ought to feel scot-free to do the same. On the contrary, we ought to proud enough to set an example. >2) A minute of conversation is about a page of dialogue; call it >2 kilobytes. A Trailblazer can send 2KB (compressed) in less than >a second. Nearly a 100 to 1 reduction in phone bandwidth, plus MORE >IMPORTANTLY, as Chuq noted computers batch messages, and so many >messages are sent with one connection, reducing the amount of >phone switching required. Yes yes, Trailblazers are wonderful and everyone should have one, but not for the sake of being able to guarantee continuity for the Led Zeppelin Mailing List in the middle of a nuclear power plant accident zone. They are good because with them you can get your emergency information distributed over the net in a few seconds before yielding the lines to comply with an official request -- or before you lose service altogether. >Next subject. For the above quoted poster this is probably wise. :-) -- Annex Canada now! Free Quebec; raze and depopulate | Tom Neff Ontario; license Inuit-run casinos on the BC shore. | tneff@bfmny0.UU.NET
amanda@intercon.com (Amanda Walker) (10/28/89)
In article <84@toaster.SFSU.EDU>, eps@toaster.SFSU.EDU (Eric P. Scott) writes: > The MAJOR news flows in the USA are *not* uucp-over-switched > lines. They're NNTP over Internet, and shutting them down can > only aggravate things. Go ahead--turn off your transport, but > keep your "good intentions" off MINE. A good point. I know that UCB and LBL were back up amazingly fast, if they were down at all, and that most or all of Barrnet stayed up. Dedicated media (such as NSFnet and other high-speed networks) have their advantages; you can't call home over them, but neither can anyone else :-)... -- Amanda Walker <amanda@intercon.com>
wb8foz@mthvax.cs.miami.edu (David Lesher) (10/28/89)
# >... Often, power gets knocked down, and the local telco # >must fall back on their own, limited battery resources to run the phone # >system. # # The telcos have about as much faith in the power company as in the Easter # bunny. The battery resources are indeed limited, but they are backed up # by emergency generators capable of running the system for days. A telco friend told several standby power horror stories. One was their first Solar turbine installation. The (somewhat knowledgeable) employee freaked out when he saw the actual RPM on the tach, figured it was running away (a diesel problem that can be VERY bad news) and pulled all the emergency stops. Solution was to change the tach to say "% of rated speed". Second was the religiously tested diesel that ran for only 3 minutes when needed. You see, the 110v fuel pump was (need I say it?) not an emergency load. My favorite was the one they couldn't turn off, and the office building elevators that couldn't run with it on. It was MANY floors of stairs to get to the roof to quell the beast. After Don's stories, when I go to a building to observe a standby power test, I DEMAND the real thing. Pull the mains, and then show me everything that runs. Saves grief later. -- A host is a host & from coast to coast...wb8foz@mthvax.cs.miami.edu no one will talk to a host that's close..............(305) 255-RTFM Unless the host (that isn't close)......................pob 570-335 is busy, hung or dead....................................33257-0335
bzs@world.std.com (Barry Shein) (10/28/89)
>>What is needed is to inform the people who actually are tracking an >>emergency situation first-hand (AT&T, Civil Defense, FEMA, Pentagon) >>of contacts who might be able to get bandwidth freed if and when >>needed ... > >Before getting excited about this, figure out how much of the total phone >bandwidth we amount to. It's not worth the trouble. >-- >A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology I dunno, I think my point stands, why not let the professionals mentioned above decide this? If they agree with you at least it was their decision and we don't find out some other reasoning we missed later. -- -Barry Shein Software Tool & Die, Purveyors to the Trade | bzs@world.std.com 1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs
csg@pyramid.pyramid.com (Carl S. Gutekunst) (10/29/89)
In article <1195@atha.AthabascaU.CA> lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) writes: >The UUCP Mapping Project was also very much on the ball during the >earthquake. As sites were verified as non-operational, they were >marked as dead in the d.AProject file, and updates were forwarded >into comp.mail.maps on a regular basis. This allowed the well >connected sites to rapidly reconfigure their routing tables. Mel and I debated this privately, to no resolution. As a host that was never down, I took rather strong exception to being listed "DEAD" in the d.AProject file without anybody consulting me first. In fact, most of the hosts listed DEAD were never down at all. Mel's justification was that he generally wanted to reroute mail around the Bay Area. My point was that unless you list hosts that are actually down (sun.com was down, but not listed), and *only* hosts that are down, then it serves no purpose. >Of course, the mail had to eventually bottleneck *somewhere*. Exactly. Which is why the d.AProject changes were a well-intentioned mistake. All the changes did was cause mail to take longer, more circuitous routes -- and chew up even more of our precious phone bandwidth. There *is* one thing that we do that I'd like to suggest to other sites: all of our modems are set to quit if they don't get a dialtone within 5 seconds. That way, when the phones were most jammed, we placed a much smalled number of calls. (Pyramid's UUCP also logs call progress messages, so I could see the NO DIALTONE messages in LOGFILE. But that's just a warm fuzzy.) <csg>
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (10/30/89)
I do not know if sgi.com was marked "DEAD". If it was, it was no more than
another expression of hysteria in the rest of the country.
Unilaterily breaking the network seems extremely irresponsible, and
depending on how you describe it, sounds like sabotage. One would have
thought that those with direct UUCP links would be smart enough to take
responsible, individual action as needed. Shutting off major mail
links such as pyramid probably contributed to the voice communications
problems. ("Gee, Joe didn't respond to my email...I better call to see
what happened!") One 60 second TB+ call between rutgers and pyramid might
well have prevented ten 5 minute calls between humans.
One should keep things in perspective and not confuse the little box with
reality. Having your house collapse or your family killed would not be
minor, but for the vast majority of Bay Area residents, the direct effects
were trivial. Secondary effects such as panic attacks during aftershocks
and the hysteria of the rest of the country which caused telephone problems
were much more important to almost all of us.
Perhaps "hysteria" is the wrong word. Maybe it is nothing more than the
same goulish phenomenon as the traffic jam which happens on other side of
the divided highway from the accident. Maybe it is just a desire to
participate in earth shaking events. In any case, it is not admirable.
When the Big One finally happens, I guess the rest of the country will have
to do something really impressive. Maybe bomb Donner Pass? Start the Big
War?
Vernon Schryver
Silicon Graphics
vjs@sgi.commarc@noe.UUCP (Marc de Groot) (10/30/89)
In article <103@farcomp.UUCP> shibumi@farcomp.UUCP (Kenton A. Hoover) writes: >I propose that there be an disaster plan for USENET that entails its being >"turned off" in local areas during periods when utility services are >suffering excessive loading. Of course, such proposals are more likely to get you flamed than get you results. Right after the earthquake my computer went off hook and dialed without being given a dial tone. When it got no answer, it hung up again and waited an hour. Offhook time was about thirty or forty seconds per hour. No connects were made. When I consider the activities of people on the phone after the quake, who became human auto-redialers until they got through, I think the load my machine put on the phone system was minimal. Perhaps you will do better by proposing that dialing scripts not overdo it on redial. Just my $0.02 -- Marc de Groot (KG6KF) These ARE my employer's opinions! Noe Systems, San Francisco UUCP: uunet!hoptoad!noe!marc Internet: marc@kg6kf.AMPR.ORG
thomas@mvac23.UUCP (Thomas Lapp) (10/30/89)
chuq@Apple.COM (Chuq Von Rospach) writes: > I know of a number of people and groups who did this. If you simply shut > down the nets for the duration, you've immediately cut off information flow > from Inside to Out (and in the other direction). A single message on USENET > saved me a hundred phone calls by letting me broadcast status information. > Seems like a good tradeoff. over on the Bitnet mailing lists, QUAKE-L and HELPNET (from listserv@ndsuvm1.bitnet or listserv@vm1.nodak.edu), someone posted an offer to create a list of people who agree to (attempt to) report to the rest of the group, and others by e-mail and take requests in the event of an emergency in their area. The list is being compiled by zip code (or postal code for non-US). So rather than sitting back and talking about it, someone is actually trying to put something in place. A lot of the call attempts (as has been noted) were of relatives trying to call in and out and reassure families of well-being. Between using amateur radio and e-mail (if people knew about it), I bet we could keep traffic down a bit. Keep the networks up and use that bandwidth to its fullest! Of course amateur radio is at an advantage because 1. they often have battery-powered devices and generators to run them as well, and 2. they practice (test) a lot! - tom -- internet : mvac23!thomas@udel.edu or thomas%mvac23@udel.edu uucp : {ucbvax,mcvax,psuvax1,uunet}!udel!mvac23!thomas Europe Bitnet: THOMAS1@GRATHUN1 Location: Newark, DE, USA Quote : Virtual Address eXtension. Is that like a 9-digit zip code? -- The UUCP Mailer
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (10/30/89)
In article <35944@apple.Apple.COM> chuq@Apple.COM (Chuq Von Rospach) writes: >A reasonable analog would be what the Hams do during an emergency. We're >not nearly as well organized as they are, wanna bet? [ 0.5 * :-) ] > but nobody would consider telling >the hams to shut up until the emergency was over. That's not the point. If the hams were tying up the phone lines needlessly they would (should) be told to shut up. The reason the hams start up is because they often have the ONLY communications line (radio) in the first few hours after a disaster. In many areas there are no provisions for guaranteed access lines during high usage periods. This can cause emergency related phone calls to wait in line for a trunk along with the low priority stuff. This is *not* what you want to have happen. During the first few hours after a disaster, nobody really knows what's going on, therefore it's pointless to try to call anyone in the area for information. If everyone *does* call, it's counter-productive since they are just making it more difficult for the emergency response people to do their job, part of which is to determine who is alive (and who isn't) and get that information out to the relief agencies that are set up to distribute it as fast as possible. Of course, all this applies to the dialup phone network. If you have a leased line that's still working, by all means *use* *it*. You'll help cut down on needless telephone calls. (I'm thinking Internet vs. UUCP style connections here.) -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA The Connector is the Notwork.
djaggard@wheaton.UUCP (Deborah Jaggard) (11/04/89)
The Postmaster General's suggestion for the shut-down of USENET lines during natural disasters which would be considered "emergencies," is an excellent idea. It would provide more local power to the area in order that people can call relatives, and important news can be passed on.
jeff@eniac.seas.upenn.edu (Jeffrey M White) (11/14/89)
In article <1371@wheaton.UUCP> djaggard@wheaton.UUCP (Deborah Jaggard) writes: > >The Postmaster General's suggestion for the shut-down of USENET lines >during natural disasters which would be considered "emergencies," is an >excellent idea. It would provide more local power to the area in order >that people can call relatives, and important news can be passed on. In theory this is probably a good idea. However, I question how much difference it will really make. After all, how many usenet sites would be affected (i.e. trying to call into/out of the emergencey area)? 100? 1000? Now compare that to the user population. I can't see that amount getting anywhere near a substantial amount. Jeff White University of Pennsylvania jeff@eniac.seas.upenn.edu
gary@sci34hub.UUCP (Gary Heston) (11/14/89)
In article <1371@wheaton.UUCP>, djaggard@wheaton.UUCP (Deborah Jaggard) writes: > > The Postmaster General's suggestion for the shut-down of USENET lines > during natural disasters which would be considered "emergencies," is an > excellent idea. It would provide more local power to the area in order > that people can call relatives, and important news can be passed on. No, it's a LOUSEY idea. E-mail is a very efficient means of moving a lot of information in a small amount of time. A far more rational plan would be to organize news or sys admins who could queue up a batch of inquiries, send them off to a disaster-area site via a backbone site (to prevent congestion by systems trying to call in, and also probably go thru leased lines or satellite links, not the phone co.) and let someone in the area contact people. Then, a batch of mail can be built up, sent back out to the areas needed, and the net/sys admin can them call and report the contact. I'd have no problem doing that; I'd have LOTS of problems with cutting off the fastest, most efficient, and least loaded communications system when it can do the most good. -- Gary Heston { uunet!sci34hub!gary } System Mismanager SCI Technology, Inc. OEM Products Department (i.e., computers) Hestons' First Law: I qualify virtually everything I say.
dan@ccnysci.UUCP (Dan Schlitt) (11/16/89)
In article <16848@netnews.upenn.edu> jeff@eniac.seas.upenn.edu.UUCP (Jeffrey M White) writes: >In article <1371@wheaton.UUCP> djaggard@wheaton.UUCP (Deborah Jaggard) writes: >> And several others talk about shutting off uucp links. My reading of the articles in Communications Week and other places which describe the planning the various phone companies have done and the things they did during the earthquake make me believe that they are better placed to control the situation. Since we are talking about a very small number of calls in the first place it really won't make much difference in the load. But I suppose that if you want to feel like a hero there is nothing to stop you from closing down your links. -- Dan Schlitt Manager, Science Division Computer Facility dan@sci.ccny.cuny.edu City College of New York dan@ccnysci.uucp New York, NY 10031 dan@ccnysci.bitnet (212)690-6868
adnan@sgtech.UUCP (Adnan Yaqub) (11/22/89)
In article <3743@ccnysci.UUCP> dan@ccnysci.UUCP (Dan Schlitt) writes:
And several others talk about shutting off uucp links.
My reading of the articles in Communications Week and other places
which describe the planning the various phone companies have done and
the things they did during the earthquake make me believe that they
are better placed to control the situation. Since we are talking
Amen! The phone companies have spent lots of dollars building in the
ability to control and manage their network. They have such things as
"cancel to", "cancel from", and "limit operator attempt" controls.
(We have all experienced the "We're sorry, but due to heavy calling
your call did not go through. Please try again later. This is a
recording." messages.) Since they know what the actual load is on the
network, they are in a much better position to apply back pressure to
the system, including back pressuring persistent UUCP links. Why not
just consider our UUCP mail as an application and let the phone
network, as our underlying communications layer, manage the flow.
--
Adnan Yaqub
Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860
...cwjcc!ncoast!sgtech!adnan ...uunet!abvax!sgtech!adnan