This is great! I agree that having a protocol that can better balance between push vs pull, especially depending on message type, is really valuable.
On that note, I would suggest that D_announce is a per-topic configuration variable. For example, attnets probably has a different value that would be optimal.
(And if we go that route, maybe D should be configurable per message type/topic. I don’t believe it already is, right?)
Did you try this for other values of D_announce? Seeing a curve showing the relationship between values from 0 to D would be valuable
Funny to see that 0 is 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 expect 0 to 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.
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.
What is the relationship you see here? Yes, IHAVE/IWANT is similarly announcing for pull opportunities, but the major difference is that IHAVE/IWANT is to a wider set of peers than your mesh degree, D, and thus helps ensure distribution of messages even under adversarial p2p network conditions. Given that IANNOUNCE/INEED is upon the same set D, then it’s usage does not serve the same resilience purpose as IWANT/IHAVE (ensuring that if the narrow degree D is corrupted/disrupted, that the network can still communicate)
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.
Another idea is for D_announce to potentially be dynamic locally based on observations – e.g. how many duplicates normally getting, how far into the slot normally receiving message, etc – and for local adjustments to tune the network as a whole. Can of worms but might have some promising avenues