Choke extension for Gossipsub #681
Conversation
|
|
||
| Authors: [@marcopolo] | ||
|
|
||
| Interest Group: TODO |
There was a problem hiding this comment.
Please comment here if you would like to be added to this interest group.
There was a problem hiding this comment.
I'd like to be there, if it's possible
There was a problem hiding this comment.
please add me to the interest group too
| $P_{3}$: Treat `IHAVE` from a choked peer the same as receiving a message for | ||
| scoring purposes. | ||
|
|
||
| $P_{7}$: If mesh peers fail to respond to an `IWANT` following an `IHAVE` | ||
| penalize them twice as much as a non-mesh peer. They are using a slot in your | ||
| mesh and not fulfilling their role. |
There was a problem hiding this comment.
For twice as much seems arbitrary and too small to me. Not yet sure how this can be abused, but I think a much higher penalty would be needed. For example. while I understand why you want to keep
|
Worth linking also #413 from @AgeManning and all the discussions in that thread. |
|
I'm in favour of this. It seems its difficult for us to agree to large changes to specifications, so I'm in favour of incremental small changes that allow implementors freedom to optimize. +1 from me. |
| │ ┌─────────────┐ │ | ||
| │ │ CHOKED │─────┘ | ||
| │ │ │ | ||
| │ └─────────────┘ |
There was a problem hiding this comment.
Should there be an arrow from CHOKED to PRUNED as well? because the node can leave the mesh when choked?
| it will not be the first delivery of the message. | ||
|
|
||
| An implementation SHOULD NOT send a Choke message to another peer that is not | ||
| part of its mesh. Note that this can not be a MUST as a peer may leave the mesh |
There was a problem hiding this comment.
| part of its mesh. Note that this can not be a MUST as a peer may leave the mesh | |
| part of its mesh. Note that this cannot be a MUST as a peer may leave the mesh |
|
Thank you for bringing this up. Just one suggestion: We already have PRs for 1.3 and 1.4 proposals. In my opinion, labeling this as 1.5 can help avoid any potential reference conflicts. |
| This strategy chokes peers that deliver late duplicates. It will unchoke peers | ||
| when they deliver messages sooner than any unchoked peer. This strategy has two | ||
| parameters: | ||
|
|
There was a problem hiding this comment.
Random choking is analogous to reducing mesh degree, and achieving optimal choking/unchoking is challenging. For the same publisher, early senders often remain consistent; however, they may vary if the publisher changes.
A few possible suggestions for choking/unchoking decisions:
-
We send a list of message IDs to the choked peer. These IDs represent messages that were delivered late from the choked peer, which identifies predecessors for those messages and only stops sending messages from those predecessors (partial choking). We can partially choke all mesh members.
-
We can completely choke slow mesh members, which requires computing effective data rate for all mesh members (Message preamble can make it trivial)
-
Choked peers may send IHAVEs much earlier, whereas actual message transmission can take a considerable amount of time. We can consider the effective data rate in message/IHAVE arrival time difference estimates.
|
|
||
| - Two new control messages: Choke/Unchoke. | ||
| - Mesh peers MAY send IHAVEs in lieu of pushing a message. This is typically | ||
| done in response to being Choked. |
There was a problem hiding this comment.
IDONTWANTs still serve the purpose. We just need to change that mesh members can request messages using IWANT
There was a problem hiding this comment.
Agree that there is overlap here, but semantically these are different. IHAVE signals that this the message has been validated by the peer. IDONTWANT makes no such guarantee. We do not want to request/propagate messages that have not been validated.
| A common optimization is limiting the number of concurrent IWANTs for a given | ||
| message ID. When using this optimization an attacker could further delay | ||
| message. To mitigate this, implementations SHOULD use timeouts to request the | ||
| messages from other peers and increase the the number of concurrent IWANTs for |
There was a problem hiding this comment.
| messages from other peers and increase the the number of concurrent IWANTs for | |
| messages from other peers and increase the number of concurrent IWANTs for |
There was a problem hiding this comment.
lets not forget the experiments i and @AgeManning have run... i like the general idea of letting each peer individually decide how to choke.
This PR hopes to make a minimal protocol change to enable various optimizations. I know we have many alternative proposals in flight now, and, while I won't make a full comparison table just yet, please note that this extension does not forbid or block any other proposal. In some cases it even enables them.
I'll let the document speak for itself, but to cover some meta points:
I only claim credit for the text itself. The ideas presented are old and have been brought up many times in the past, particularly from @AgeManning. Any mistakes are my own.
How does this relate to Generalized Gossipsub?
This spec introduces the same Choke/Unchoke extensions as that proposal, but with relaxed restrictions to allow for optimizations and to account for race conditions. I believe it makes sense to break up that proposal into a small extension that introduces these control messages and a general rephrasing of the gossipsub spec (which I also favor). If the community prefers going all in on the generalized gossipsub approach right away and skipping this extension, that would also be okay with me.
How does this relate to IANNOUNCE/#653?
This spec change would allow this proposal to simply use the existing
IHAVEmessage instead of a new control message. That said, I believe having the receiver control eager vs lazy push makes more sense as the receiver has more information on their mesh peers and received duplicates.How does this relate to PREAMBLE/IMRECEIVING/#654?
The general ideas could complement this spec. First, this spec allows mesh peers to lazy push a message. Second, in the medium/long term I would like to see each message being sent on a new stream. In that case having something like the preamble would be useful as you could reset the message stream safely and without having to read the whole message.
Finally, the document is split into two sections: protocol changes, and implementation recommendations. The implementation recommendations will change as we get more experience. My goal is for the protocol changes to be flexible enough to allow experimentation. On top of this, applications may themselves have recommendations to implementations (I'm sure I'll draft something more for the peerdas usecase after more experience).