brian@ucsd.Edu (Brian Kantor) (11/10/89)
I have in MY nameserver the following for the bitnet "top level domain". Because there is no record in the root nameserver pointing at me for ".bitnet", this is not advertised to the outside world, but it allows my mail system to treat "user@host.bitnet" just as it would any other domain-type mail. Because I assign these hosts equal priority (and because sendmail-5.61 randomizes usage of equal-priority MXs), my limited amount of bitnet traffic gets spread between the several gateways I have listed. (I think there are more internet->bitnet mail gateways but these are the ones I know about.) This is a real hack but it works real well for me. I don't see why this couldn`t be done internet-wide but I suspect the reason is other than technical. Is that true? - Brian in the boot file: primary bitnet bitnet in the 'bitnet' file: @ IN SOA ucsd.EDU. brian.ucsd.EDU. ( 880506 7200 1800 2419200 86400 ) * IN MX 10 cunyvm.cuny.edu. * IN MX 10 mitvma.mit.edu. * IN MX 10 uicvm.uic.edu.
david@ms.uky.edu (David Herron -- One of the vertebrae) (11/12/89)
There's a problem that's been floating around in the back of my head
that's partly politics and partly graph theory. I've never come
to an acceptible answer ...
It's this
suppose you have >= two computer networks which are described with
a weighted directed graph. (er.. come to think of it, the real world
example includes a net that isn't weighted or directed. at least from
the e-mail point of view). These networks actually have multiple
physical connections between themselves, but little-to-no coordination
of routing between themselves.
Now ... how do you pick the "shortest" and/or "best" route between
any two nodes on this conglomerated network?
In (almost) all cases all a site knows is that the destination site is
on another network, due to MX records this isn't always known. What
is always known is one-or-more gateways to use. All the site knows
is the "weight" to reach the gateways. It doesn't know the weight
from each of the gateways to the destination, and it doesn't always
know an actual weight to the gateways.
(In MX records, there's a weight of sorts attached to each gateway.
However that weight isn't related to the topological distance between
the nodes. Therefore it's not a useful weight in figuring out
which is the closest gateway to the sender ...)
For instance ... if you're on UUCP going to BITNET you only know
the closest BITNET gateway. All your BITNET mail goes over to that
gateway even though it might be better to send some BITNET mail to
one gateway and some to another. On BITNET there's some links near the
"center" of the net which are chronically overcrowded. It'd be
best in terms of reliability and transmission times if ... well,
your gateway is going to be on one side or another of the "center"
of BITNET. If your routing software somehow knew which side your
target was on then it could pick an appropriate gateway.
This would become easier if BITNET & UUCP were to exchange weighting
information back and forth ... each network has a pathalias-like tool
(program for calculating spanning trees of a weighted directed graph).
In a previous message I suggested a method whereby BITNET information
could be distributed in the Usenet maps. Specifically for each gateway
list all the BITNET nodes along with weights from that gateway to the
particular node. Hopefully a good criteria for calculating the weights
could be come up which would weigh in both the actual distance and
normal traffic loads on that section of BITNET.
It's more complicated on the Internet since MX records, or anything
else for that matter, doesn't give you any indication of reachability
between any two nodes on the Internet. The Internet likes to
pretend that all sites are equally reachable, which just ain't
so. For instance, from SURAnet most of MILnet is basically unreachable.
The normal RTT for ping packets is on the order of 1.5 to 3 seconds,
which just ain't good.. Keep alive mechanisms start failing at that
sort of RTT times ... (unless you're using Phil Karn's TCP/IP code :-)).
Anyway, this is a bunch of incompleted thoughts and I apologize if
this seems rough around the edges. It's been awhile since I've
had the spare time to think about this problem, and it is somewhat
late right now. (gosh, back when I was a student this was certainly
not a "late" time of night -- it's only midnight :-)).
--
<- David Herron; an MMDF guy <david@ms.uky.edu>
<- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-
<- New official address: attmail!sparsdev!dsh@attunix.att.comlear@GENBANK.BIO.NET (Eliot Lear) (11/12/89)
A problem with .BITNET is that there is indeed a lack of granularity. This would seem to me to be a strong reason for BITNET hosts to get real domains (as it seems they have been). -- Eliot Lear [lear@net.bio.net]
tneff@bfmny0.UU.NET (Tom Neff) (11/13/89)
Perhaps, instead of trying to pre-guess the weighting of the world, we could dynamically exchange weighted volume-carried information between all nodes and gateways before transmission begins. This way you would have a constantly self-adjusting network. -- There's nothing wrong with Southern California that a || Tom Neff rise in the ocean level wouldn't cure. -- Ross MacDonald || tneff@bfmn0.UU.NET