This is a topic to discuss Message Priorities. A message on SAFE is any data that’s transfered between 2 nodes. Therefore it should not be confused with messages you sent over your phone using Whatsapp or other messengers. When you do want to discuss these type of messages, please talk about messengers.
We are prioritising Routing traffic and taking aggressive action to drop all other traffic if a node cannot accommodate the network traffic as we expect
Hey, this is interesting. Not all messages are the same since that test. And there’s a good explanation for that. Think of SAFE at the lower level. What do nodes (like your vault) do? They connect over several layers of encryption and create routing tables and connect to each other. Now think of this network with people downloading a lot of data (so a lot of routing) creating congestion in the network. What could we do to keep the network up and running?? This is where prioritization comes in. It simply means that 1 message (like a new node to be added to a routing table) is more important than delivering a chunk of 1 mb. to a user. It’s to keep the network alive even under extreme pressure. LINK.
/// Priority of a message to be sent by Crust. A lower value means a higher priority, so Priority 0
/// is the highest one. Low-priority messages will be preempted if need be to allow higher priority
/// messages through. Messages with a value `>= MSG_DROP_PRIORITY` will even be dropped, if
/// [bandwidth is insufficient]
Is also helps nodes with low bandwidth to stay part of the network and even help securing the network. How? The idea is quite simple. When the network is under stress or when a node is in low bandwidth it can drop the less important stuff to focus on the really important stuff. I’ll make list below and try to figure out what happens at what priority. I probably get it wrong because there’s some guessing in here as this stuff changes over several tests.
0 - Routing
This is the most important layer for the network. The network can’t survive without routing tables as the lowest layer in XOR. This part of the network needs to be up and running no matter what! So if your node finds out there’s congestion on the network and everything slows down, all messages related to routing (like heartbeats and confirmations on receiving routing messages) should be prioritized over all the others messages like delivering a chunk of 1mb. data.
1 - Client accounts
Imagine not being able to log in to the network. It’s quite the same as “Gmail is down for a lot of users” but even worse. Because in our case, your wallet, messages (messenger) and datamaps to your personal files are in your personal account.
2 - Safecoin
When the network is up and running, even while it’s under heavy stress, Safecoin should work as long as you can log in to your account. It’s again more important than delivering 1 mb. data chunks. If merchants start to use Safecoin, it should just work. “Safecoin is not working for several users” is again a very scary title to spot on cryptonews websites.
3 - Messenger
SAFE Messenger is less important than Safecoin (overall), but if you see how people use whatsapp and other messengers these days it is very important. Imagine a heavy tornado going over an area bringing down internet for most people. At that moment it’s even more important than Safecoin as people want to find out where their loved ones are.
One thing to notice is that all things at these layers are the most easy to do for the network as they consume way less bandwidth than watching an episode of breaking bad. If all our internet connections fall down to 20 Kilobyte/sec. up and down, everything up to priority 3 should work quite well. It’s only when we start to up- and download data like videos, docs and music that KB’s go up quite fast. That’s why these shouldn’t be in the highest priority level. The next question is at which levels we want things like computation, smart contracts, structured data and more.
Thank You for bringing up the topic . Eventually , we are going to learn more about the little details that may very likely matter more than we think , right now . As our ideas and priorities sharpen we might find also a way to model the desired behaviour , discussing this will surely give us more spin around the imaginative and the real solutions ; I’m saying … it all helps to push us further towards the SAFE shores we are only starting to see on the horizon
I don’t know what “structured data and more” is… but management of computation and smart contracts, I wonder, may follow any breakthroughs that Ethereum find. If the impact of a contract on the network, or in their case blockchain, is minimal, then that will be distinct from all that computation being substantially extra load. I’ve not followed Ethereum closely as it’s almost too much blue sky and wild but if they can resolve a way to manage consensus for contract actions, then that could be adopted.
More directly, I would expect that given SAFE is about delivery of data, any added extras like computation and contracts would be secondary to that. So, I guess 4=data; 5=contracts; 6=computation, following from the way the OP suggests capability collapses under stress.
Yes, this one is very important. I think at regular use we won’t see that much trouble. The question is, what happens when we get stress in several parts of the network, like the nodes in a small country like the Netherlands get in trouble because of a major fiber cable break or something. They might dump everything below a certain prio while still keeping the network secure. And that’s the great thing I realized when writing the topic:
The messages for securing The SAFE Network are also the smallest messages on that network.
This is a very big win for SAFE. I actually think it’s the part that makes this network a killer . Just think about it, the smallest messages on a blockchain network are the transactions, but the “messages” to secure the network are the blocks. That’s the complete opposite from SAFE !!!
One better than that, is capability for vaults to go down and come back up still able to contribute the data they held. There is some risk in areas where ISP monopolies or power network are liable to fail. Relative to power networks, I wonder rolling brownouts will be interesting to work with too.
Regrading computation, it would be great if the management of a computation task and the carrying out of that task were separate so that the much smaller management work load could be at a lower level where it could throttle, pause, or shut down gracefully the main computational work load if network resources were becoming scarce.
I would not rely on that. I’d say that some tuning is going to happen and this behaviour is up for change. I can remember a lot being said about that it is insecure to allow this behaviour except for archive nodes
Structured Data can be a higher priority than Chunks since they are nominally 1/10 the size and since they cost relatively more to store data they can be presumed to be more important. People only spend extra on more important things.
Unpredictability is actually a good thing here: just think about Chaos Monkey, whose job is to make sure you can chill, no matter what goes down. Designing a resilient system may be hard, but getting rid of unpredictability is straight out impossible; cranking it up a bit will reveal what needs to be tweaked.
. Just think about it, the smallest messages on a blockchain network are the transactions, but the “messages” to secure the network are the blocks. That’s the complete opposite from SAFE !!!