Implement bandwidth limiting
- Dominant language
- Go
- Stars
- 17.1k
- Forks
- 3.2k
- Avg merge
- 3d 18h
- Merged PRs (30d)
- 11
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
- 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).
- 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.
- 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
Related Issues:
- https://github.com/ipfs/go-ipfs/issues/2489
- https://github.com/ipfs/go-ipfs/issues/2828
- https://github.com/ipfs/go-ipfs/issues/2917
- https://github.com/ipfs/go-ipfs/issues/2923
Contributor guide
Assessment
This issue has not been assessed yet.