exp/experthelp wantedstatus/deferredtopic/libp2p
Repository metrics
- Stars
- (13,906 stars)
- PR merge metrics
- (Avg merge 4d 2h) (28 merged PRs in 30d)
Description
We need to place limits on the bandwidth ipfs uses. We can do this a few different ways (or a combination thereof):
- per peer limiting on each actual connection object
- pros:
- low coordination cost (no shared objects between connections)
- should have lower impact on performance than blindly rate limiting the whole process
- cons:
- no flow control between protocols, dht could drown out bitswap traffic
- pros:
- per subnet limiting
- pros:
- avoids rate-limiting LAN/localhost connections.
- cons:
- it's not always possible to tell what's "local" (e.g., with IPv6).
- pros:
- per protocol limiting on each stream
- pros:
- should have the lowest impact on system performance of the three options
- each protocol gets its own slice of the pie and doesnt impact others
- cons:
- increased coordination required, need to reference the same limits across multiple streams
- still makes it difficult to precisely limit the overall bandwidth usage.
- pros:
- global limiting using a single rate limiter over all connections
- pros:
- will successfully limit the amount of bandwidth ipfs uses.
- cons:
- ipfs will be quite slow when rate limited in this way
- pros:
Related Issues: