🚀 go-pugleaf

In article <KARL.90Dec17233700@giza.cis.ohio-state.edu> 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