说实话感觉没有很惊艳到我的一篇文章，技术也都不太复杂，为啥会有4k行代码
在黑箱模式下，云租户不知道网络特性，而云提供商也不知道应用程序的通信语义和传输时间表。 这就错过了云租户和云提供商使数据流适应底层网络拓扑结构和条件以提高这些应用的性能和效率的机会。
关键的想法是，提供商提供一个提示--对云租户的带宽分配的间接指示。租户应用程序然后根据提示调整他们的传输时间表，这些提示可能随时间变化。
NetHint的有效性有赖于解决三个重要的挑战。 - 首先，提示应该包含哪些信息？ - 第二个挑战是如何以较低的成本提供这种提示。 - 最后的挑战是应用程序应该如何对提示做出反应。
nethint包含哪些信息
以下信息
- 虚拟链路信息：一棵树；原型使用一个三层树，捕捉虚拟机在数据中心机架之间的分布情况，并将机架层以上的网络结构折叠成一个根节点。
- 每条虚拟链路上的总带宽
- 每条虚拟链路上的剩余带宽
- 共享对象的数量
根据以上信息，可以按照provider的公平策略建模出。式子也比较简单
provider及时提供信息
user query overhead，100ms提供一次，每次的数据总大小很小
collection overhead，1.3Gbps/机架。假设每个机架有500Gbps的出站带宽。那么NetHint的带宽开销是0.26%。
如何调整（该section主要用来表明，一部分的分布式应用可以受益）
优化collective communication
优化task placement
flexible adaptation for stale information
收集+计算延迟和采纳的延迟都可能导致stale info。
两点启示：
- stale information should not be used when it is misleading
- there is no one-size-fits-all solution