gossipsub v1.2

[vyzo]

Working Draft for aggregating v1.2 changes.

Related PRs:

• [GossipSub 1.2] IDONTWANT control message #548
• [GossipSub 1.2] PING/PONG control messages #558
• Gossipsub extension for Epidemic Meshes (v1.2.0) #413

[arnetheduck]

With IDONTWANT, is #413 still relevant? are there compatibility problems foreseen if a client supports only #548 but not #413

[vyzo]

I think it is, but we'll have to test.
Also #413 is definitely not ready for merge, so we might want to push it to v1.3.

[vyzo]

If we push it to v1.3, then we wont have compatibility problems.

We might also want to implement some feature matrix announcement as well, so that an implementation doesn't have to support all features in the latest version.

[Wondertan]

I had the same question in my head, and then I realized that IDONTWANT targets a particular message by its id, while CHOKE and UNCHOKE target all messages coming from a mesh peer you choke. Both help to reduce duplicates.

[Menduist]

imo, episub (413) is nicer than IDONTWANT (548) for smaller messages (IDONTWANT is basically useless with small messages), however, episub will have a cost on latency, while IDONTWANT wont

[arnetheduck]

episub (413) is nicer than IDONTWANT (548) for smaller messages

A counterpoint would be that for small messages, duplicates maybe are less damaging overall - the mechanism is also more complex in terms of what potential side effects it might have.

Nevertheless, the core point here is that we have a clear and present use case for IDONTWANT, the simulations are showing good numbers and the protocol is both simple and ready - the point of moving forwards with 1.2.0 at this point would be to not block progress on that front while waiting for episub.

It's also interesting to consider / document how gossipsub going forwards would deal with unsupported "sub-features", for example how to treat clients that support one of episub / IDONTWANT but not the other - is this a direction worth exploring? Version numbers don't really convey this information well.

[Menduist]

A counterpoint would be that for small messages, duplicates maybe are less damaging overall

A thousand 1kb message is just as bad as one 1mb message

DONTSEND + staggersend might also help the "many small messages" case, but doubt so

It's also interesting to consider / document how gossipsub going forwards would deal with unsupported "sub-features", for example how to treat clients that support one of episub / IDONTWANT but not the other - is this a direction worth exploring? Version numbers don't really convey this information well.

imo, both of these features can be sent "optimistically", and if the peer doesn't support it, so be it
ie we don't have to be that precise to transmit our feature set

[vyzo]

I will propose a feature matrix annoncement as part of v1.2.

[cortze]

Hey there, folks; I’d like to bring this discussion back to the table.

For the last two months, at ProbeLab, we’ve been doing a thorough analysis of GossipSub, and we have pretty much come to the conclusion that reducing the number of duplicates should be the next priority item on the GossipSub 1.2 roadmap.

For some context, we’ve managed to identify a list of items (from Ethereum’s network) that we think are relevant to the discussion:

• relatively large messages (above the 30KB size) like blocks are prone to generate more duplicates than smaller messages like attestations

• for those “large” messages, the time between the first arrival and the first duplicate exceeds the 0.2 seconds 50% of the times

• There are some edgy cases where a node would request through multiple IWANT messages a non-seen message that ends up arriving a few ms later, generating an extra duplicate than the expected mesh arrival ones. (this sometimes generates the same peer sending us the same duplicated message at two different times)

Based on these main points, we would like to reopen the discussion to reconsider limiting the scope of the GossipSub 1.2 version to “only” the aggregation of IDONTWANT messages to the protocol. This way, we could start seeing how the number of duplicates significantly reduces on those gossipsub topics with a larger message size (making it worth the extra resources to send and track who doesn’t want them).

The proposition considers reducing the overall bandwidth used by gossipsub (which can help scaling the throughput of some networks like Ethereum with its blob targets), without waiting until the specs on episub are closed and implemented (which could still be targeted for version 1.3).

Links to the publicly shared posts originated from our last project on analyzing GossipSub in collaboration with the EF:

• https://ethresear.ch/t/number-duplicate-messages-in-ethereums-gossipsub-network/19921
• https://probelab.io/blog/deep-dive-dencun/#message-arrivals-and-duplicates
• https://ethresear.ch/t/gossip-iwant-ihave-effectiveness-in-ethereums-gossipsusb-network/19686/4
• https://ethresear.ch/t/gossipsub-network-dynamicity-through-grafts-and-prunes/19750

[ppopth]

Based on these main points, we would like to reopen the discussion to reconsider limiting the scope of the GossipSub 1.2 version to “only” the aggregation of IDONTWANT messages to the protocol. This way, we could start seeing how the number of duplicates significantly reduces on those gossipsub topics with a larger message size (making it worth the extra resources to send and track who doesn’t want them).

The proposition considers reducing the overall bandwidth used by gossipsub (which can help scaling the throughput of some networks like Ethereum with its blob targets), without waiting until the specs on episub are closed and implemented (which could still be targeted for version 1.3).

That makes sense. I agree that GossipSub 1.2 should include only IDONTWANT to deliver it faster. However, even if the episub thing is also included in GossipSub 1.2, we can still implement IDONTWANT in each implementation and deploy it, right? No one can stop us from using it, if they are all implemented in all the implementations.

[arnetheduck]

we've already deployed IDONTWANT, calling it 1.2.0 - it's just a number, at this point might as well do 1.3.0 for any new features/changes