On that note, I would suggest that
D_announceis a per-topic configuration variable. For example,attnetsprobably has a different value that would be optimal.(And if we go that route, maybe
Dshould be configurable per message type/topic. I don’t believe it already is, right?)
Yeah, this would be a natural next step for us. We didn’t include it in the initial specification because we wanted to be able to complete the simulations in a reasonable amount of time without implementing per topic parameters. v2 would be a good time to introduce this into the spec.
Funny to see that
0is strictly worse (under these non-adversarial conditions). This is because duplicates are just wasting local/global bandwidth? Assuming we were hitting peak load locally or globally, you’d expect0to be strictly better. Maybe it’s worth running an experiment with all 1Gbps (or even 10Gbps) nodes to show that when bandwidth is not saturated, that push is faster. This would help us validate the hypothesis of why pull is faster for more bandwidth bound networks.
For large messages, sending out so many messages at the same time saturates the uplink bandwidth which is why it shows an improved performance even against 0 in our simulations. Its the same reason why batch publishing has much better results.
I agree on validating this with new simulations with all the nodes having much higher bandwidth to eliminate uplink saturation. Alternatively we can also drop the message size ( 1kb) and run the simulation to show that 0 is strictly better in the absence of congestion
I’m concerned that this isn’t adequately capturing adversarial network conditions or poor mesh constructions. It does look very promising! But, I could imagine attack cases could degrade worse under this model.
Does shadow model any of the attack conditions that Testground did in the original gossipsubv1.1 parameter additions? For example, the “Covert Flash Attack” might more seriously disrupt a mesh that is being less opportunistic about push. that said, the gossip meta-data (IWANT/IHAVE) might still be sufficient to protect. Nonetheless, I do think that we should model some set of relevant p2p attack vectors when adding a significant change to the gossip protocol – the v1.1 set of attacks as a good basis
We haven’t started simulations yet with a malicious majority yet, but it is definitely something we will cover soon. The worst thing a mesh peer can do is to not respond back to an INEED message within the timeout, so this can push up the latency by quite a bit in the event of an attack. There are heuristics that can be used to handle such events(very similar to unfulfilled promises with gossipsub v1.1). Ex: If the mesh peer is non-responsive beyond a threshold it is ignored and pruned from the mesh. It does need to be balanced with not being too harsh on slower peers.
I do agree that revisiting IWANT/IHAVE, it’s timing, and load should be under consideration. I guess, you probably want IANNOUNCE/INEED to happen in quicker time frames than IWANT/IHAVE heartbeat to ensure that IWANT/IHAVE doesn’t become dominant wrt message broadcast.
Yeap, we just do not want IWANT/IHAVE to interfere with mesh announcements. A peer could be already receiving the message from a mesh peer and request it at the same time from a non-mesh peer which would lead to a duplicate.