可以看到，DragonFly与以下三者均无可比性。因此我目前的想法是将取一个目标的占用带宽比，之后向该值移动，具体机制可以参考TCP的拥塞协议。
Google File System
数据流选择物理距离上最近的机器进行传输，自定义的网络拓扑保证了IP地址可以用于计算机器之间的距离。
机器实际上无需抉择带宽的分配：毕竟只有一个传输目标。
MapReduce
底层使用了GFS作为存储结构，由于master只需要向worker节点传输input data，而数据在GFS中是作为三副本来传输的，因此存储在master的数据在其他节点也有存储，所以可以直接就近传输。在大数据量的情形下，这种策略的并发性尤其好。
BitTorrent
download: 经典的实现中采用了 rarest-first block shceduling ，即默认网络中各个节点的带宽均匀。
upload: 优先对曾经给自己传输过数据的节点发送数据。
因为DragonFly根本没有考虑到peer节点之间的公平性问题，关于带宽的优化目标只是最大化其使用，所以不可直接使用BitTorrent的结果
BitTorrent is an Auction
BitTorrent is an Auction: Analyzing and Improving BitTorrent’s Incentives is exactly the paper that I was looking for. I found it in section 2.2 of IPFS paper. In the section 2.2, the authors present existing work regarding the bandwidth allocation strategy, the following paper could also be used as the reference
- Dandelion [centralized servers, kind of like dragonfly architecture]
- BitStore [monetary mechanism]
[3.1 BitTorrent basics]: 该章节介绍了BitTorrent的基础，包括leechers, seedres, unchoke 以及 unchoke 的基本实现方法 [固定的小值常量，或以带宽为输入的函数]
我们想要优化的目标是leecher的下载速度。这里没有注明上传速度，是因为BitTorrent将upload speed的决定权交给了用户。由于大的上传速度可以保证更快的下载速度，所以用户可以自行抉择。在这里我们可以观察到BitTorrent目前与DragonFly的显著区别：前者是服务于用户的，需要注重节点之间的公平性；而后者是面向企业的，关键目的是优化带宽的利用率，并且防止拥塞网络。
Dandelion
该论文是上一篇论文的出发点，由于这篇使用了server-client的架构，因此与df有比较相似的特性。同时目前通过对这两篇paper的理解，认为可以修改peer的bid为{available bandwidth / current bandwidth}，并且以某一个常量为界限 [如0.5] 来进行反馈。
同时我认为supernode作为调节的一方可能overhead比较大，因为其需要收集信息，之后再做反馈。如果将决策放在client处，也许能达到更好的效果。
但通过查看论文我发现通篇的重点仍然放在了如果激励peer节点进行upload，以及随之的奖励机制。所以我认为这与DragonFly的架构与特性匹配得不好。
Appendix
在hacker news论坛看到了一些比较有经验的外国人在讨论DragonFly与其他P2P平台的对比，收益良多。但他们对其的理解不是很深入，没有理解到DragonFly是面向企业的文件分发系统，所以一直在把DragonFly与BitTorrent作对比。这两者之间的可比性非常少，因为DragonFly根本没有考虑到peer节点之间的公平性问题，关于带宽的优化目标只是最大化其使用