But you also say "There is no need for a portal that registers the
subnets,
they only need to be configured in the gateway routers."
I haven't seen a technical write-up of what you propose. But the
statement
above tells me that those who aren't interested in the putting up
with the
new problems the overlay hubs would create have lost the simplicity
we have
now.
The routing of the subnets is not something the user would have to manage, that is what BGP does automatically. There is no need to register them. Every gateway tells its neighbors what subnets it has locally, and this information is passed around the entire overlay network.
It's easy enough to say things like "you can set up crosslinks to
wherever
you like". But without the central registry, we lose the simplicity
we have
today. Today, we download a file and run a script. Done. Direct connections to everyone else. No middle men. No added latency. No
added
complexity. No added troubleshooting difficulty. No added dependence on some volunteer at the hub who may or may not be available when needed.
As I wrote, to have that it would require an additional protocol like Cisco DMVPN which unfortunately is proprietary and not available in most (if not all) of the inexpensive routers that radio operators want to use.
Now if your proposal included the following, it would truly be solving a problem for some people with causing a problem for others:
- For folks who can't support direct connections, let them use a VPN
connection to a hub of their choosing (as you appear to be proposing)
- *** BUT *** leave the central registry in place, and augment it so
that
when you sign up for a hub, your subnets are still published to all other gateways as reachable through the hub.
- Therefore, those who can support direct connects but are not a hub can
still see a full registry and automatically create direct
links/tunnels to
all other gateways (whether they are individual gateways or hub gateways) and routes to all subnets behind all other gateways.
I think the minor problem of "now some paths are two hops while they would have been direct in the current system" is very minor compared to the many issues there are with the current system. When we want a system that anyone can easily connect to without being a network export, the system I propose provides that. When you do not want that, because it takes away the artificial hurdles "that everyone has to overcome", of course you could object to such changes. It is similar to the situation of no-code licenses. People who already had passed the CW exam were objected to removing the requirement for new licensees, with similar reasoning.
Again, while there are over 500 gateways in the current network with tunnels between all of them, there is no way they are all going to be in use. Wiring them up for everyone really makes no sense, and introduces a scalability problem that would become real when it were easier to use the system and we had like 50000 participants instead of 500. A system with regional hubs, while still offering the capability to cross-connect, is much more extensible.
Cross-connects require manual intervention because the situation has to be examined. As the new system does not require the IP address of the participants to be static, allows them to be behind NAT, behind a firewall, etc, it has to be decided what type of connection is made, which direction the connection is made, etc. E.g. when one of the two has a static address and the other one dynamic, it is best to connect from the dynamic to the static address (and re-make the connection when the dynamic address changes). When they are behind NAT, it is possible to use a VPN that can cross NAT. Right now, such stations simply cannot participate, and with a new system they can.
Rob
Rob,
I think the minor problem of "now some paths are two hops while they would have been direct in the current system" is very minor compared to the many issues there are with the current system.
Then you weren't paying attention this past week. The spectacular failure of the volunteers who manage DNS to speak up and address the problem (with ARIN, as it turns out) was astounding.
Again, I have yet to see a written proposal of what you're trying to do. I can only guess, based on what you've said in emails. And from what you have said, you would eliminate the central portal, which would dismantle the existing mesh and force all connectivity to pass through hubs managed by people with no service level agreement with those they serve. I certainly want no part of that.
When we want a system that anyone can easily connect to without being a network export, the system I propose provides that.
Maybe. It also creates a bunch of problems, which you STILL haven't addressed.
Also, you haven't identified the problem you're trying to solve. It would help to have a clear statement of the problem.
When you do not want that, because it takes away the artificial hurdles "that everyone has to overcome", of course you could object to such changes. It is similar to the situation of no-code licenses. People who already had passed the CW exam were objected to removing the requirement for new licensees, with similar reasoning.
Completely wrong. Nobody is objecting to adding new folks, perhaps using a different technology. I already said I'm for anything that's more standard and easier. But you're ALSO proposing doing away with the existing connectivity. That's throwing the baby out with the bathwater.
As you say below, there are over 500 gateways working just fine. But to offer connectivity to others, your proposal would presumably remove the existing connectivity from all of the existing sites, and force them to go through some hub somewhere (typically two - one at each end). That's a big step back for the 500 existing gateways.
Again, while there are over 500 gateways in the current network with tunnels between all of them, there is no way they are all going to be in use.
It doesn't matter how many are in use. If my ampr routing table has 50 or 500 or 5000 routes, who cares?
What matters is that anyone can register on the portal, and after the next update (RIP-44, file download, whatever), all other gateways will automatically be configured with a tunnel to the new gateway/subnet. No one has to do anything. And if there is a problem, the two endpoints can diagnose directly. tcpdump on each end is all you need.
Wiring them up for everyone really makes no sense, and introduces a scalability problem that would become real when it were easier to use the system and we had like 50000 participants instead of 500.
Do you have evidence for your statements? https://qrznow.com/us-amateur-radio-population-grows-slightly-in-2018/ It looks like from 2014 to 2018, the US ham population only grew 4%. And I haven't monitored it closely. But it seems to me that the size of amprnet has remained about the same (+/- 100 or so) for the last 10 years. So who/where are these 49,500 other gateways? Why would a bunch more tunnels be a problem?
A system with regional hubs, while still offering the capability to cross-connect, is much more extensible.
I heard you the first time. But you still haven't addressed the problems they introduce: -- increased latency and jitter -- increased troubleshooting complexity (no end-to-end troubleshooting by the two endpoints) -- very few existing gateways will have a BGP connection to their ISP, so most will lose direct connectivity to other gateways and be at the mercy of some hub operator somewhere -- hubs are operated by volunteers with no service level agreement with their users, no consequences whatsoever if they don't want to help during dinner or when they are out at a movie or sick or on vacation or whatever. No consequences if they simply decide they don't want to do it anymore.
Cross-connects require manual intervention because the situation has to be examined.
But they don't today. Register your subnet and gateway with the portal and all other gateways will be configured on the next update (RIP or file). And they don't require any middle-men/hubs in between. Yet your proposal would presumably throw all of that away and force everyone through hubs. Those who don't want that would be left to figure out some other manual cross-connect solution on their own.
BOTTOM LINE:
1) If you want to provide a solution for folks who can't use IPIP, then that's awesome. Go for it. Build a hub (or multiple hubs) and offers VPN connections or whatever/however you want. In fact, I think some people already do that.
2) Getting started on the IPIP mesh is difficult. So, if you have a better solution for **DIRECT** connections than the existing IPIP mesh, then let's hear that. But once you're up on the mesh, there's literally nothing to do and it works great. So until you have a better solution for **DIRECT** connections, it makes no sense to destroy the direct connectivity that 500 gateways currently enjoy, along with the automated configuration, ease of troubleshooting, etc. and, above all, ZERO dependence on some other volunteer's operation of a hub.
Michael, N6MEF
Hi,
Le 22/07/2019 à 05:03, Michael Fox - N6MEF via 44Net a écrit :
... force all connectivity to pass through hubs managed by people with no service level agreement with those they serve. I certainly want no part of that
The purpose, art least for now, is not to remove anything, nor to force anybody. The purpose is to test newer things. We are still discussing about what would be possible or not. Some of us are using such "different" things in their region. We are trying to see if we can normalize that.
Also, you haven't identified the problem you're trying to solve. It would help to have a clear statement of the problem.
For me, the main problem is IP-IP : - Non-standard implementation, requiring specific software (not a real problem, anyway) - No security at all (password sent in plain text) - Difficult implementation for non-experts. It requires a "protocol redirection" on the Internet box. With some operators, while it's possible to redirect a "port", redirecting a "protocol" is simply impossible.
Here, we are using a "Plug and Play" TKbox : the end-user just connects it, and it works, whatever the operator, the technology or the Internet modem. It even works through 3G, or in some locations where "low points" are gracefully hosted by third-party partners on their business networks.
A system with regional hubs, while still offering the capability to cross-connect, is much more extensible.
I heard you the first time. But you still haven't addressed the problems they introduce: -- increased latency and jitter
Not necessarily. This depends on the placement of the gateway, and the way the Internet operators built their networks. Moreover, I'm living on an island where 35ms is the minimal latency for any Internet link, which means 70 ms for point-to-point. Even if we'd like to reduce it, and we are doing investments for that, a high latency does not seem to cause critical problems. We have VoIP with different technologies connected (analog, D-Star, DMR, Echolink), and it works...
-- increased troubleshooting complexity (no end-to-end troubleshooting by the two endpoints)
Again, not necessarily. The operators of the gateways are usually skilled network specialists, which may greatly improve troubleshooting. Moreover, we are not talking about preventing people from building point-to-point communications ! We are just thinking about al alternate way that would be plug-and-play, and more easy to use for non-specialists.
-- very few existing gateways will have a BGP connection to their ISP, so most will lose direct connectivity to other gateways and be at the mercy of some hub operator somewhere
Anybody can create a hub. The idea is to have more hubs all over the world. Any end-user can connect to the hub of its choice. In the ideal situation, it would connect to several hubs, with redundancy between them (for ex, a "regional" hub, and a "national" hub with lower priority). Nobody will be at the mercy of nobody. Everybody will be able to do what he wants to do (and not what other people decided for him).
Moreover, about BGP, we already talked about solutions very easy to implement for $5/month at vultr.com.
-- hubs are operated by volunteers with no service level agreement with their users, no consequences whatsoever if they don't want to help during dinner or when they are out at a movie or sick or on vacation or whatever. No consequences if they simply decide they don't want to do it anymore.
To avoid that, you just have to connect to several hubs. Or build your own in your area. If we agree on some kind of normalization for our hubs, setups will be well documented, and more easy to implement for any volunteer.
Anyway, hubs will not replace direct mesh between users. It's just that, for now, we don't know how to do mesh in a PnP manner behind an end-user Internet box. Any idea is welcome.
- If you want to provide a solution for folks who can't use IPIP, then that's awesome. Go for it. Build a hub (or multiple hubs) and offers VPN connections or whatever/however you want. In fact, I think some people already do that.
Yes, some of us are already doing that, and it works well :-) We're now trying to normalize our technologies, so that we can inter-operate more easily, and that such hubs become more easy to built by local / regional teams.
- Getting started on the IPIP mesh is difficult. So, if you have a better solution for **DIRECT** connections than the existing IPIP mesh, then let's hear that. But once you're up on the mesh, there's literally nothing to do and it works great. So until you have a better solution for **DIRECT** connections, it makes no sense to destroy the direct connectivity that 500 gateways currently enjoy, along with the automated configuration, ease of troubleshooting, etc. and, above all, ZERO dependence on some other volunteer's operation of a hub.
We don't want to destroy anything :-) We're just trying to displace the technical difficulty from the end-user to a local team, and doing mesh between gateways (which may easily have networking capabilities such as fixed IP, BGP, and skilled people). Most of end-users are not capable, or don't want to bother, with IP-IP. If the user has a problem with its IP-IP configuration, he will call... you ! So, your zero-dependancy argument is wrong, HI :-) Why are so much D-Star or DMR repeater sysops connecting their machines directly to Internet ? Because AMPRNet / HamNet is too difficult, and they don't see any reason to bother with it !
Our first networking attempt here used IP-IP on an ADSL box, as a low-point to feed a repeater on a high point. One week later, it stopped working. The QRP had latency on its gaming system, he called the ISP, and it reset the Internet box, which killed the IP-IP protocol redirection :-( That's what decided us to try something else, and that's what we did with TKBoxes.
73 de TK1BI
-
Michael Fox - N6MEF -
Rob Janssen -
Toussaint OTTAVI