Are yiu sure it was a bandwidth throttle and not a cpu throttle ?
Yesā Iām sure. The VPSās were fine for weeks and then both were throttled. Could not get records when when new nodes were started. Iāve been monitoring CPU usage.
The Netcup VPS would pick up 900 records in a few minutes when a new node was started. Contabo which was working fine for weeks about 5 days ago would only pick up 5 to 15 records when a new node was spun up. This was for both Contabo VPSās
Iāve been wondering if the sheer volume and frequency of Autonomi traffic is enough to bring unwanted and unwarranted attention to the network. Is it that much greater than other UDP traffic and does it stand out to automated and human traffic monitors? Maybe it looks like someone is probing different servers in the eyes of the safety personnel at ISPās, VSPās and others.
If so, it might be worthwhile to investigate the possibility of reducing the number of connections the software makes, if it can be done without compromising the performance of the network.
2 Likes
Most of internet traffic is TCP, UDP is relatively rare (19%) and most of it are well known services like Zoom or MS Teams. Combination of UDP, unknown service and communication to hundreds of different IPs can raise some eyebrows.
But we are not doing anything wrong, it is completely legitimate traffic. If someones threat detection system is too paranoid, he needs to change it, it is not reason for us to change the network.
5 Likes
That accusation of doing udp port scans on random completely uncommon ports is so ridiculous anywayā¦
3 Likes
I had 3 VPS servers in the last testnet. Both providers accused me of malicious traffic. When I explained what I was doing they turn my servers back on. One accused me of running a bot net. My home ISP which is comcast unlimited hasnāt been bothered.
2 Likes
The reason why we should think about altering the algorithm is that Autonomi adopters are being threatened with termination of their internet accounts. That, after possibly spending a not-so-inconsiderable amount on equipment to support the testing of the network. In some cases, there is no other game in town, if your account is suspended by the one and only ISP, youāre out of luck, along with the rest of your family.
1 Like
But do we really want to put a lot of early adopters in a position of having to defend use of a network they might know little about? That is the kind of thing that could give Autonomi a black eye right from the start.
1 Like
Iām in agreement. New users should start nodes in a set and forget way. Having them get flagged and explain they are doing nothing wrong is not good for adoption.
It would be great if traffic could blend in more with normal ISP traffic. Iām not sure how feasible that is at this point.
Running only a couple of nodes, 5, 10, will fly under the radar so most users will be just fine. Those who run hundreds will have to defend themselves or move to a different cloud provider.
Canāt wait for autonomi IPV6 support!
6 Likes
I assume you have considered something like this for network level connection:
re: PKT Cash link:
peer-to-peer network that bypasses traditional ISPs
That sounds like magic ā¦ if you are using a mobile device close to other mobile devices, then sure, you can mesh and skip over ISPās, but thatās not realistic for stable connections and especially for connections with everyone else in the world - you canāt get very far before having to go through an ISP.
So for people running nodes itāll have to be through an ISP - sadly, there is no magic.
Running a small number of nodes though shouldnāt trigger any event with an ISP I think - only those hosting a large number - and if they are doing so, then likely a professional node runner and they can afford the time to do things like setting-up blocklists to prevent connections with ISPās that cause trouble.
@dirvine - perhaps we can incorporate a blocklist system and then people can submit IP addresses that are causing trouble to a community maintained blocklist. Even my torrent client has such built-in.
1 Like
The point here is not the hardware cjdns (pkt network protocol) runs on. It can be used over ethernet UDP, which is enought.
But the point is that even with only one connection to network, you can reach every other node in very efficient way; network itself finds the optimal route throught other nodes to the destinstion.
Adding more connections of course helps, but when the amount of connection increases, every new connection helps a lot less. At some point, adding more is worthless.
What I have in mind; would it be more efficient to separate network layer to something like cjdns and then make the needed 100-1000 connection on the cjdns-like layer, not on the ethernet layer?
I donāt understand how what you are promoting is any better than what we have ā¦ there are many measures and metrics and weāve only just begun to test what we have - so no serious idea what all itās strengths and weaknesses are yet ā¦ but you are already wanting to jump off to some other system.
Go ahead and build it it you want - create a fork and start coding. Once done with that, let people know, we will test it and if itās better using side by side comparisons, then your code will be adopted.
1 Like
Actually, testing the idea would not be too difficult; just compile an ipv6 version that allows only those adresses that starts with fc. All clients need to install cjdns before autonomi.
The result should be that router sees only a few connections instead of current thousands. But that would require a lot of testers.
I looked into this a bit, many questions, old code and partially working bindings. Seems no windows support and I am not sure if you have to already to have an ipv6 compatible router. I suspect you do.
So itās a lot of work to test and figure out, but much of the code seems very very old and not much work getting it to work with other languages or OSās etcā¦
I am not writing it off, but itās a project for sure to figure this project out, test it and then see where we are with it.
6 Likes
Well, current bitcoin core uses it as alternative layer.
Cjdns does not need ipv6 support on the router. It just need some connection, which does not even need to be ethernet. Using that connection, it creates an ipv6 interface for the device with a special ip address starting with fc.
But the idea would to separate the data transport layer from the connection layer. It does not need to be cjdns, but something like that. With a few (10 to 30?) connection the data layer would have a virtual connection to any other node in the network.
It still relies on the Internet and so, either TCP or UDP, whatever the app (
in our case) requires. CjDNS is an overlay to the Internet that routes packets with DHT at each node, itās not a magical replacement for the Inet as data still has to be routed normally to the nodes first. Iām unsure what is needed for mesh, but for most people they still have to use the internet and still use their ISP provided IP address at the base layer.
Additionally as a overlay where nodes have to route packets, this adds work for our network nodes and increases latency.
CjDNS is a good solution when you are concerned about third parties blocking routes - i.e. governments stopping data from flowing from one node to another. But if governments become concerned enough they may be able to use deep packet inspection to detect CjDNS packets and throttle or block them ā¦ and then we are back to square one and no real advantage.
What does already hides the data as itās self-encrypted. So Iām left feeling there are no advantages to CjDNS for us and at least two disadvantages - more latency and work for nodes.