The connection manager should treat LAN connection specially

[MichaelMure]

Version information:

go-ipfs version: 0.4.19

Type: enhancement

Description:

The connection manager currently treat indistinctly LAN and internet connection, even though they don't have the same cost, for all meaning of this term.

This means that a MDNS-enabled node might have its LAN connection dropped when the connection manager reach the high water mark, and be forced later to route through the internet for something that could be achievable locally, which is a bit silly. Also, nodes that are in the same local network usually are mode likely to require content from each others, be it because they are part of the same application or because users want to access the same content from different machine at home.

I'd like to suggest a smarter connection manager, that either:

• don't drop local connection
• treat specially local connections, with a dedicated low/high water mark

[parkan]

this will likely benefit from the lessons learned modeling apps/collaborations in peer-base (although js-libp2p will probably get it before go)

@pgte am I right in thinking that peer topology work will move upstream into libp2p?

[pgte]

@parkan that's a hard, and I'm not sure the learnings of peer-base apply, but here goes anyway:

In the case of peer-base, the application defines the collaborations, and then the peer-base connection manager makes the hard work of trying to maintain a topology that maximizes application value (keeping directly or transiently connected to the peers that are the source of interesting data). If this logic were to move down to libp2p, we would need a) a way for the application to define the interest of each peer and b) to maintain a gossip topology that is well connected separately for each collaboration. IPFS doesn't have the notion of a collaboration, so I think this would be hard to translate to the libp2p world..

OTOH, a collaboration is a name, so I guess this could be somewhat translatable to IPNS over gossipsub, where the topology is cleverly maintained by gossipsub. (Perhaps @aschmahmann could shed some light here?)

In a collaboration particular case, differentiating a peer that is interesting and that is on the LAN from another peer that is interesting but is not on LAN, would mean that not only the application tracks the value of a connection, libp2p should also track the cost, applying some heuristic for ranking peer connections.

[aschmahmann]

@pgte yes my hope is to abstract out the gossip layer from the gossipsub protocol so people can use it for all sorts of use cases (including IPNS over gossipsub). gossipsub itself has a topic which in many ways is like a collaboration.

I haven't played around with the connection manager too much, but I think you can manually tag and protect peers to modify the value of a connection and @jhiesey is interested in the resource allocation/cost side of the spectrum.

@MichaelMure this question probably belongs in libp2p at https://github.com/libp2p/go-libp2p-connmgr. It is closely related to libp2p/go-libp2p-connmgr#35, libp2p/go-libp2p-connmgr#20 and libp2p/go-libp2p-connmgr#37. I'd recommend either continuing on libp2p/go-libp2p-connmgr#35 or opening up a new issue in that repo.

[Stebalien]

While this doesn't fix the connection manager issues, it sounds like a decent heuristic.

[Stebalien]

If someone's interested in this feature, the best way to implement it would be to:

1. Listen for new connections using host.Network().Notify(...).
2. Tag all connections to local peers.

[aschmahmann]

This issue has been open for a little while, is the request here still valid? If so having a fleshed out proposal would be helpful to implement this.

For example, do we give weights/protect peers with local network connections, only ones discovered via MDNS, etc? What types of peers are considered "local" what happens with people using VPNs, Yggdrasil, etc.?