Gossipsub: Unsubscribe backoff #383
Conversation
|
@vyzo can you take a look here? |
pubsub/gossipsub/gossipsub-v1.1.md
Outdated
| @@ -105,6 +105,10 @@ within the backoff period and extend it. | |||
| When a peer tries to regraft too early, the pruning peer may apply a behavioural penalty | |||
| for the action, and penalize the peer through P₇ (see [Peer Scoring](#peer-scoring) below). | |||
|
|
|||
| When unsubscribing from a topic, the backoff period should be finished before subscribing to | |||
| the topic again, otherwise a healthy mesh will be difficult to reach. | |||
| A specific backoff period for unsubscribing should be set accordingly. | |||
There was a problem hiding this comment.
did you mean "resubscribing" here?
There was a problem hiding this comment.
The UnsubBackoff is sent to peers when we unsubscribe to allow us to resubscribe before the full PruneBackoff
So while this is meant to allow fast resub, I called it the unsubbackoff because why send it during unsub
It tried to explain this better in the doc, lgty?
|
@AgeManning @divagant-martian thoughts on this as the Rust Gossipsub experts? |
|
Yep. This lgtm. We'll make a PR for rust gossipsub. |
Implements the changes specified by libp2p/specs#383. Co-authored-by: Max Inden <mail@max-inden.de>
|
For the record, this is now implemented in rust-libp2p via libp2p/rust-libp2p#2403 thanks to @divagant-martian. |
@vyzo could you tackle the Golang side? |
|
I'll try to make some time for this. Any takers? |
|
@vyzo friendly ping. I don't think anyone else from the Go side picked this up in the meantime. |
|
As far as I can tell, this issue has been addressed in libp2p/go-libp2p-pubsub#473. |
|
Doesn't look like it, the goal of this spec is to have a tunable, different backoff when unsubscribing from a topic |
|
ok, will make this configurable. |
|
@vyzo if you haven't started already I can take. Seems pretty straightforward. |
|
Sure, go ahead! |
|
This is now implemented in Rust, Nim, and Go. I think we can merge this. Thanks all! |
Implements the changes specified by libp2p/specs#383. Co-authored-by: Max Inden <mail@max-inden.de>
In eth2, you can't really be sure at which point you will have to subscribe from a topic.
So you when unsubscribe, you may have to resubscribe in the next 60 seconds
This causes a clash with the backoff, since every peer you had in your mesh when you unsubbed is now in your backoff, and forming an healthy mesh becomes tricky.
This is a bit of a corner case, but adding a setting to tune to unsub backoff really helps with this case, and doesn't cost anything, since if you stay out of the topic, you shouldn't get GRAFTed anyway.
We implemented it in nim-libp2p: vacp2p/nim-libp2p#665
which drastically improved mesh health on our busy test nodes (2500 validators, which in eth2 term is stupidly big, but that's where the issue is most visible) (each validator causes some sub/unsub):