Spam attacks testing

[piotrm50]

Perform spamming attacks on a real network (feature network/docker network). The network should not have any PoW set and the scheduler buffer size should be decreased to drop messages more easily. This test's purpose is to test whether the dropping of messages doesn't crash the node and doesn't have any other weird implications that make the network unusable.

• Spam by single low mana node
• Spam by multiple low mana nodes
• Spam by single high mana node
• Spam by multiple high mana node

[piotrm50]

Single spammer with honest congestion control with little mana:

• Setting:
  • scheduler rate: 100ms (10mps)
  • buffer size: 50kb
  • faucet: 5mps (65% amana)
  • master: 3mps (35% amana)
  • spammer: 10mps (0% amana)
  • activity messages are issued (about 1-3mps)
• Conclusions:
  • drops his own messages
  • schedules his own messages sometimes
  • his own queue fills the whole buffer
  • because he schedules sometimes his old messages, the tangle looks like a donut and grows towards the inside
  • buffer on other nodes is basically empty (no significant increase in the spammer's queue)
  • spammer node books all the dropped messages, but the tangle is also a donut, but with thicker layers
  • tip numbers on all of the nodes are reasonable
  • nodes don't crash if the maxVerticesWithoutFutureMarker parameter is decreased from 3000 to 200 (https://github.com/iotaledger/goshimmer/blob/00d90fadb81e71bc400c88fbd4a37a64818635b3/packages/markers/sequence.go#L22)

Tangle visualization on honest node:

Tangle visualization on spammer node:

[piotrm50]

Single spammer with half the scheduling rate (50ms vs 100ms) congestion control with little mana:

• Setting:
  • scheduler rate: 100ms (10mps), spammer: 50ms
  • buffer size: 50kb
  • faucet: 5mps (65% amana)
  • master: 3mps (35% amana)
  • spammer: 10mps (0% amana)
  • activity messages are issued (about 1-3mps)
• Conclusions:
  • spammer doesnt drop his own messages
  • spammer queue is empty
  • neighbors drop spammer's messages because the spammer queue is full
  • neighbors of neighbors don't see any spamming and the buffer is relatively empty
  • spammer's neighbors book all the spam messages and assign markers to them
  • spammer's neighbors drop marker messages, and it needs to process a certain number of messages to create another marker, which might also be dropped. It's a serious problem in dishonest environment as it can cause nodes not to confirm anything and run out of sync. Even with the maxVerticesWithoutFutureMarker parameter is decreased from 3000 to 200 (https://github.com/iotaledger/goshimmer/blob/00d90fadb81e71bc400c88fbd4a37a64818635b3/packages/markers/sequence.go#L22)
  • tip numbers on all of the nodes are reasonable

[piotrm50]

After implementing heuristic not to assign markers to messages from spammer nodes (spammer nodes are estimated using buffer and queue size), dropped markers are not a problem most of the times, however a problem occurs when a node schedules a message, that the rest of the network has dropped.

Say a node schedules something that the rest of the network has dropped, then attaches to it, and one of the messages in the future cone is marked as a marker. Then the confirmation stops on an honest node (or is delayed) because it attached markers to part of the tangle dropped by the network (thus no confirmation). It cannot confirm the other part of the tangle (or is delayed), because there are no markers for some time and the node is building up in soon-to-be-orphaned subtangle, so a lot his messages will be orphaned (until the tips are removed by the TSC condition). It's messages will never be even scheduled by its neighbors because they will never be ready (past cone is dropped and will not be confirmed).

[piotrm50]

Need to perform those tests in a more decentralized scenario, where cMana is more evenly distributed. E.g. on the feature network.

[piotrm50]

Spam tests setup:

• buffer size: 100MB
• 8 nodes with equally distributed aMana and cMana
• tests performed on the Feature Network
• Scheduler rate: 100MPS
• Spam rate: 110MPS (data only)

Results:

• Tip set starts growing immidately after spammer is started.
• With time, booker creates a lot (hundreds) of marker sequences.
• After a while, and a lot of sequences, booker can't keep up with the rate and creates back pressure. Booker queue fills up, then Gossip queue fills up and messages are dropped upon arrival to Parser.
• Tip pool size growth is not related to Booker being slow, but rather to the fact that Scheduler in a congested network adds some delay to the messages, and with larger message delay comes wider tangle (more tips).
• The effect of large tip pool needs to be researched more deeply.
• Tip pool size can be limited by limiting the size of the scheduler buffer, because then messages with too big delay, would be dropped from the tangle. But then it could create problems even in an honest environment, where buffer could fill up due to some random delays of communication layer/software lags.

Spam tests setup:

• buffer size: 50KB (~250 messages)
• 8 nodes with equally distributed aMana and cMana
• tests performed on the Feature Network
• Scheduler rate: 100MPS
• Spam rate: 110MPS (data only)

Results:

• Tip set starts growing immidately but limits at a few hundred tips (~420)
• Marker sequences are not created as frequently, therefore Booker doesn't create backpressure as fast. However sometimes new marker sequences are created.
• Interesting observation is that the more messages are issued above the scheduler rate, the less tips there are. This is because old messages are dropped faster from the scheduling buffer, reducing the effective delay of messages when they become tips.

[GalRogozinski]

Closing by request of @karimodm Can be reopened if needed