[pskmail] Re: Server to Server Mail Routing Algorithm Ideas
- From: Rein Couperus <rein@xxxxxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Thu, 11 Oct 2007 22:08:46 +0200
These are interesting ideas.
In the background I am working on a mixed-medium (internet & HF) Delay Tolerant
Network for information delivery. This would be based on 'agents' like the ones
already living in the pskmail server (but much more clever), which will deliver
messages to an addressee either on the internet or on a known server.
They accompany the message from node to node, and when that node does not have
that capability they will create that locally (if necessary carrying the code
to perform the service). Routing information is sent via the internet wherever
available and through HF where no internet connection is present. If you are
running a server you will have seen messages like "SM0RWO GATING PE5YES,
dropping PE5YES from record".
This tells all servers connected to the APRS backbone that PE5YES can be
reached via SM0RWO.
Using an opportunistic medium approach has the advantage that routing
information on HF can be kept to a bare minimum. My ultimate goal is to also
press the clients into service if there is no route via a server. The clients
would then receive a request from an agent carrying a message, if necessary
acquiring the code necessary to run that agent locally as if it was in a server.
The main problem with such an approach is the bandwidth taken away by sending
routing information.
Most opportunistic mesh systems use a system based on flooding the complete
mesh with routing information, to give every node a picture of the whole
network. I have tried this out during the last Chaos Computer Camp, and it
worked for the 54 Gb Wifi network present there. My pskmail worm hole was
faster most of the time though. The routing algorithm they used was simple.
Every node sent a beacon, and that beacon was relayed by every node receiving
it, stating source node and relay node (not the whole path like in Packet
Radio). With 50 nodes on the same 54 Gb channel his resulted in about 5% of the
beacons reaching the edge of the network, 95% were killed by collisions. And
there was not much channel capacity left for data.
The routing table said that the beacon from PA0R was received from SM0RWO (3x)
and PI4TUE (25x). The route was then chosen as to send stuff for PA0R via
PI4TUE.
See http://events.ccc.de/camp/2007/Fahrplan/events/2039.en.html for a short
description of the BATMAN algorithm. This is the best I've seen so far, but it
needs lots of work to make it suitable for a 125 Hz wide channel.
The quintesence of all this is that we should try to keep as much traffic on
the internet as possible and use the HF channel mainly as an access mechanism.
This channel with its typical Ham Radio Characteristics:
* Pactor or JT65 qrm, or the new 'Robust Packet Modem' from SCS, just settled
on 10148.750,
* deliberate jamming (yes, they even follow the scanning of the server if
necessary),
* 4 hours of OTH radar with S9+20dB (this morning on 30m),
* your neighbour's vacuum cleaner,
* 140 campers in a car park all charging their batteries with switchers,
is difficult enough to manage as it is, and UNAVAILABLE for great lengths of
time. Hence the Delay Tolerant Network characteristics, which will persistantly
try to deliver the stuff and wait until the channel comes back.
Do not forget that HF allows to span enormous distances. In our camper site in
Honfleur, France, I could work equally well via IS0GRB-3 and SM0RWO on 30m.
These are distances of 1000 and 2000 km. The footprint of these nodes is
enormous, provided you have optimized your equipment for psk125.
You were just reading my ideas about pskmail v. 2.0 (we now have 0.5
remember?).
73,
Rein PA0R
> -----Ursprüngliche Nachricht-----
> Von: pskmail@xxxxxxxxxxxxx
> Gesendet: 11.10.07 02:18:02
> An: pskmail@xxxxxxxxxxxxx
> Betreff: [pskmail] Server to Server Mail Routing Algorithm Ideas
I was thinking today about an algorithm for mail delivery once a
> server-to-server protocol is developed. Here's some thoughts I jotted
> down on "paper":
>
> Needs/Requirements
>
> - The server to server mail delivery protocol should work independently
> without an Internet connection, central control, or central database.
> Also, server nodes should be able to be added or deactivated on an ad
> hoc basis.
>
> - While PSKmail is currently geared towards using Internet POP
> accounts, mail may also be hosted directly on PSKmail servers. This
> functionality could be valuable during disaster situations and/or when
> Internet connectivity is not available. There needs to be a way that
> mail for local server accounts can be delivered to the server when that
> server's Internet connection is down.
>
> - Source routing is...evil. "Over-the-air" (local server) email
> addresses should never require source routing nor should the capability
> exist.
>
> - Any exchange of routing information needs to consume very little
> bandwidth and be very simple. Fast convergence is not requirement, but
> should be responsive enough to change with propagation changes.
>
>
> Basic Mail Routing Algorithm Idea
>
> Is the email destination
> domain local?
> |
> + YES: Deliver locally
> + NO: Does an MX record exist in DNS for the email destination domain
> name?
> |
> + YES: Attempt delivery to MX server via the Internet; was it
> successful?
> | |
> | +YES: DONE
> | +NO: Is there an over-the-air route (looking at
> beacon table)?
> | |
> | + YES: Send email via server-to-server
> protocol to the best route
> | + NO: Queue mail and start at top of
> process again in X minutes
> |
> + NO: Is there an over-the-air route (looking at beacon table)?
> |
> + YES: Send email via server-to-server
> protocol to the best route
> +
> NO: Queue mail and start at top of process again in X minutes
>
> - Server beacons would broadcast what mail domain names they can
> accept email for, and how many hops away the destination server is.
> The server configuration should have a setting to limit the domain
> names they broadcast by hops away (i.e. 0 = broadcast only domains
> hosted on the server, 1 = domains one hop away, etc.). The server
> should indicate "internet" as a route if they are currently connected
> to the Internet. (The server software should dynamically remove this
> route if the Internet connection goes down.) Essentially this is a
> classic vector-distance routing algorithm.
>
> Example server routing table (at server K1ABC):
>
> server node | domain | hops
>
> K1ABC k1abc.org 0
> K1ABC internet 0
> K2XYZ quirkyemail.com 0
> K2XYZ internet 0
> W3AB quirkyemail.com 1
> W3AB k1abc.org 1
> W3AB w3abmail.com 0
> W4XYZ internet 0
>
> (all callsigns and domain names are fictitious and randomly chosen)
>
> In this example, K1ABC is currently connected to the Internet, hosts
> k1abc.org email locally, and is "beaconing" two routes over the air.
> K2XYZ is beaconing two routes and hosts mail locally for
> quirkyemail.com. W3AB has no Internet connection, but he can "hear"
> K1ABC and K2XYZ and is set to relay email one hop away, so he's
> beaconing the two routes for the other servers he can see, plus he's
> hosting mail for w3abmail.com. W4XYZ hosts no mail locally, but has an
> Internet connection and beacons that as his only route.
>
> -Functionality could be added later so that servers can have multiple
> MX records in (Internet) DNS with secondary lower priority entries
> pointing to other PSKmail servers. If the Internet connection goes
> down to the server hosting the email for a domain, SMTP servers on the
> Internet would deliver the mail to other PSKmail servers who will try
> to deliver the mail over-the-air to the destination server.
>
> -If clients could not reach an Internet-connected server to access a
> POP account hosted somewhere on the Internet, they could send a "mail
> redirect" command to whatever server they could hit over the air and
> indicate an alternate email address (most likely a locally hosted
> account on that server). The server receiving the mail redirect
> request would forward it to a PSKmail server in its routing table that
> is Internet connected. That server would access the POP account and
> re-mail the email to the address indicated in the mail redirect
> request. For example (using the above routing table example):
>
> Client VE1ABC can't get to an Internet-connected PSKmail server to
> retrieve email from someaccount@xxxxxxxx He sends a redirect request
> to the W3AB server requesting someaccount@xxxxxxx, POP passwd:
> letmein123, redirect to ve1abc@xxxxxxxxxxxxx The W3AB node sends the
> redirect request to the K2XYZ server who's in his routing table and
> Internet connected. The K2XYZ server retrieves the mail and forwards
> it to ve1abc@xxxxxxxxxxxxx It follows the routing algorithm above and
> since the MX server isn't reachable over the Internet, it will revert
> to the server-to-server air protocol and transfer the mail to the W3AB
> node. The W3AB node follows the routing algorithm and delivers the
> mail to the local POP box. VE1ABC then picks up his email from the
> local mail account on the W3AB node.
>
> Anyway, just some ideas I had....comments welcome...
>
> 73
> Goody
> K3NG
>
> -- Blog: http://thek3ngreport.blogspot.com/
>
--
http://pa0r.blogspirit.com
Other related posts:
