Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!emory!hubcap!ncrcae!ncr-sd!sceard!mrm From: mrm@sceard.Sceard.COM (M.R.Murphy) Newsgroups: comp.mail.misc Subject: Re: CompuServe backlog; mail servers (LONG) Message-ID: <1990Dec19.150853.10463@sceard.Sceard.COM> Date: 19 Dec 90 15:08:53 GMT References: <1990Dec13.235726.563@jpradley.jpr.com> Reply-To: mrm@Sceard.COM (M.R.Murphy) Organization: Sceard Systems, Inc. San Marcos, CA 92069 Lines: 100 In article karl_kleinpaste@cis.ohio-state.edu writes: [...] >"Never underestimate the bandwidth of a > station wagon loaded with magtapes." > --Unknown, but possibly Bob Sutterfield (Bob?) I heard this as "the fastest way to deliver data across the country is to fill a truck with magtapes and drive it" in the early 1970s. Is it worth calculating to see if this might be the case? I think it was Tom Reidel that said it. [...] > >On the former, I posted the note here both for the information content >so people know why things are delayed, as well as to editorialize on >the evils of MBASes. As a result of the posting, I am informed in >private mail that > [a] Uunet's mail servers will not respond to any but uunet > customers. > [b] Brian Kantor & Co are working on a mail server which > will respond only if there is an IP addr for the origin; > or the address is local-to-UCSD-uucp-host!user; or the > address is uunet!one-machine-hop!user. >I find both of these to be done The Right Way. I find >bitftp@pucc.princeton.edu to be done The Wrong Way. I recognize the problems (evils:-) of MBASes. I think that a major part of the problem is trying to put two pounds in a one pound sack. That is, to try to have a low-bandwith link as the sole path between two high traffic generating entities is likely to be a loser. The solutions are: 1) generate less traffic, 2) raise the link speed, or 3) make more paths. Number one contains the the "kiss off MBASes, they stink 'cause they flood my site" solution. Removing the service is probably the same as pulling the plug on a machine because it is too noisy. Other ways to do this are to raise the price or slow the turnaround or limit the flow. Number two is probably the simplest solution. It may cost money, but it provides new capabilities and a new toy. As always, hopefully it is someone elses money and effort :-) :-( Number three is the artery bypass solution. If a single path is too clogged, as even a high speed link will become if the traffic increases, then new paths for information flow will really help. This also contains the brian@ucsd.edu and uunet.uu.net providing mail server solutions. (Easy for me to say, we're connected to both :-) I think this is the preferable solution, but I'm biased. This brings up what I think is likely to become a Real Problem. Check the UUCP maps. See how often uunet is in a path. They become a real limiting resource as a transport path. They caused, through their excellent service, a network that was distributed to become heirarchical. That is, to send to a site across town, the message first goes through Virginia. This creates a burden that is rather large when the cross-town message is a biggie. It would seem that it might be getting close to time to regionalize uunet. What I mean by this is have uunet distribute its service geographically such that (simplifying to just four regions, and in UUCPmapspeak) uunet-north .uu.net(LOCAL) uunet-north=uunet uunet-south .uu.net(LOCAL) uunet-south=uunet uunet-east .uu.net(LOCAL) uunet-east=uunet uunet-west .uu.net(LOCAL) uunet-west=uunet and have sites in the west hook to uunet-west and such, and have uunet choose best internal routing such that a west-west transfer stays in the west and a west-east transfer doesn't need to go south for the winter. Did I get the simplified example right? Correct it, please. WRT mail, this can be accomplished to some degree by having uunet provide nameservice and MX's pointing to regional centers that handle mail forwarding. This brings up the problem that uunet could probably not survive financially on nameservice and MX alone. It is too valuable a resource to kiss it off. Would regionalization as above help solve what probably will become a problem? Is it already this way internally in .uu.net? Does anyone care? BTW, I know that uunet is now its own, and that this is none of my business except as a concerned customer who likes the service. [...] > [2] The excess stuff starts bouncing back at the originator > due to a "mailbox full" error. (And yes, there are > glitches where it inadvertently returns to the From: on > this error rather than the Sender:. CServe folk are aware > of the problem and will fix it eventually.) >Guess what the latter does to the gateway machine... I'd hope that eventually meant quicker than between trips to the bank to deposit receipts. It would seem that the problems of cis.ohio-stat.edu can be attributed to being the sole, slow-link path 'twixt two large entities. Cut the link and don't think about other solutions :-) Or just provide service for air-letters and don't provide parcel post. Now back to bickering about header rewriting :-) -- Mike Murphy mrm@Sceard.COM ucsd!sceard!mrm +1 619 598 5874