jo-pillar/jo-pillar.github.io

My blog

NetHint

1 Introduction

数据密集型应用（例如，网络功能、数据分析、深度学习）越来越多地转移到云端，以实现资源弹性、性能、安全性和管理的便利性。云网络的性能对这些应用的性能至关重要。因此，云服务提供商已经付出了大量努力来优化云网络的各个方面，包括网络拓扑[34, 73, 76]、拥塞控制和网络堆栈[3, 33, 42, 44, 69, 77, 92]、负载平衡[2, 46, 63, 88]、带宽保证[6, 9, 43, 48, 51, 67]、调试[7, 31]、故障恢复[53]、硬件[8, 27, 52, 58]以及虚拟化[66]。

如今，云服务提供商将网络呈现给租户时采用了黑盒模型：云租户对其预期的网络性能（例如，常数最差情况下的带宽保证）或底层网络特性（包括链路层网络拓扑、共存租户数量和瞬时可用带宽）了解甚少。

考虑从虚拟机A向虚拟机B、C和D广播一个单位大小的数据对象。图（a）显示了网络特性，所有链路的双向带宽均为1。虚拟机D具有0.25的上行后台流量。图（b）到（d）展示了可能的广播树及其相应的广播完成时间。箭头表示流量流向，数字表示吞吐量。

由于其简单性，长期以来黑盒模型一直运作良好。然而，随着云中流行的数据密集型应用的出现（例如，数据分析、分布式深度学习和分布式强化学习），我们观察到这种黑盒模型不再有效（§2）。问题的关键在于，许多这类新兴应用具有根据底层网络特性调整其传输计划的能力和动机，但在黑盒网络中实现这一点很困难。

考虑广播，在强化学习和集成模型服务中是一种重要的通信原语。图1显示了一个示例，虚拟机A向虚拟机B广播，然后广播到虚拟机D。图1b展示了在黑盒模型下构建的可能广播树。没有底层网络特性，广播树是网络无关的，这在交叉机架链路上引入了链路压力。图1c展示了基于拓扑信息构建的广播树（即拓扑感知），通过最小化交叉机架流量，将广播完成时间从2降低到4/3时间单位。图1d显示了基于拓扑和带宽信息构建的广播树（即网络感知）。它构建了一个避免VM D上行链路拥塞的最佳广播树，进一步将完成时间降低到1时间单位。对于具有更大过订阅比例或更倾斜流量的数据中心网络，性能提升更为显著。

上述例子说明了现有网络抽象的黑盒性质与数据密集型应用调整其流量的能力之间存在基本不匹配。在黑盒模型中，云租户对网络特性一无所知，云服务提供商对应用通信语义和传输计划一无所知。这导致了云租户和云提供商错失了调整数据流以提升性能和效率的机会。潜在的收益是可观的：我们在AWS上进行的基准实验显示，深度学习实验的allreduce延迟在不同的allreduce传输计划中变化最多可达2.8倍。一种候选方法是让应用程序探测和分析网络，然后根据其结果规划数据流[5, 57]。第二个选择是将可能的传输计划报告给提供商由提供商选择。我们观察到这些替代方案引入了相当大的通信延迟和系统开销（§2.2）。

在本文中，我们探讨了一种解决这种不匹配的白盒方法。其中一种可能性是，云提供商向应用程序提供物理网络拓扑、虚拟机位置以及带宽保证。然而，这种方法有两个主要缺点。首先，暴露虚拟机的位置和数据中心网络拓扑可能会危及云租户的安全，并对云提供商造成担忧（§2）。其次，租户的可用带宽取决于其他租户的通信模式，这可能是非常动态的。不及时或不准确的预测可能弊大于利。

本文探索了一种替代方法。我们设计并实现了NetHint，这是一种云租户和云提供商共同提升应用性能的机制。其关键**是提供商提供一个提示——对云租户的带宽分配的间接指示（例如，虚拟链路层网络拓扑、共存租户数量、网络带宽利用）。然后，租户应用根据这些提示调整其传输计划，这可能会随时间变化。NetHint在保密性和表达能力之间取得了平衡：一方面，提示避免暴露其他租户的物理网络拓扑或流量特性（§9）。另一方面，我们展示提示提供了足够的网络信息，使租户能够规划高效的传输计划（§5）。

NetHint的有效性取决于解决三个重要挑战。首先，提示应包含什么信息？我们为每个云租户提供了虚拟链路层网络拓扑以及虚拟拓扑中每个链路上的可用带宽。这使应用程序能够调整其传输计划以避免网络拥塞。第二个挑战是如何以低成本提供这个提示。我们设计了一种两层聚合方法来收集主机上的网络统计信息。我们在机架中指定一个NetHint服务器来聚合机架中的网络特性。然后，NetHint服务器使用全局的全对全通信来交换网络特性。因此，云租户可以向其机架本地的NetHint服务器查询提示。

最后一个挑战是应用程序应该如何对提示做出反应。我们为NetHint提供了几个用例，以优化一系列流行的数据密集型应用，包括深度学习、MapReduce和服务集成模型。结论是，对于所有这些应用，租户可以通过简单的调度算法使用NetHint信息。然而，适应也有一个缺点：提示可能过时，根据过时的信息调整传输计划可能会损害性能。我们设计了一个策略，使应用程序能够在不同场景中灵活地适应不同的提示：当后台网络条件稳定且适应开销低时，应用程序使用时间带宽信息，否则应用程序回退到仅使用时间不变的拓扑信息（§6）。

我们使用小型测试平台和大规模模拟评估了在数据中心引入NetHint的开销和潜在性能提升。我们的结果显示，在分布式数据并行深度学习的allreduce完成时间、集成模型服务中的广播完成时间以及分布式数据分析中的MapReduce洗牌完成时间中，NetHint平均提高了性能分别为2.7倍、1.5倍和1.2倍。此外，这些好处是廉价获得的：NetHint只产生了适度的CPU、内存和网络带宽开销。

总的来说，本文做出了以下贡献：

• 我们识别了当前黑盒网络抽象与数据密集型应用通信需求之间的不匹配。
• 我们探索了多租户数据中心的白盒网络方法。
• 我们设计并实现了NetHint，这是一种低成本的系统，允许数据密集型应用调整其数据传输计划以提升性能。

2 Background

2.1 Black-Box Networking Abstraction

今天，云的网络抽象仅仅是在终端主机上对每个虚拟机进行的带宽分配。这种抽象是一个黑盒：租户对底层网络特性一无所知，包括网络拓扑、共存租户数量和瞬时可用带宽。因此，云租户无法预测其网络性能。图2显示了一个例子。即使对每个虚拟机静态分配了5 Gbps的带宽，VM A仍然无法预测其网络性能，因为它取决于其他虚拟机的流量需求。当VM C和D的两个流导致网络内拥塞（情况2）时，VM A只能获得3.33 Gbps的带宽。即使采用工作保守的带宽保证，一个虚拟机的网络性能仍然取决于其他虚拟机。

为了量化这种影响，我们在Amazon Web Service（AWS）上对allreduce延迟进行基准测试。Allreduce是一种用于分布式深度学习的集体通信原语。它在所有工作进程（每个在其自己的虚拟机中运行）之间聚合一个向量（即深度学习中的梯度更新）。在我们的实验中，我们在EC2 US-East-1区域启动了32个g4dn.2XL实例（使用Linux内核5.3），并使用NVIDIA NCCL（版本2.4.8）测试环形allreduce延迟，进行了100次连续运行。我们重复上述实验5次，不同的试验可能在物理拓扑上有不同的虚拟机布局。图3显示了我们的发现：在256MB缓冲区上的环形allreduce性能在不同试验中空间上变化，而在试验中时间上也变化。跨不同试验比较，最快的试验平均性能比最慢的试验好1.8倍；在试验内的100次运行中比较，最快的运行比最慢的运行快高达2.8倍。

2.2 Adaptiveness in Data-Intensive Applications

除了强化学习和集成模型服务可以根据需要广播模型和输入数据（如图1所示）外，我们发现许多其他应用程序也有能力和动机根据底层网络特性调整其传输计划。许多分布式数据分析工作负载在不同作业阶段之间包含网络密集的洗牌阶段。例如，在MapReduce应用程序中，洗牌创建了在映射和减少阶段之间进行全对全数据传输的情况。洗牌阶段占据了许多数据分析工作负载执行时间的大部分[16]，并且许多研究[4, 15,16,39,84,87,90]表明优化洗牌性能可以显著提高应用程序性能。在给定网络特性的情况下，分布式数据分析应用程序可以通过改变传输计划（通过更改任务位置）来最小化洗牌完成时间。图4a显示了一个具有两个映射器（m1和m2）和两个减少器（r1和r2）的MapReduce作业的洗牌流量。从图4b到图4d，我们观察到基于拓扑和带宽信息分配映射器和减少器有效地将这个洗牌完成时间从4减少到2单位。此外，新兴的基于任务的分布式系统（例如，Ray、Dask、Hydro）支持具有动态任务图的应用程序。与MapReduce示例类似，我们可以通过选择不同的虚拟机放置任务来更改这些应用程序的传输计划。此外，许多深度学习作业是网络密集型的。这一观点得到了许多最近研究[14, 35, 40, 71, 86]以及在生产集群中的观察（例如，Microsoft [30, 41, 82]和ByteDance [65]）的验证。特别是，如§2.1中所述，深度学习作业包含allreduce阶段，用于在每次训练迭代中同步工作进程之间的梯度更新。如图5所示，allreduce阶段有多个候选拓扑。例如，allreduce流量可以通过连接所有工作进程的环以灵活的顺序发送（图5a和图5b）。或者，我们可以构建一个allreduce树，将梯度更新聚合到一个工作进程，然后将聚合的梯度更新沿相反方向发送回去（图5c和图5d）。不同的allreduce拓扑引入不同的传输计划。因此，给定网络特性，深度学习作业可以通过选择allreduce的算法和配置来更改其传输计划。

2.3 解决不匹配

现有网络抽象的黑盒性质和数据密集型应用的适应性造成了不匹配。数据密集型应用会受益于云提供商提供更多网络信息以配置其传输计划，但黑盒网络隐藏了这些信息。

基于黑盒抽象的解决方案。有两种方法可以在不修改现有黑盒网络抽象的情况下解决这种不匹配。一种可能的方法是让云提供商作为云服务优化租户的通信。为此，我们首先必须为云租户开发一个通用的网络API，以表达其通信语义、流量负载和优化目标。API的设计应该类似于coflow抽象[16]或虚拟集群抽象[9]，但更通用，以支持各种可能的流量模式和用户定义的目标。此外，最近的一项测量研究[78]显示，主要公共云在秒级时间粒度上存在高带宽变异性。因此，在保证网络服务水平协议（例如，通过网络API定义）的同时，云提供商很难，如果不是不可能，在集中方式中及时进行数千个租户的网络调度。

另一个潜在的方法是让云租户在其分配的虚拟机中运行广泛的性能分析[29, 49, 57]。例如，PLink [57]使用DPDK对VM进行逐对带宽和延迟的探测，并使用K均值聚类来反向工程底层网络拓扑。这使其能够通过选择良好的allreduce算法实现高性能。Choreo [49]使用3步测量来确定数据中心网络中拥塞的链路，以调度数据分析工作负载。类似的方法在几十年前就在广域覆盖网络上的Internet流量路由上探索过[5]：基于用户测量选择高性能Internet路径。不幸的是，这种方法既昂贵（因为每个租户/用户必须独立地对网络进行分析），又慢（因为探测阶段会延迟应用程序的启动）。PLink的作者告诉我们，他们使用10000个数据包来确定一对主机之间的带宽。Choreo生成了3分钟的探测流量，以推断10个VM的网络特性。

白盒网络抽象？鉴于这两种基于黑盒的方法的缺陷，我们反而探索了一种白盒方法：提供者向租户透露关于网络特性的基本信息，然后租户相应地优化其传输计划。

实现这一目标的一种可能方法是，云提供商向租户透露每个VM在物理链路层网络拓扑中的位置，并估算每对VM之间的可用带宽。然而，这种方法可能引发安全和竞争问题。首先，将虚拟机在物理网络中的分配公开可能会为云租户引入隐私风险。例如，恶意用户可以定位目标租户的VM并发动攻击。其次，公开的虚拟机分配信息可能会引起云提供商的竞争担忧。例如，这些信息可能对竞争对手学习云提供商的调度政策有价值，从而降低其竞争优势。第三，租户可以获得的带宽取决于所有租户的传输计划，一个租户传输计划的单一变化可能触发所有租户的重新计算。因此，实时更新带宽份额对于云提供商而言是计算上昂贵的。此外，应用程序的带宽还取决于其自己的传输计划。例如，在图2的情况2中，如果VM A发送一个额外的流，VM A的总出口带宽将增加到5 Gbps。因此，在不了解租户的传输计划的情况下，云提供商无法向其租户提供准确的带宽估算。

NetHint是云租户和云提供商之间的交互式机制，共同增强应用程序性能。其关键**是，提供者提供一个提示——对底层网络特性的间接指示（例如，租户的VM的虚拟链路层拓扑，共存租户数量，网络带宽利用率）给云租户。如图6所示，提供者提供了一个NetHint服务，定期（默认为每100毫秒）收集提示信息以捕捉底层网络特性的变化。租户应用程序可以查询NetHint服务以获取提示信息，然后根据提供的提示调整其传输计划。请注意，NetHint不会改变底层网络的公平机制。租户可以随时选择加入/退出，使用NetHint与否不会影响其在网络中的公平份额。该提示提供了一个白盒网络抽象，向租户提供了额外的网络信息。因此，用户可以在不经过大量探测延迟或与提供者的通信开销的情况下推断出他们的最佳传输计划。该提示既不暴露物理网络拓扑，也不暴露租户VM在其中的位置（例如，哪些机架）。与提供带宽信息相比，该提示减轻了提供者计算准确带宽分配的负担。而且，与计算带宽分配相比，获得准确的提示消息（例如，租户的VM的虚拟链路层拓扑，共存租户数量，网络带宽利用率）更容易。因此，提供者免受提供不准确信息的潜在风险。

我们要求NetHint具有以下特点：（1）易于部署：所有机制均可使用通用硬件实现；（2）低成本：云提供商可以以最小的CPU、内存和带宽成本收集网络特性。我们要求NetHint具备以下特点：（1）易于部署：所有的机制都可以使用通用硬件实现；（2）低成本：云提供商可以以最小的CPU、内存和带宽开销收集网络特性；（3）实用：数据密集型工作负载可以利用这些提示来实现高性能。为了实现这些目标，NetHint的设计和实现必须解决三个问题。首先，应该向租户提供哪些提示？其次，云提供商如何以较低的成本收集提示？第三，应用程序应该如何利用提示来调整其传输计划？

NetHint描述了连接租户VM的虚拟链路层拓扑。此外，NetHint向租户提供最近利用摘要以及在虚拟拓扑**享网络链路上的共存租户连接的计数。这些信息使租户能够根据网络中的拓扑和时间热点来调整其传输计划。此外，我们的设计确保NetHint唯一公开的附加信息是所有租户的聚合网络统计信息。因此，一个租户很难获取关于任何其他单个租户的信息。

对于第二个问题，我们首选的收集提示的方法是使用网络遥测在物理交换机中测量网络流量，例如，使用草图技术[54, 55]。然而，草图依赖于特定的可编程交换机功能，这些功能尚未广泛部署。相反，我们的原型采用了一种由主机驱动的方法，其中每台机器监视本地流量并将流级别的统计信息传输到NetHint测量平面。每个机架中的一台机器运行NetHint服务器进程，以聚合机架级别的信息。这些NetHint服务器使用周期性的全互联通信交换信息。云租户连接到本地NetHint服务器以获取提示。我们展示了这种方法使得NetHint能够以较低的CPU和带宽开销及时向租户提供提示。

至于第三个问题，我们考虑根据提示做出调整的两个方面。首先，我们观察到适应算法应该考虑应用程序的传输计划和语义，以最大化性能收益。为此，我们考虑了NetHint的几个用例，涵盖了一系列热门的数据密集型应用，包括（1）在分布式深度学习中选择allreduce算法，（2）为serving ensemble模型构建广播树，和（3）在MapReduce框架中放置任务。对于每种情况，我们展示了应用程序如何根据提示信息调整其传输计划。结论是，对于所有这些示例，租户可以通过简单的调度算法利用NetHint信息（§5）。

其次，我们探讨了适应的缺点：它引入了额外的计算开销，如果网络条件变化过快，可能是无效的，甚至有害或不稳定的。我们得出结论，适应算法应该根据网络变化的频率和适应开销使用不同的提示集。例如，我们发现如果一个应用程序在收集提示和计算传输计划方面具有可观的延迟，带宽信息可能已经过时，因此可能对应用程序性能产生负面影响（详见§6）。基于这一直觉，我们设计了一个应用程序根据提示灵活应对的策略：在网络条件稳定且适应开销低的情况下，应用程序使用带宽和拓扑信息来最大化适应性的性能收益。否则，应用程序仅使用稳定的拓扑信息（§6）。

3 NetHint概述 NetHint是云租户和云提供商之间的交互机制，共同增强应用性能。其关键**在于提供者向云租户提供一种提示——对底层网络特征的间接指示（例如，租户VM的虚拟链路层拓扑，共同承载的租户数量，网络带宽利用率）。如图6所示，提供者提供了一个NetHint服务，它定期（默认为100毫秒）收集提示信息，以捕捉底层网络特征的变化。租户应用程序可以查询NetHint服务以获取提示信息，然后根据提供的提示调整其传输计划。请注意，NetHint不会改变底层网络的公平机制。租户可以随时选择加入或退出——使用NetHint与否不会影响其在网络中的公平份额。该提示提供了一个白盒网络抽象，为租户提供了额外的网络信息。因此，用户可以在不需要与提供者进行实质性的探测延迟或通信开销的情况下推断出最佳的传输计划。提示既不暴露物理网络拓扑，也不暴露租户VM在其中的位置（例如，所在的机架）。与提供带宽信息相比，该提示减轻了提供者计算准确带宽分配的负担。此外，与计算带宽分配相比，获取准确的提示消息更加容易（例如，租户VM的虚拟链路层拓扑，共同承载的租户数量，网络带宽利用率）。因此，提供者免受提供不准确信息的潜在风险。 我们要求NetHint具备以下特性：（1）易于部署：所有机制均可使用商品硬件实现；（2）低成本：云提供商可以以最小的CPU、内存和带宽开销收集网络特征。（3）有用：数据密集型工作负载可以利用这些提示实现高性能。为了实现这些目标，NetHint的设计和实现必须解决三个问题。首先，应向租户提供什么提示？其次，云提供商应如何以最低成本收集提示？第三，应用程序应如何使用提示来调整其传输计划？

NetHint描述了连接租户VM的虚拟链路层拓扑。此外，NetHint向租户提供了有关虚拟拓扑**享网络链路上租户连接的最近利用情况摘要和计数的信息。此信息允许租户根据网络中的拓扑和时间热点调整其传输计划。此外，我们的设计确保NetHint公开的唯一附加信息是跨所有租户的聚合网络统计信息。因此，对于租户获取有关任何其他租户的个体信息是困难的（§4.1）

对于第二个问题，我们首选的提示收集方法是使用网络遥测在物理交换机中测量网络流量，例如使用草图技术[54, 55]。然而，草图依赖于特定的可编程交换机功能，这并没有被广泛部署。相反，我们的原型采用了主机驱动方法，其中每台机器监视本地流量并将流级统计信息传输到NetHint测量平面。每个机架中的一台机器运行NetHint服务器进程以汇总机架级信息。这些NetHint服务器使用周期性的全互联通信交换信息。云租户连接到本地的NetHint服务器以获取提示。我们展示了这种方法允许NetHint以低CPU和带宽负担为租户提供及时的提示（§4.2）。

至于第三个问题，我们考虑根据提示做出调整的两个方面。首先，我们观察到自适应算法应考虑应用程序的传输计划和语义以最大化性能增益。为此，我们考虑了NetHint的几个用例，涵盖了一系列流行的数据密集型应用程序，包括（1）在分布式深度学习中选择allreduce算法，（2）为提供集成模型构建广播树，以及（3）在MapReduce框架中放置任务。对于每种情况，我们展示了应用程序如何根据提示中的信息调整其传输计划。结论是，对于所有这些示例，租户可以通过简单的调度算法利用NetHint信息（§5）。

其次，我们探讨了调整的缺点：它引入了额外的计算负担，如果网络条件变化过快，可能会无效甚至有害或不稳定。我们得出结论，自适应算法应根据网络变化频率和适应开销使用不同的提示集。例如，我们发现如果应用程序在收集提示和计算传输计划的过程中具有非可忽略的延迟，带宽信息可能已过时，因此可能对应用程序性能产生负面影响（详见§6）。基于这一直觉，我们设计了一个应用程序策略，以灵活的方式对提示做出反应： 在网络条件稳定且适应开销低的情况下，应用程序使用带宽和拓扑信息来最大化适应性的性能收益。否则，应用程序仅使用稳定的拓扑信息（§6）。

4 提供NetHint服务 4.1 提示中包含什么？ NetHint向云租户公开了一个虚拟链路层拓扑T。租户的虚拟拓扑将网络抽象为一个树状数据结构，其中租户的虚拟机（VMs）是叶节点。树中的链接表示数据中心网络中一个或多个物理链接，而内部节点可能抽象出交换机和链接的区域。该原型使用一个三层树，捕捉了VM在数据中心中的分布，并将位于机架级别以上的网络结构折叠到一个单一的根节点。位于相同机架中的VM属于相同的子树。虚拟拓扑抽象不会显示租户没有存在的机架或服务器。由于通常观察到拥塞损失通常发生在机架级别[12, 43, 60, 89]，NetHint原型中的这些虚拟拓扑忽略了机架级别以上任何结构的拥塞[23]。通过在树中添加层，可以表示更多的结构。树的近似推测是基于数据中心网络能够平衡其负载，以便抽象节点的子节点之间的流量看到相似的可用带宽。关于数据中心高效网络负载平衡有丰富的文献[2,21,22,26,28,36,46,47,63,88]，其中一些可以使用商品硬件轻松部署。

NetHint允许应用程序对网络中的时间热点做出反应。为此，NetHint公开了对每个虚拟链接l的利用率的估算。回顾图2中的Case 1，现在假设来自VM A的橙色流只使用10 Gbps中的2 Gbps。如果VM B的租户知道网络利用率信息，它可以推断VM B可以以8 Gbps发送流量。因此，NetHint提供了（1）每个虚拟链接l的总带宽B_lt和（2）剩余带宽B_lr。然而，我们发现仅凭这些信息，特别是在链接拥塞时，应用程序无法调整其传输时间表。例如，即使一个链接l已经达到了100%的利用率，租户仍然可以通过l发送流量并获得公平的带宽份额。

共享对象和公平模型。实际上，带宽份额取决于云提供商实施的公平模型。对于基于RDMA的网络，自现代RDMA NICs可以配置为选择其中之一，自然可以实现每流的公平性和每VM对的公平性。对于基于容器的云，由于云用户无法修改内核TCP堆栈，可以自然地强制实施每流的公平性。对于传统的基于TCP和VM的云，许多最近的研究[18, 37, 62]描述了如何实施每VM对的公平性。随着现代交换机的可编程性越来越强，现在可以在网络中实施其他公平模型[74, 83]，例如每租户的公平性。考虑一个应用程序在100 Gbps网络链接上放置3个连接，并有来自3个其他租户的7个现有连接的情况。我们假设每个流都可以达到100 Gbps的吞吐量。根据每流公平性模型，应用程序应该获得30 Gbps的带宽。对于每租户公平性模型，应用程序应该获得25 Gbps的带宽。

该示例表明，带宽份额还取决于每个链接l上的共享对象数量。共享对象的定义取决于公平模型：在每流（每VM对，每租户）公平性模型下，它分别是一个流（VM对，租户）。

带宽估算。虚拟拓扑中的信息使租户能够有效地估算每个虚拟链接l上的可用带宽。更正式地说，考虑一个计划在其传输时间表中将k_l个共享对象放置在链接l上的租户。如果链接l是虚拟拓扑T中的一条网络链接（即不连接到任何VM），则租户获得的带宽份额可以估算为：

方程1表明，当链接未充分利用时，租户可以利用所有剩余的带宽 B_l_r，即使链接已经拥塞，租户也至少可以根据共享对象的数量达到其公平份额。

如果链接l是一条边缘链接（即连接到一个VM），带宽份额还受底层共享方法的影响。更具体地，用B_v表示共享方法提供的每个VM的带宽保证，我们有：

不准确性的来源和影响 我们承认方程1和方程2都是近似值，有时可能不准确。首先，一些共享对象（例如租户、VM对或连接）的流量需求可能小于其公平的网络份额，因此计算B_l_e的确切值需要知道每个共享对象的流量需求。由于这样做会引入安全问题，并且考虑到这类对象的数量巨大，NetHint不提供每个对象的信息。其次，由于虚拟链路对应于物理拓扑中多个并行路径的聚合，估算在这些平行路径上的网络负载均衡不足时可能不准确。我们注意到，在最近提出的数据中心网络负载均衡设计中，这种情况不太可能发生。

尽管在带宽估算中存在这些不准确性，但我们的结果（§8）显示，即使是三层树的近似也足以调整传输计划并改善目标应用程序的性能。此外，评估结果还显示，随着逼近质量的下降，这些好处会逐渐减弱。

缓解安全性和竞争问题。与暴露VM分配信息和物理网络拓扑的天真白盒解决方案相比，NetHint已经缓解了安全和竞争方面的顾虑。首先，NetHint不暴露已分配VM的物理位置，因此租户无法了解提供商的VM分配策略。其次，我们的网络统计信息是对所有其他租户进行聚合的，因此一个租户很难从中推断出任何其他个体租户的网络行为。最后，即使在当今的黑匣子模型中，租户VM之间的网络拓扑也是可访问的，通过用户探测方法，例如在PLink [57] 和Choreo [49] 中提出的方法。NetHint确实更容易访问这些信息，但我们认为这不会增加安全风险。请注意，NetHint并未完全消除这些问题，我们在§9中对其进行了讨论