WIP connmgr v2 specification

[raulk]

Incomplete. Heavy WIP. Open to high-level feedback.

• introduction
• high-level overview
• quota allocation
• protocol enrollment
• stream scoring
• locking
• bursting
• regulation procedure
• environment sensing
• observability

[vasco-santos]

Awesome!

I and @jacobheun will need to work in improving the connection manager in js-libp2p for Q2, as a consequence of enabling the DHT and dealing with way more peers now. This way, we should be able to get involved in this discussion.

[JustMaier]

It seems like there could be some interesting overlap between the connection manager and the proposed v2 peerstore. Ideally, peer metrics and connection manager determined quotas could be retained in the peerstore, and if the peerstore becomes a source of address quality/confidence, the information would be very valuable to the connection manager as it allocates resources.

Either way, I think that evolving peerstore around the same time as connection manager could make a lot of sense.

[raulk]

@JustMaier – thanks for your interest in this spec. I think you're dead on with your intuitions about the alignment between peerstore v2 and connection manager v2. Have a look at the RFC for the go-libp2p eventbus too – I think you'll find it interesting.

All these proposals share a common theme of adopting a reactive, event-driven system comprised of autonomous, discrete services with loose coupling amongst each other.

[jacobheun]

I've started to put down some of my notes on Connection Management over at libp2p/notes#13 (comment) to avoid polluting this PR.

[meyer9]

Would the protocol enrollment section explain how to accept peers based on the protocols they support? For example, say I want to have 10 peers supporting the IPFS protocol and 10 peers supporting the FooBar protocol.