Protocol request: Direct group communication protocol for low-latency applications (<100ms)

[jimstir]

Reference Issue: vacp2p/rfc#446
Author: oskarth

Problem

Some applications have a requirement for lower-latency direct communication as a group. This can be due to (soft) real time comm requirement. For example, video chat.

This can either be for 1-1 or as a group of N participants.

Relay/Gossip latency

From https://research.protocol.ai/publications/gossipsub-v1.1-evaluation-report/

Gossipsub-v1.1 achieves timely delivery.In our test network, with 1k honest peers and connection RTTs of 100 ms, we have not found a case where the v1.1 protocol experienced delivery delays higher than 1.6 sec for the 99th percentile of the latency distribution, even in scenarios with Sybil:honest connection ratio ashigh as 40:1. The maximum latency observed was about 5s but that affected a few messages while the systemwas recovering from an attack.

This is what we are working with. More benchmarking etc can be done, but gossiping over multiple hops in open network will always have some latency.

Example usage

• Status voice/video chat in browser for N participants. See e.g. https://discuss.status.im/t/waku-v2-webrtc-subprotocol-for-voice-and-video-chat/1850 by @decanus

• WalletConnect low latency connection between dapps and wallets, "faster relay, <500ms". @pedrouid can probably elaborate more on specific requirements here.

Sketch

Basically we want to trade-off some metadata protection and flexibility for latency in a specific negotiated context.

We can use relay protocol to discover peers to talk to, then negotiate a separate group context where all nodes can dial each other. Then based on that context

The simplest version would be a 1-1 direct voice chat, say. Initially via WebSockets but WebRTC (or possibly QUIC?) would be useful to do things like video chat in a browser.

There may be some more infrastructure work on libp2p needed here to make this suitable for voice/video, cc @dryajov re this

100ms is based on general response time limits (https://www.nngroup.com/articles/response-times-3-important-limits/) as well as intuition re things like FPS gaming for "real time feel".

Acceptance criteria

1. Issue with more limited scope for PoC

2. Better understanding of hard requirements and required work / reduced uncertainty on things like:

• WebRTC and/or QUIC (plus infrastructure needed for it)
• libp2p possibilities and limitations, especially for things like running from a browser
• understanding of how limited group negotiation would work, with joining context/consensus etc (make simplifying assumptions for initial spec)

---

^ @D4nte @jm-clius @arnetheduck @staheri14 FYI