摘 要
我们提出了OpenNetMon，这是一种方法和开源软件实现，用于监视OpenFlow网络中的每个流量指标，特别是吞吐量、延迟和包丢失。目前，isp为了满足客户的QoS需求，过度提供容量。软件定义的网络和OpenFlow允许更好的网络控制和灵活性，以尽可能高效地追求操作网络。OpenFlow提供了实现细粒度流量工程(TE)的接口，OpenNetMon提供了必要的监视，以确定是否实际满足端到端QoS参数，并为TE方法提供输入，以计算适当的路径。OpenNetMon轮询边缘交换机，即带有流端点的开关，其自适应速率在样本之间的流速率不同时增加，在流稳定时减少，以最小化查询的数量。自适应速率降低了网络和交换机CPU开销，同时优化了测量精度。我们证明，不仅本地链接服务于可变比特率视频流，而且聚合的广域网链接也受益于自适应轮询率，以获得准确的测量结果。此外，我们验证了吞吐量，延迟和包丢失的测量在我们的实验试验台突发的场景。
为了达成QoS协议和流量工程，网络管理的一个关键要求是准确的流量监控。在过去的十年中，网络监控一直是一个活跃的研究领域，特别是由于IP网络中流量的数量和数量庞大，以及部署测量基础设施的复杂性，使得在线检索和精确测量变得困[1]。
由于细粒度的监视需求，许多基于流的度量技术消耗了太多的资源(带宽、CPU)，而其他监视解决方案需要在硬件部署和配置管理方面进行大量投资。相反，Internet服务提供商(ISP)过度提供网络容量以满足QoS约束[2]。
尽管如此，过度供应与尽可能高效地运行网络存在冲突，并且不利于细粒度流量工程(TE)。而TE则需要粒度实时监控信息来计算最有效的路由决策。
最近的SDN提议——特别是OpenFlow[3]——引入了编程接口，使控制器能够执行细粒度TE，但是还没有实现完整的基于OpenFlow的监视提议。我们声称，由于缺乏在线和准确的监控系统，因此无法开发预期的支持TE的OpenFlow控制器。鉴于OpenFlow提供的接口使控制器能够查询统计数据并将数据包注入网络，我们设计并实现了这样一个粒度监控系统，该系统能够为控制人员提供他们所需的在线监控测量数据。在本文中，我们提出了OpenNetMon，这是一个POX OpenFlow控制器模块，它可以精确地监视每个流的吞吐量、包丢失和延迟指标。OpenNetMon能够在线监视每流吞吐量、延迟和数据包丢失，以帮助TE。
本文的其余部分结构如下:在第二节中，我们首先讨论ISP使用的现有测量方法和监视技术。第三节总结了OpenFlow及其我们的实现使用的特定选项，以及在OpenFlow网络中度量流量方面的先前工作。我们的OpenNetMon建议在第四节中给出，并在第五节中进行了实验评估。最后，第七部分对本文进行了总结。
传统上，在计算机网络中使用许多不同的监控技术。这些技术所依赖的主要度量方法类型及其带来的权衡将在下面的两个小节中进行讨论。传统上，每一种测量技术都需要单独的硬件安装或软件配置，因此实现它是一项冗长且昂贵的任务。然而，OpenFlow提供了实现大多数讨论的方法所必需的接口，而不需要定制。第三小节总结了isp用于监视其网络的几种技术。
网络测量方法大致分为两大类，被动测量法和主动测量法。无源测量方法通过观察来测量网络流量，而不以探测包的形式注入额外的流量。被动测量的优点是它们不会产生额外的网络开销，因此不会影响网络性能。不幸的是，被动测量依赖于安装网络内流量监视器，这对所有网络都是不可行的，并且需要大量的投资。
另一方面，活动度量向网络注入额外的数据包，监视它们的行为。例如，流行的应用程序ping使用ICMP包可靠地确定端到端连接状态并计算路径的往返时间。
主动和被动测量方案都有助于监测网络流量和收集统计数据。然而，需要仔细决定使用哪种类型的度量。一方面，主动测量会引入额外的网络负载，影响网络，从而影响测量本身的准确性。另一方面，无源测量要求网络中放置的观测信标之间保持同步，从而使监测过程复杂化。第三节讨论了ISP通常使用的被动和主动测量技术。
2.2 应用层和网络层测量
通常网络测量是在不同的OSI层上执行的。在应用程序层上的测量是准确测量应用程序性能的首选，isp通常不能访问终端用户设备，因此使用网络层测量。网络层测量使用基础设施组件(如路由器和交换机)来获得统计数据。这种方法并不充分，因为度量粒度通常仅限于基于端口的计数器。它缺乏区分不同应用程序和流量的能力。在第四节的建议中，我们使用启用OpenFlow的交换机和路由器保存每个流的统计数据来确定端到端网络性能。
2.3 现有测量部署
简单网络管理协议(SNMP)[5]是最常用的网络状态监测协议之一。其中，SNMP可用于从交换机请求每个接口的端口计数器和整体节点统计信息。自1988年开发以来，它在大多数网络设备中得到了应用。使用SNMP进行监视是通过定期轮询交换机来实现的，但是由于CPU开销，频繁轮询可能会降低交换机的效率。尽管供应商可以自由地实现他们自己的SNMP计数器，但是大多数交换机仅限于为整个交换机及其每个接口聚合流量的计数器，从而禁用细粒度流量工程所需的流级统计信息。因此，我们认为SNMP不适合基于流的监控。
NetFlow[6]提供了一个可伸缩的基于被动流的监视示例。它收集交通样本，并根据这些样本估计总体流量统计数据，这些数据被认为对长期统计数据足够准确。NetFlow使用1 / n随机抽样，这意味着它存储每个n个数据包，并假设收集的数据包代表通过收集器的所有流量。每个可配置的时间间隔，路由器将收集到的流量统计信息发送到一个集中的单元，以便进一步聚合。包抽样的主要问题之一是，如果注意到，小流量的代表性不足。此外，一个路径上的多个监控节点可能会采样完全相同的数据包，从而过度表示某个流量组，降低了准确性。cSamp[7]通过使用流采样代替包采样来解决这些问题，并部署了基于哈希的协调来防止包的重复采样。
Skitter[8]是一个CAIDA项目，它使用主动探测分析Internet拓扑结构和性能，使用地理分布信标执行大规模跟踪。它的探测包包含计算RTT的时间戳和估计测量信标之间的延迟。当Skitter适合生成总体网络延迟的粗略估计时，它不会计算每个流的延迟，因为除非安装了非常高密度的信标，否则不会遍历所有路径。此外，该方法还引入了额外的不精确性，因为之前存在的不确定性边际值的加减。
使用被动测量来测量数据包延迟稍微复杂一些。IPMON[9]提供了一种解决方案，它捕获每个TCP/IP包的头部，对其进行时间戳，并将其发送到中央服务器进行进一步分析。需要安装多个监视单元来检索整个网络的统计信息。如果技术非常精确(以微秒为单位)，则会由于与中央服务器进行必要的通信而产生额外的网络开销。此外，精度取决于监测单元时钟的精确同步。
虽然SDN并不局限于OpenFlow，但在OpenFlow之前就存在其他控制平面解耦机制，OpenFlow通常被认为是SDNs中配置和监控交换机的标准通信协议。支持OpenFlow的开关连接到中央控制器，如POX[10]或Floodlight[11]。控制器既可以用转发规则预先配置交换机，也可以对交换机发出的请求做出响应，当数据包与任何现有规则都不匹配时，交换机就会发送请求。除了管理转发平面之外，OpenFlow协议还能够请求每个流计数器的统计信息并向网络注入数据包，这是我们在第四节中提出的建议中使用的功能。
更具体地说，当一个新的、当前不匹配的连接或包到达时，支持OpenFlow的交换机向控制器发送一个PacketIn消息。控制器响应使用一个或多个流表修改消息(FlowMod)安装路径，并指示交换机使用PacketOut消息重新发送数据包。FlowMod消息指示空闲超时时间和硬超时时间，以及是否应该用flowremove消息通知控制器这样的删除操作。图1给出了流设置期间消息交换的示意图。使用PacketIn和flowremove消息，控制器可以确定存在哪些活动流。此外，flowremove消息包含最近删除的流的持续时间、包和字节数，使控制器能够对过去的流进行统计。我们在第四节中的建议将此信息与定期查询的流统计请求(StatsRequest)消息结合使用，如图2所示，以获取正在运行的流的信息，并定期向网络注入包，以监视端到端路径延迟。
OpenFlow对交换机和每条流统计数据的开放性已经在最近的研究提议中得到了体现。例如，OpenTM[12]通过跟踪每个流的统计信息来估计流量矩阵(TM)。应用程序查询按一定的间隔进行切换，并存储统计信息，以便派生TM。本文对几种轮询算法进行了实验，并对其精度进行了比较。当只轮询所有路径的最后一个开关时，会得到最准确的结果，而其他轮询方案，例如选择负载最少的开关轮询，或(非)均匀随机选择，只会得到稍微不那么准确的结果，与最准确的最后一个开关选择方案的偏差最多为2.3%。替代的轮询方案、偏好的非均匀随机选择开关路径的最后表现最精确而last-switch轮询,紧随其后的是统一的随机选择和循环的选择开关,当负载开关结束最后仍然有精度约在86 Mbps + 0.4 Mbps。但是，由于OpenTM仅限于生成供离线使用的TMs，并且不捕获包丢失和延迟，因此我们认为它不适合在线监视流。
OpenSAFE[13]侧重于将流量分配给监视应用程序。它使用的事实是，每个新的流请求都通过网络的OpenFlow控制器。控制器将新流量的创建转发给多个流量监控系统，该系统记录流量并使用入侵检测系统(IDS)进行分析。然而，OpenSAFE需要硬件投资来执行实际的监视，同时我们引入了一种机制，可以重用现有的OpenFlow命令来检索上述指标。
其他人建议设计一种新的协议，并行于开放流，以实现SDNs中的监控。例如，penSketch[14]提出了一种基于SDN的监控体系结构。然而，一个新的SDN协议需要升级或替换所有网络节点，isp将不愿意进行大规模投资。此外，新协议的标准化已被证明是一项漫长而乏味的任务。由于OpenFlow已经在数据中心环境中越来越受欢迎，并且越来越多地在commodity交换机中实现，所以使用OpenFlow的解决方案需要isp更少的投资来实现，并且不需要更大的社区进行标准化。因此，我们认为与OpenFlow兼容的监视解决方案(比如我们的OpenNetMon解决方案)更有可能成功。
在本节中，我们将介绍我们的监视解决方案OpenNetMon，它是作为OpenFlow控制器POX[10]的模块编写的。OpenNetMon不断监视预定义的链路-目标对之间的所有流量，包括吞吐量、数据包丢失和延迟。我们相信这样一个颗粒状的实时监控系统对于交通工程(TE)来说是必不可少的。
在下面的小节中，我们将首先讨论我们的实现如何监视吞吐量，以及如何确定正确的轮询算法和频率，然后讨论我们的实现如何度量包丢失和延迟。有人可能会说，在OpenFlow SDNs中测量吞吐量并不新鲜，尽管我们实现它是专门用于监视的，而不是用于生成流量矩阵，但我们是第一个将它与针对数据包丢失和延迟的活动每流测量相结合的。
4.1 轮询吞吐量
为了确定每个流的吞吐量，OpenNetMon正则查询切换到使用第三节中描述的消息检索流统计信息。对于每个查询，我们的模块接收发送的字节数和每个流的持续时间，使它能够计算每个流的有效吞吐量。由于任何节点对之间的每个流都可能得到控制器分配的不同路径，所以OpenNetMon会定期轮询指定要监视的每个节点对之间的每个不同分配路径。
尽管随机或轮询每个路径的开关被认为是最有效的，并且仍然足够准确的[12]，我们轮询每个路径的最后一个开关。首先，在具有多个流的大型网络中，轮询交换机的选择变得更加复杂。当存在更多的流时，非边缘开关将更频繁地轮询，从而降低效率。此外，非边缘开关通常需要维护更多的流，这使得流统计数据的查询更加昂贵。其次，为了计算分段IV-B中的包丢失，我们周期性地查询和比较每个路径的第一个和最后一个交换机的包计数器。由于此查询还返回吞吐量计算所需的字节和持续时间计数器，因此我们决定将这些查询组合在一起，仅对每个路径的最后一个开关进行采样，以便进行吞吐量计算。
在大多数路由发现机制中，链路状态信息在拓扑变化和保证同步的规则时间间隔内交换，但是流的到达率可能会有很大的变化。正如我们将在下面简要说明的，因此有必要自适应地监视流行为，方法是在流到达时增加轮询间隔或更改它们的使用特性，并在流统计数据收敛到稳定行为时减少轮询间隔。
传输过程中信息的大量消耗以及内容的编码和压缩导致流的流量需求高度波动，例如，HD视频流所需的瞬时带宽可以在1到9 Mbps之间变化。虽然通过多路复用抑制了这种行为，但是这种行为甚至在聚合链接上也是可见的，如图3所示，在可用带宽测量15分钟包级跟踪100 Mbps日本WAN链接时可以看到这一点。为了促进高效的流量工程，并在高利用率下运行网络以节省第一节中讨论的成本，需要关于每个链接和流的当前吞吐量的准确信息。
在许多不同的链路状态更新政策提出了在过去几十年[16],我们的实验测量表明,基于绝对的还是相对的政策变化以及基于类或定时器策略不捕捉今天的网络流量的动态在足够详细级别作为一个输入流调度。图4对比的区别实际带宽10 Mbps的网络链接和访问带宽估计的一个相对改变政策:随着流迅速的变化要求,流的吞吐量是严重低估或高估的网络,从而超额认购和浪费资源,或潜在伤害流。这种行为是当前链路状态更新策略根据最近但仍然是历史的度量传播信息的结果，目的是平衡过高的更新率或容忍过时的信息。虽然这个特定的跟踪在原则上可以通过调优更新速率或选择不同的链接状态更新策略来更好地逼近，但是所有现有方法都存在基本问题:图5显示了作为更新策略和更新频率函数的平均相对估计误差。
在减少过时性的同时，更定期的更新并不一定能提供更好的流信息，因为图3或图4所示的复杂流特性的动态特性如果不使用无穷小的时间间隔及其高昂的开销，静态报告间隔就不能很容易地接近它们。为了避免这个问题，我们提出的OpenNetMon使用了一个自适应的流特性，当新流被接纳或流统计数据发生变化时，它会提高采样率，以便在静态环境中，当获得的新信息很少时提高分辨率和回退。
当基于网络状态的新细粒度视图重新分配流时，OpenNetMon的自适应特性在避免过多的路由抖动方面可能也很有用。对于动态网络中路径稳定性的讨论，我们参考[17]。
每个流的包丢失可以通过轮询每个交换机的端口统计数据来估计，假设链路包丢失和每个流的吞吐率之间存在线性关系。然而，当流量根据QoS参数或优先级进行排队时，这种与流吞吐量的线性关系就不成立了。相反，我们通过轮询每个路径的第一个和最后一个交换机的流统计信息来计算每个流的数据包丢失。通过将源交换机包计数器的增量与目标交换机包计数器的增量相减，得到了对过去样本包丢失的精确测量。
然而，路径延迟更难测量。测量延迟不回避,被动的方式——这意味着没有额外发送数据包通过网络——OpenFlow由于不可行,不可能有开关标记样品包的时间戳,也不太可能让交换机复制和可预测的样本数据包发送到控制器相比有其内部到达的倍数。因此，我们使用OpenFlow的功能将数据包注入到网络中。在每个被监视的路径上，我们定期在第一个交换机注入包，这样探测包就会沿着完全相同的路径运行，并让最后一个交换机将它发送回控制器。控制器通过计算数据包离开和到达时间之间的差来估计整个路径延迟，减去从切换到控制器延迟的估计延迟。通过将立即返回给控制器的包注入RTT来确定开关到控制器的延迟，并将RTT除以2来计算给出Tdelay = tarrival - Tsent - 12
(RT Ts1 + RT Ts2)的答案的双向性，从而估计交换机到控制器的延迟。
第五部分的延迟实验表明，使用控制平面注入和检索探测数据包，使用OpenFlow PacketIn和PacketOut消息，会导致交换机控制平面的软件调度产生不准确的结果。为了确保测量精度，我们连接一个单独的VLAN，专门用于传输探头数据包，从控制器直接到所有开关数据平面。该方法省去了开关的控制平面软件，具有较高的精度。
为了使测量精度和包开销与每个流的大小匹配，我们为每个路径注入包，其速率相对于流吞吐量的底层和。也就是说，在某条路径C上，从节点A到节点B的所有流量中，每秒的数据包数量越高，我们发送的数据包就越多，从而可以准确地判断数据包丢失。平均每轮测量发送一个监测包。虽然这乍一看会带来开销，但是监视包是一个任意的72字节的小型以太网帧(包括序言在内的最小帧大小)，它是基于一个MAC地址对沿着路径转发的，该地址对标识其路径，并有一个包标识符作为有效负载。相对于默认的1500 MTU(在巨型帧中甚至更大)，导致没有802.1Q VLAN标签的帧数为1526字节，我们认为这么小的开销是对所获得的知识的合理惩罚。
在本节中，我们将通过物理测试平台上的实验来评估开放网络mon的实现。我们的测试台由两台运行库存Ubuntu服务器12.04.2 LTS的Intel Xeon
Quad核心服务器组成，其中1 Gbps的nic连接到4台运行库存Ubuntu服务器13.04的Intel Xeon Quad核心服务器，使用Open
vSwitch作为兼容OpenFlow的交换机。网络由运行POX OpenFlow控制器的相同服务器控制，如图6所示。所有的主机都使用1gbps以太网连接到它们的交换机，因此我们假设本地有足够的带宽。然而，开关间的连接被限制在100mbps。开关1-2和3-4之间的延迟等于1毫秒，而开关2-3之间的延迟等于5毫秒，以模拟广域网连接。此外，所有交换机之间的数据包丢失等于1%，导致平均数据包丢失略小于3%。使用NetEm[18]引入延迟和包丢失。使用这种拓扑，我们打算模拟一个小型的私有广域网，由一个OpenFlow控制器控制。
在整个过程中，我们使用视频流对流量进行建模。由于其突发性的流量，我们选择了一个H.264编码的电影，是流从服务器到客户端。图7显示了通过实现OpenNetMon与Tcpstat比较，我们的服务器和客户机之间的吞吐量。此外，图8显示了与配置的包丢失相比的包丢失情况。最后，图9给出了在我们的网络中测量到的延迟。
图7中所示的度量代表了Tcpstat和OpenNetMon执行的吞吐量度量，它们平均只相差16 KB/s(1.2%)，这表明大多数传输流量都被度量所考虑。然而，标准差为17.8%，乍一看，这似乎是一个相当大的误差。这种误差主要是由于两个测量装置之间缺乏同步造成的。由于我们无法同步最小1秒存储段的开始时间，因此在一个度量中属于一个存储段的流量被归入另一个度量中相邻的两个存储段。再加上我们交通的高度紧张，这就导致了高度偏差。然而，从OpenNetMon的测量结果来看，平均值的高精度显示了适当的精确度。事实上，我们选择了高度偏离的流量来证明我们在最坏情况下的测量场景中的实现，因此，我们声称我们的结果比流量不那么突发性的场景更可靠。
图7中的吞吐量测量还显示了偶然的峰值，随后或之前出现了突然下降。由于开关的流计数器更新频率和OpenNetMon的轮询频率匹配得太紧密，因此会出现绑定问题，所以引入了峰值。简而言之，发生的情况是，我们的系统在第一轮更新计数器前不久请求计数器统计信息，而它已经在相邻的一轮更新了。虽然从长期来看，差异是平衡的，但两个箱子的值都是相等的，但与期望值相反，导致标准差。
所述的边值问题不能通过减少或增加轮询频率来解决，在最佳情况下，误差幅度较小，但仍然存在。相反，两端都需要根据系统时钟实现更新和轮询频率，而不是使用流行的sleep函数，该函数由于操作系统调度器和轮询和更新进程占用时间而引入了轻微的漂移。使用系统时钟对更新和轮询计时，确保两个系统的采样箱同步。此外，交换机需要实现一个系统来相互排斥对计数器的访问，以确保流计数器在更新其所有属性之前不能被读取，反之亦然。另一个理想的解决方案是扩展OpenFlow，允许流计数器更新通过订阅以可配置的间隔发送到控制器。但是，由于这需要同时更新OpenFlow规范和switch固件，所以我们不认为它在短时间内是可行的。
由于一个时间样本内的丢包可能并不代表整个丢包行为，因此图8显示了通过计算路径上第一个和最后一个交换机的包计数器之间的差异计算出的丢包平均运行时间。虽然运行中的数据包丢失不是很准确，但是这些测量数据提供了一个很好的估计来检测服务退化。要获得更准确的流包丢失估计，可以使用端口计数器统计数据中的插值。
图10中的类别图证实了这些经验，显示基于控制平面的测量平均为4.91 ms, 95%的置信区间为11.0 ms。若平均值与期望值的差值已超过30%，则置信区间大于期望值的1.5倍，在实际应用中不可行。然而，基于数据平面的测量确实显示了7.16±0.104的准确估计值，这与稍微大一点的终端用户应用体验(7.31±0.059 ms)非常接近。应用程序延迟稍微大一些，因为从交换机到终端主机的链接延迟无法被OpenNetMon监控。
这些结果表明，由于软件引入的响应时间波动过大，控制平面不适合作为精确时延测量的介质。然而，我们能够通过使用专门配置的VLAN将控制器连接到数据平面来获得准确的结果，该VLAN用于将探测包从控制器转发到网络。
第六章 实现细节
OpenNetMon的实现是公开源码的，可以在我们的GitHub web页面[4]中找到。我们将其作为开源共享的主要意图是使其他研究人员和业界能够使用它进行实验，将其用作获取细粒度流量工程的输入参数的方法，并在适用时将其扩展到它们的使用中。虽然OpenNetMon被认为是一个单独的模块，但在技术上它由POX OpenFlow控制器中实现的两个模块组件组成。转发组件负责路径的保留和安装，而监视组件负责实际的监视。这两个组件都依赖POX发现模块来学习网络拓扑结构和更新。
与POX附带的一些组件一样，转发组件了解网络中节点的位置，并通过在交换机上安装每流转发规则来配置这些节点之间的路径。但是，我们已经实现了一些与我们将进一步阐述的其他POX转发模块不同的具体细节。您可以将此作为构建自己的转发模块的小指南。
1) opennetmon不预先计算路径，而是在需要时在线计算它们。在多路径环境中(例如，请参阅[19])，并非从节点a到节点B的所有流都必须遵循相同的路径，通过负载平衡或流量工程，任何两个节点之间最好使用多个不同的路径。为了支持监控多径网络，我们决定实现一个转发模块，它可以计算任意节点a到b的多条路径并从中进行选择，特别是支持在线细粒度流量工程，它可以使用SAMCRA基于多个指标计算路径
[20]路由算法，我们决定使用在线路径计算来实现。我们立即在所有必需的交换机上安装按流量转发规则。我们发现，模块附带许多配置了路径切换的控制器。这意味着一旦接收到不匹配的包，控制器就会在该交换机上配置特定的转发规则，重新发送该包，然后从路径上的下一个交换机接收到相同的包。此过程迭代，直到配置好所有开关。但是，我们的转发模块在从节点A到B的路径上的所有交换机上安装适当的转发规则，然后将路径上最后一个交换机的原始数据包重新发送到目的地。
3)在所有交换机的所有边缘端口上，我们立即将目标未知的广播消息和单播消息淹没。我们发现被分类为被淹没的包，或者由于它们的广播或组播特性，或者由于它们的目标MAC地址位置仍然未知，被逐个开关淹没的方法与前面提到的方法相同。最后，扩展树中的每个交换机都用一个相同的包与控制器联系，而该包的动作保持不变。此外，如果在此期间了解到以前未知的单播消息的目的地，则会导致转发模块安装从该特定开关到目标开关的无效路径。为了减少数据包到达时需要被淹没的通信开销，我们的实现将与所有交换机和所有边缘端口上的洪泛连接。
4)我们只在边缘端口上“学习”MAC地址，以防止学习主机无效的开关端口位置。
当安装了可能具有不同路径的新流时，转发组件向监视组件发送一个事件。执行此操作后，监视组件将把边缘开关添加到自适应计时器迭代的列表中。在每个定时器间隔，监视组件从所有流目标和源开关请求流计数器。流计数器包含包计数器、字节计数器和每个流的持续时间。通过存储上一轮的统计数据，可以确定这些计数器的增量来计算每流吞吐量和数据包丢失。
第七章 总结
在本文中，我们提出了OpenNetMon，这是一个POX OpenFlow控制器模块，它监视每个流的QoS指标，从而支持细粒度的流量工程。通过以自适应速率轮询流源和目标交换机，我们在最小化网络和交换机CPU开销的同时获得了准确的结果。每个流的吞吐量和包丢失来自查询的流计数器。相反，延迟是通过将探测包直接注入交换数据平面，沿着相同的路径(即节点、链接和缓冲区)移动，从而确定每个流的实际端到端延迟来测量的。我们已将建议的python实现代码作为开放源码发布，以支持在软件定义的网络中进行QoS领域的进一步研究和协作。
我们在一个模拟小型办公室间网络的硬件测试台上进行了实验，同时加载了具有高突发性能的流量。实验测量结果验证了所测吞吐量和监测时延的准确性，而数据包丢失则较好地估计了可能的业务分解。
基于[21]中的工作，我们进一步建议将微流划分为一个更大的流，直到识别为大象流，从而消除微流带来的开销。这可以防止控制器被无关紧要但可能数量众多的流潜在地超载。在未来的工作中，我们打算使用OpenNetMon作为响应式实时QoS控制器的输入生成器，用于重新计算和重新分配路径。
