21 Jul
2019
21 Jul
'19
3:03 a.m.
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:
1) 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)
2) *** 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.
3) 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
21 Jul
21 Jul
11:03 p.m.
New subject: Time to restructure the network?
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
22 Jul
22 Jul
2:53 a.m.
New subject: Time to restructure the network?
Hi,
Le 22/07/2019 à 05:03, Michael Fox - N6MEF via 44Net a écrit :
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...
... 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 -- 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.
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.
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.
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.
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
1763
days inactive
1764
days old
2 comments
3 participants
participants (3)
-
Michael Fox - N6MEF -
Rob Janssen -
Toussaint OTTAVI