Path to landing Bitswap PoC

[dirkmc]

We're currently working on a proof-of-concept for Bitswap to improve performance by disseminating information about how blocks are distributed amongst peers. This issue outlines the remaining steps required to complete it:

• Complete PoC code review
• Close out remaining issues:
  • Timeout Management
  • Debounce wants
  • Prune peers from Session if they stop sending blocks
  • Session should broadcast when all peers are removed
  • Simulate DONT_HAVE when peer doesn't respond to want-block (new peers)
  • Docs + Code cleanup
• Create proposal for testground test suite
• Implement testground test suite
  • Measure Performance (compare with master) Add bitswap test suite testground/testground#345
  • Version compatibility https://github.com/ipfs/testground/issues/435
  • Fuzz Test Plan https://github.com/ipfs/testground/issues/427
  • Seed Selection https://github.com/ipfs/testground/issues/436

After landing PoC:

• implement server side of PoC in Javascript (HAVE / DONT_HAVE messages)
  Feat/have new msg types js-ipfs-bitswap#211
• tackle rate limiting

[dirkmc]

Performance comparison of master vs proof-of-concept

We collected performance data comparing Bitswap master against the proof-of-concept branch using a testground test suite.

In particular we are interested in comparing

• time to fetch at different latency / bandwidth, for varying numbers of leeches and seeds
• number of duplicate blocks fetched

5ms latency, variable bandwidth: 1 seed, 2 seeds, 4 seeds

These graphs are for 1 leech fetching from 1, 2 and 4 seeds with 5ms latency and 10MB, 20MB, 40MB, 160MB and 1024MB bandwidth.

For high bandwidth:

• the PoC gets better performance with more seeds whereas master gets worse performance with more seeds
• the PoC performs much better than master

For low bandwidth:

• the PoC and master both get better performance with more seeds
• the PoC performs somewhat better than master

5ms latency, variable bandwidth: 3 leeches fetching from 3 seeds

These graphs are for 3 leeches downloading simultaneously from 3 seeds. It seems like at any bandwidth the results are similar:

• PoC is faster, particularly for higher bandwidth / file size
• PoC results seem to be more consistent (points are less scattered)

Duplicate blocks - 5ms latency, variable bandwidth: 1 seed, 2 seeds, 4 seeds

These graphs show the number of duplicate blocks received by the leech for 1, 2 and 4 seeds.
Note that in the case of 1 leech / 1 seed, there will be no duplicates.
The points are highly scattered, but the results are generally as expected:

• For the PoC there are rarely any duplicates, at any bandwidth
• For master there are more duplicates when there are more seeds, and at lower bandwidths

100ms latency / variable bandwidth: 1 seed, 2 seeds, 4 seeds

These results for variable bandwidths with 100ms latency are similar to those with 5ms latency above.

[momack2]

OMG SHIP IT! (@hinshun - some pretty graphs to show off validating all the great work)

[jbenet]

Fantastic perf improvements! Great graphs! 🎉🎆❤️🚀

[bertrandfalguiere]

Holy ship! 🚀

[dirkmc]

Shout out to @Stebalien with whom we came up with the design ideas, and who reviewed the 9,000 line PR, @hinshun who created the test environment to validate the initial proof-of-concept and to the testground team ❤️

[obo20]

This is amazing. Great work all around. We're super excited to see this make it to production.

[whyrusleeping]

Fantastic! This is great stuff @dirkmc :)