I propose to speak for a while about the routing of private mail in the UK, then throw it open for discussion.
Over the past few years, many Packet BBS's have closed down, and as a consequence, the forwarding of personal mail has become increasingly unreliable.
Although bulletins reach virtually every BBS, a significant proportion of private mail is being bounced, killed or lost, and never reaches its intended recipient.
Confidence in the system has reached such a low point that users are either corresponding by bulletin, or are abandoning Packet in favour of email.
When a traffic handling BBS is removed from the network, the immediate neighbour sysops have to re-arrange their forwarding in an attempt to circumvent the outage. This may involve routing through extra BBS's and requires a lot of sysop co-operation, introducing the potential for errors.
If successful, the rest of the network will remain ignorant of the change. However, if the outage cannot be circumvented locally, the disruption may spread far away, requiring many more sysops to take remedial action. In some cases, traditional mail routes become unviable and completely new routing is required.
Sysops far removed from the area may not be aware of the problem, and may continue to route mail towards the unviable route. This will cause the mail to be ping-ponged at some point. The sysop must then inform the peer who sent the mail, who must inform the next sysop, and so on back to the point where the mail was misrouted. All these sysops must fix their routing before the stuck mail can be given a new MID and released. Even then, the mail is likely to get stuck again because the intermediate BBS's will detect that they have handled the mail before. If there is a large volume of mail, the problem is likely to get noticed and fixed, but the occasional ping pong may simply be dismissed without investigation.
This problem has always existed, but now there are fewer BBS's, the loss of one has more effect.
The reason for this situation is, I believe, a result of fundamental flaws in the store and forward system we use.
Store and forward was the only viable method of moving mail when the BBS network first began, and in many places that’s still the case. However, the addressing system used in the UK was fundamentally flawed from the outset.
Firstly, it didn’t take the topology of the underlying infrastructure into account.
Secondly, it required close cooperation between sysops to set up mail routing.
And lastly, it required sysops to have intimate knowledge of routing outside their own area.
I will now explain these statements in more detail...
The assumption was that, to route mail, all you needed to do was send it to a BBS closer to the hierarchical destination address. The UK was divided into 7 geographical regions, each consisting of up to 9 county-sized sub regions. Outside a region, BBS's could use wildcards to forward towards that region. Within the region, BBS's would route on the sub-region, and within the sub-region, BBS's would forward on the destination BBS callsign.
Unfortunately the geography of the UK, the locations of the BBS's, and animosities between some sysops or packet groups made this simple idea unworkable in some areas. For example, Region 5 (Wales) is mostly mountainous, with the majority of its BBS's confined to the coastal strips on the North, West and South sides. There was no connectivity between North and South Wales, thus mail for North Wales had to be routed via Region 1 (North-West England), and mail for South Wales had to be routed via Region 4 (South-West England). Sysops far removed from Wales, who should ideally have been routing on region 5 alone, were in fact required to route on the Welsh sub-regions. Even worse, they all had to agree, otherwise mail would have ping-ponged.
Similar situations occurred to a lesser degree all over the UK, due to obstructions such as the Pennines, the Mendips and Dartmoor to name but a few. Even in relatively "flat" regions routing was distorted due to the relative locations of the BBS's and the scarcity of RF links, so it was very common to have different parts of a region routed through different neighbour regions, and no communication within a region.
The situation was just as dire for foreign mail. There were a handful of Satgates, HF forwarding links and cross-Channel VHF links, and very few sysops knew exactly which gateway the mail for any given country should be routed to.
If one sysop thought mail for Spain should be routed south towards a cross-Channel link, whilst the next sysop thought it should be routed North to a Satgate, and someone else thought it should be routed West to an HF gateway, the chances are that the mail would never arrive.
This need for every sysop to agree on routing is crucial, and I will refer to it again later.
Although we have lost a lot of the BBS’s and infrastructure, in my view we still have sufficient resources to maintain an effective mail network. The problem is, the resources aren’t being used properly.
The mail system is a total anarchy. There is no-one in control, and each BBS is an equal peer, free to do more or less as they please. In some ways that’s a good thing. It’s a hobby system, with varying degrees of skill and commitment, and we shouldn’t try and tell people what to do. On the other hand, there are sysops who perhaps need some sort of guidance.
An anarchy can work, providing everyone has a sense of what they should be aiming for. We can’t *tell* people what to do, but what we should do is give then the information to do it for themselves. That’s what’s missing.
Forwarding files are usually set up by local agreement, without knowledge of the wider picture. But there *is* no overall plan. As far as I know, no-one has drawn up a map of the BBS’s, their relationship to the infrastructure, the preferred forwarding routes etc. There isn’t even a decent up to date list of the active BBS’s and their sysop’s contact details.
To me, there now seems to be a lack of interest in the system. Sysops are not keeping each other informed - how often do you see a SYSOP @ GBR bulletin these days? The chances are, it contains nothing meaningful and few will read it anyway. We don’t even have sysop meetings any more, this conference is our only opportunity to get together.
One possible solution is automatic routing, and it’s something we could think about for future BBS software, providing sysops are willing to relinquish control of the forwarding files, which in this country seems unlikely. I started to work on a system to retro-fit to FBB, but that’s on the back burner for now.
We need fixes *now*, before the remaining users abandon ship. We don’t need to throw technology at the problem. The most effective thing we can do, which requires no technology at all, is simply give sysops the information to set up their forwarding files effectively. I propose we do this by maintaining some sort of national mail routing database and making the information readily available, perhaps on a website and by REQFIL.
The greater the number of systems handling a piece of mail, the greater the chance for it to get lost or killed due to misrouting, equipment failure or a sysop with a grudge. Therefore we should attempt to minimise the number of systems through which mail must pass.
This can be done by using the Internet whenever possible, to get the mail as close as possible to its intended destination with the fewest hops. This would have the additional benefits of removing some traffic from the overloaded RF links, and getting the mail through faster.
There are a growing number of BBS’s telnet forwarding via the Internet, and the network infrastructure itself is becoming increasingly connected via the Internet. So there is plenty of potential to move mail this way. However, Internet forwarding is currently rather un-coordinated.
Since there are so many potential forwarding partners, Internet sysops tend to forward mainly with their friends. There is considerable duplication of effort, and no overall plan. This results in massive redundancy to some areas, whilst others are left devoid of mail. For example, there could be 5 UK BBS's forwarding to a well known BBS in Las Vegas, yet no-one forwarding to Michigan.
Internet forwarding is a good resource, used badly.
In the ideal world, all BBS’s would be connected to the Internet, or a fast, reliable global packet network, and would be able to forward directly with any other BBS. Thus mail could be delivered directly from the sender's BBS to the recipient's BBS. It would be fast, and there would be less chance of mail getting lost.
Although that situation is unlikely ever to occur, it highlights an important issue, namely the number of possible forwarding partners. There are perhaps 100 BBS's left in the UK, and many thousands throughout the world, so it would be impractical for each sysop to maintain a forwarding file containing so many partners, even if the software was capable of it.
The number of forwarding partners for each BBS can be reduced by organising the BBS's into a pyramidal hierarchy, where each tier contains a manageable number of peers. The addressing scheme is already hierarchical, so it’s just perfect for the job.
This sort of hierarchy is not easily possible with RF-only BBS's, but is ideally suited to Internet-connected BBS's, because they are not restricted by geography. However, as the connectivity of the node network is improving all the time, an increasing number of RF BBS’s have access to each other.
In practice, we have a hybrid network consisting of RF-only BBS's which must continue to use existng mail routing methods, plus Internet-connected BBS's which can be organised into a hierarchy according to the sysop's aspirations.
What I am advocating is a tiered "agency" system as follows:
Any internet-connected BBS which can forward *directly* to all the BBS's in a given area can declare itself to be a mail agent for that area, and that fact is recorded in the routing database so that all sysops are aware of it. A BBS can *not* claim to be an agent for any BBS it does not have a direct forwarding arrangement with.
There can be more than one agent for an area, and a BBS is allowed to be the agent for more than one area.
Any Internet-connected BBS which needs to deliver mail to a particular area would simply forward it to the agent for that area. If it doesn't have a direct forwarding arrangement with that agent, it would forward the mail up to the next tier of the hierarchy.
In this context, an "area" can be of any size, e.g. a single BBS, a region, a whole country, or even a continent. An area may consist of a collection of smaller areas.
For the UK, I suggest a 3 tiered system based on the hierarchical addressing codes. At the bottom tier would be the sub-regional agents, serving a small number of BBS's in one county, e.g. #24. The next tier would consist of regional agents, responsible for a whole hierarchical addressing region, e.g. #2. The top tier would be the national agent(s), responsible for the whole GBR.EU address space.
For example, GB7PZT is internet-connected and also forwards directly via RF to all BBS's in sub-region #24. It can therefore declare itself to be the mail agent for #24. Anyone who wants to send mail to #24 can send it to me, knowing that I can deliver it. Similarly, Internet-connected GB7MAX could declare itself to be the agent for all #28. If GB7PZT has mail for anyone in #28, it can forward it to GB7MAX, knowing GB7MAX will deliver it. Similarly to forward to #16, I would simply forward to the #2 regional agent, who passes it on to the #1 agent, then down to #16 and so on.
Note that the connectivity within each tier need not be complete, and there is bound to be a lot of connectivity between individual BBS’s at local level. It doesn’t matter, providing all the BBS’s in one tier are connected to the tier above.
At first sight it might seem as though the higher up the hierarchy, the higher the traffic load. This is not necessarily true, because most traffic should be exchanged at lower tiers. The only time a higher tier gets involved is when there is no direct forwarding link at the current tier.
Traffic may enter the hierarchy at any tier, so there is plenty of scope for any BBS's to link with any other, regardless of position in the hierarchy.
These are the Internet connected BBS’s I know about. There are probably others which I’ve forgotten to include. I’m not aware of them all, and that’s the point I was trying to make earlier - information is the key.
As you can see, we have at least one in almost every UK region, and in the middle of the country no-one is very far from an Internet BBS. Why can’t we make more use of them? All it takes is a bit of organisation. If these BBS’s would let us know which areas they can serve with a high degree of reliability, we could adjust our forward files to make efficient use of them. Maps such as this should be on a central resource.
Of course, some of these BBS’s may not wish to be used. Every sysop is different. Some are quite happy to be in the thick of things, others just want a quiet life.
The packet purists will say we shouldn’t use the Internet for forwarding, but I’m afraid it’s already happening, so we might as well make sure it works to our advantage.
None of this will work unless we have some way of sharing information.
The information needs to be made public in a well known place, such as a web site. It should also be available to those without the web, via REQFIL or other packet means.
The data could be updated directly by the sysops, using secure web forms. The problem with this is that sysops would probably forget to update the database if they changed their forward files. So the information manager could periodically ask the sysops to supply details.
It would be quite easy for the agents to each run a utility at housekeeping time, which scans the forward file and updates the central database with any changes.
In addition to the website, a text version of the routing information could be sent periodically to SYSOP @ GBR.
Now it’s your turn to have your say. Are these ideas worth pursuing, or shall we just carry on as before. Does anyone have a better scheme?
(pzt.org.uk/nts/ if no-one else wants to do it)