Xref: utzoo comp.protocols.tcp-ip:9174 comp.mail.misc:2583 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!ukma!david From: david@ms.uky.edu (David Herron -- One of the vertebrae) Newsgroups: comp.protocols.tcp-ip,comp.mail.misc Subject: Re: MXing the world Message-ID: <13210@s.ms.uky.edu> Date: 12 Nov 89 04:58:12 GMT References: <8911051717.AA10735@alw.nih.gov> <2441@csun.edu> <4902@yunexus.UUCP> Reply-To: david@ms.uky.edu (David Herron -- One of the vertebrae) Organization: U of Kentucky, Mathematical Sciences Lines: 70 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 <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <- <- New official address: attmail!sparsdev!dsh@attunix.att.com