Delayed Installation and Expedited Eviction:
An Alternative Approach to Reduce Flow Table Occupancy in Sdn Switches
摘要
有限的流表大小限制了SDN的应用，一种常见的克服这一缺陷的方法是识别“大象流”（elephant flows）并且专注于它们。【“大象流”：在网络链路中，TCP或其他协议建立的总字节数极大的连续数据流，“大象流”的数目不多，但是在一段时间内或会占据总带宽的一定份额。https://en.wikipedia.org/wiki/Elephant_flow】但是没有一个合适的评估标准去评判这一举措。本文选择了一个“成本函数”（命中率）和一个“目标函数”来优化平均流表占用率并提供最佳解决方案。我们将这一问题类比为“背包问题”，分析如何最小化流表占用率，分析与OpenFlow中默认的空闲超时机制（the default idle timeout mechanism）的相似与不同之处。我们还提出了一种新方法，可以从背包模型分析中获得的领悟（insight）来最小化流量表的占用。我们的解决方案通过RST/FIN包来预测TCP流的结束以加速流表规则的删除（eviction），通过创建（incubate）一些非TCP流来延迟流表规则的建立。这些方法在不同的网络环境下将平均流表占用率降低了16%-62%，引起的命中率的降低不到1.5%。通过跟踪三个真实世界的数据包，我们将我们的方法与理论上的最优解：现在OpenFlow使用的静态的空闲超时机制以及重探测器检测（heavy hitter detection approaches）做了比较。【“重探测器检测”：heavy hitter是指频繁出现的数据项，某实体的某部分行为在以包数量、字节数或者连接数等单位计算时累计超过一定程度】我们提供深入分析在哪些场景（when and where）下我们的方法优于其他方法，同时分析为何在某些场景下使用基于速率的重探测器检测会更好。
Ⅰ.简介
软件定义网络（SDN）通过控制流表（flows）来提高网络性能和实现新型服务。SDN单独管理每一项流表，以实现对网络的最终控制以及网络资源如何使用。新的控制器通常会主动预先设置一些流，但是这种情况通常不会免费。在OpenFlow中，将所有流量都单独管理不是特别实用，因为我们将需要一个大的表去为所有的流表项建立规则，这将会产生流量设置延迟，会对短流量产生较大影响，并且每一次管理都需要启动控制器，这使得对控制器的要求很高，控制器将会成为性能瓶颈。
在本文中，我们关注有限的流表问题。如果我们不能单独管理每一条流表项，那么哪些流表项是需要单独管理的，哪些又是可以集中管理的？单独管理流表项能够是我们对整个网络中数据包的流向有更好的控制，我们将这些被单独管理的流表影响的数据包为“提升包”（promoted packets）。现在的问题是，在流表大小有限的情况下，哪些数据包应该被“提升”？
我们将在模块Ⅱ深入讨论heavy hitters，即当下常见的一种处理有限流表的方法：关注“大象流”（elephant flows）。本文提出以下的问题：关注“大象流”是否是最好的减少流表占用的方法？在一个“大象流”结束之前删除有关该流的规则，是否能起到更好的效果，同时促进一些小的流量？是否有必要采用一些短小的经常被提及的流量？（例如要求高速率流量的大小可以大于阈值【3】，或者速率可以在多个间隔中高于阈值【35】）本文旨在强调解决这些问题的重要性，并且初步尝试实践这些思路。
为了回答上述问题，我们思考一个更重要的问题：哪一条是被选数据包的最佳传输路径？获知这条最佳路径可以使我们更好地分析现有的解决措施（包括现有的“大象流“监测措施），同时提供有效的思路来设计新的可供选择的使用的解决方法。我们将会在之后详细描述细节信息，最佳解决方案依赖于使用该措施的应用，这也是常常忽视的。
首先，我们为这个优化方案定义一个目标函数以及一个成本函数。许多推荐使用的重探测器检测方法或者应用都有一个缺陷，就是没有定义目标函数和成本函数。这些方法仅仅依赖于直觉，如果将资源分配给频繁出现的数据项（heavy hitter），将会获得很大的好处。即使那些从理论上分析其提出的解决方案的性能的人【25】，也没有解释为什么将重点放在“elephant flows“上。不定义目标函数和成本函数，可能会导致使用heavy hitter detection的一些直接或间接成本。
虽然本文论证了定义目标函数以及成本函数的重要性，但是并没有找到一个最佳的定义方法。在本文中，我们研究heavy hitters的动力是在因特网上的Zipflike distribution（【39】指一小组占据着大部分通信流量的流量）。因此，似乎与该目标相匹配的主要成本函数是命中率。我们将要使用这个成本函数来比较之前的专注于heavy hitters的解决方案。我们定义“命中率“是指promoted packet占总数据包的比例。
如果我们的目标是通过最小化流表占用来解决流表大小有限制的问题，我们需要决定是需要最小化流表占用的平均值、中位数还是最大值。虽然在一段时间内的流表占用最大值似乎是正确的最小化对象，但是本文认为，平均表占用率（典型情况）和99th percentile（表示一种高负载的情况）将是更好的最小化目标。我们提供了一些关于真实数据的实验结果，这些结果显示了为什么流表占用率的最大值可能不是一个最好的最具有代表性的最小化目标，同时由于99th percentile与平均表占用率密切相关，当我们最小化平均占用率时，99th percentile也将会被最小化。因此，我们将平均表占用率作为优化目标，同时在评估中提供并分析最大流表占用率和99th percentile占用率的结果。
在模块IV，我们设计了一个模型并且解决了最小化平均流表大小问题，同时将流表命中率问题描述为一个背包问题。这提供了一个最佳的解决方案，同时可以被用作一个评估其他方法的标准。但是，这个方法需要所有数据包到达事件的完全信息，显然，这是不切实际的。在模块IV-A中，我们比较了背包问题的解决方案和现有的OpenFlow使用空闲超时来管理表占用率的方法，同时得出了它们的相似性与不同之处。有意思的是，背包问题的解决方案可以被描述为一个高级一点的空闲超时管理机制，因为它智能地弃用那些已经超时的流表。我们使用这一思路来设计一个使用简单的启发式模拟背包的解决方案。
我们的解决方案基于两项技术，其一是我们加快了对已安装规则的驱逐：一旦有该流程已完成或者即将完成的迹象，我们就将该流表项删除。我们将会展示，这一简单的改变将对减小流表占用率有很大的影响。我们依赖TCP FIN以及RST首部的flag标志来预测一个TCP流何时结束。我们对现实网络的追踪显示，超过97%的TCP流在第一个FIN/RST包之后最多有两个数据包，而在这些情况的一半中，FIN/RST数据包是流的最后一个数据包。其二是我们为非TCP流延迟流表规则的建立。由于大多数这种流都很短，我们将在推广（promoting）它们之前等待多接受几个数据包。
我们将我们的“延迟安装和加快驱逐”措施与现在的OpenFlow的静态空闲超时机制以及来自大型网络（两个数据中心和一个ISP）的三个真实数据包追踪的背包解决方案。我们的解决方案将不同网络情况下（命中率降低不到1.5%）的平均流表占用率减少到16%-62%。
另外，我们将背包解决方案以及我们提出的方案与基于尺寸和基于速率的“大象流量”检测器进行比较。我们讨论了在何种情况下，我们的解决方案将优于或劣于“大象流量”检测器。这里需要强调，我们不是想指出我们的方案与“大象流量”检测器是好是坏，只是简单地指出哪一个更胜一筹。我们展示了一些我们方案更具有优势以及“大象流量”检测器更具有优势的场景。这将为应用设计者提供参考，以决定是选择哪一种方案。
这是我们主要的贡献：
- 我们认为，平均流表占用率和99th percentile的占用率是衡量以及减少流表占用率的更好指标，与最大流表占用率相比，平均流表占用率（或99th percentile占用率）和命中率（或被提升的数据包的比例）可以用作“大象流量“检测器的候选者。
- 我们提出了解决问题的最佳方法（即理论上最好的方法）。 我们分析了这种最优解与当前OpenFlow的空闲超时机制之间的异同。
- 我们基于分析提出了一种实用的方法，可以加快规则的弃用同时延迟规则的安装。
- 我们描述了一些相当小的空闲超时时间（比如小于1s，而不是现在使用的在floodlight【15】中的5s，在POX【32】中的10s，在Juniper OpenFlow【19】中的至少11s，在一些OpenFlow交换机【8】中的高达60s），较小的空闲超时时间同样可以减小流表占用率，并且建议在OpenFlow规范中将空闲超时的单位从几秒改为毫秒。非常小的空闲超时会导致频繁的流量驱逐和重新安装，但在流量表大小是主要瓶颈的某些情况下可能会有用。 我们认为这是一个使用缓存技术来克服这种缺陷并创建一种新方法来解决有限表大小的机会。
- 我们将我们的新方案与背包解决方案、现有的“大象流量“检测方案（基于尺寸或基于速率）分别在3个不同的数据集上进行比较，并分析每个数据集上，哪个方案是更好的选择。
Ⅱ.“大象流”的简单实验
在SDN中对所有流量单独管理是一个巨大的挑战，因为OpenFlow交换机中的流表大小是有限制的【8】【24】【46】。不同的OpenFlow交换机提供的流表大小仅仅1k【36】、2k【18】，或者最多小几千条流表【8】【45】。另外，这个限制可能会在不久的将来继续存在，流表的TCAMs，是较昂贵的，耗电的，同时在芯片上占用空间也很大。
有限的流表迫使控制器在安装新的规则时需要驱逐原有规则，或者拒绝安装新的规则【45】。在第一种情况下，如果有突发的小流量（比如，SYN泛洪），需要驱逐大多数活动流【31】，在第二种情况下禁止了新流的正确管理（例如，执行QoS）。
在SDN网络或者传统网络中使用的一种常见的方法是推进属于长流的包【26】，即elephant flows或者heavy hitters，同时使用聚合来管理小流量（例如mice）（例如，在Mahout【8】，DevoFlow【7】和Hedera【13】中使用ECMP）。当使用“大象流量”检测时，控制器仅为“大象流量”单独建立流表规则。
抽象的“重击球手检测问题”（例如在一个连接中发现一个频繁出现的包）是一个众所周知的经典问题【5】【30】。在网络应用中使用“重击球手检测”的想法源于对网络流量的分析：当网络中的大部分流量都很小时，有极少的流量是相当大的，这些相当大的流量占总流量比重较大【12】。例如，前10%的流量占用了总流量的90%【12】。人们使用heavy hitters和elephant flows来代指上述在众多小流量中占据较大比重的极少数的大流量。
尽管对于heavy hitters的初始定义是基于流表的大小【11】，后来的定义沿伸到其他方向，包括流的类别【22】：高速率流量（有时指的是cheetahs）、生存期长的流量（tortoises），或者是那些在不同时期突发的流量（porcupines）。对elephant flows的不同定义是有联系的，例如大流量通常拥有高速率【22】。
但是，elephant flows的定义通常基于他们的大小或者速率。在基于大小的定义中，如果一个流的总尺寸高于一个阈值，就被定义为一个elephant flows【9】【20】【23】【25】【27】【28】【34】【40】。这个尺寸通常被定义为是包的数量【28】【34】，尽管有些应用使用总字节数来定义流的尺寸【23】。这个阈值可以是一个固定的数值（例如，20个包【34】或者1000个包【28】），或者可以是基于通信量（例如占总通信量的1%【37】，占10%【9】，或者是基于流量份额的前k个流量【20】）。考虑到收集流的实际大小将会具有高额开销（例如开启流量计数器可能需要几秒时间来完成），一些方法使用估计的流量大小来检测“大象流量”。
另一个常见的定义“大象流量”的方法是基于它们的速率【3】【4】【6】【17】【24】【43】。流量的速率是指在一段固定的时间间隔内（例如1s【17】，5s【6】【24】，或者1min【43】）的数据包数量或者字节数。与基于大小的定义类似的是，这个阈值可以是固定的（例如在一个时间间隔内100KB【24】），或者是依赖于通信量（例如，在一个时间间隔内占总通信量的5%【5】，10%【17】，或者是前K【43】）。
“大象流量”被用来解决一个在网络中大范围的资源分配问题【2】。一个直观感受是因为“大象流量”占网络通信的绝大部分，通过将大部分的资源分配给这些“大象流量”，我们可以通过有限的资源收获尽量多的回报。
在OpenFlow交换机的流表大小受限的情况下，我们可以预测通过关注“大象流量”，我们将很好地控制在网络的中的绝大多数的数据包，并且维持的流表大小相当小。因此，基于“大象流量”的探测具有各种不同的解决方案（例如【25】【34】【37】）。这些解决方案大部分关注解决基于多个流的课伸缩性问题【34】【37】，并且希望帮助网络管理员更好地了解网络通信流量【37】。
对于基于尺寸的“重击球手检测问题”有一个隐含的假设，就是一旦一个流被单独管理，它在接下来的通信中仍然是被单独管理的。例如，Hedera【13】最初将所有流量都视为小流量并使用ECMP单独管理。一旦一个流被认定为heavy hitter，就会为该流设置一个单独的规则，这个流将会被单独管理直至被驱逐（比如是空闲超时了）。一些“大象流量”在它们生存周期的绝大部分时间仍然是“大象流量”【43】，这主要对于一些极大的流量成立。如果我们扩大象流的定义（即使用较低的阈值），这类流量的比率将降低。
III.研究动力与问题的定义
对于“重击球手问题“的解决方案是：（i）定义“heavy hitters”（ii）通过将资源只分配给“heavy hitter”来解决给定资源分配问题。在第一部分（“重击球手检测”），性能优劣通常通过方案对“heavy hitter”检测的效果来评判（例如，通过报告传统的分类指标，如精准度/召回度来定义heavy hitter【3】）。第二部分的评估依赖于一个基于原始问题定义的目标函数（例如，对于异常检测的精准度/召回率）。【精准度：precision：正确被检索的/实际被检索的；召回率：recall：正确被检索的/应该被检索的https://www.cnblogs.com/sddai/p/5696870.html】
这个方法存在两个问题。第一，将heavy hitter detection与剩余的问题分离，我们将会忽视一些关于heavy hitter detection的成本问题：探测heavy hitter的直接成本（需要的带宽、处理过程等）；heavy hitter detection的固有局限性（误报/否定）；在流量被标记为“大象流量”之前就丢失了一些包（“大象流量”检测的延迟）等。第二，将这些资源分配给heavy hitter将不能保证整体的目标函数性能最佳。大多数利用heavy hitter的解决方案没有直接定义目标函数，并且仅仅依赖于直觉来提供有限的资源，我们如果将资源分配给heavy hitter，将会获得大部分的优势【14】。
我们认为明确地定义目标函数和成本函数是很关键的并且不容忽视。明确定义目标函数和成本函数可以：（i）帮助定义heavy hitter detection的最佳参数（例如，标记一个流是“大象流量”的阈值）（ii）将heavy hitter detection与其他可能的方法对比，来解决资源分配问题（iii）通过完全绕过heavy hitter detection可以获得更简单的解决方案，同时获得相同甚至更好的回报。
我们从目标函数的优化开始。首先，我们需要解释一个关于减小表大小的模糊度函数：我们将考虑最小化流表的最大占用率（最坏情况）。或者也会考虑减小平均流表占用率（因为更低的平均流表占用率将会使功耗更低）。我们也会考虑一个特殊情况下的流表占用率（例如99th percentile）来关心拥塞状况。
之前的heavy hitter detection仅将流表大小的限制作为研究动力，而没有讨论是需要减小最大的流表占用率还是平均的流表占用率。另外，他们并不总是关注流表占用，而是关注对于heavy hitters的检测效果（例如，显示识别heavy hitters的精准度/召回率【3】），或者关注使用heavy hitters的应用（例如，对于异常检测的精准度/召回率【33】）。
在之前的工作中，将流表占用率的最大值【8】作为应该在流表中定义多少接口的一个重要的限制条件。我们认为流变占用率的最大值不是评估的最佳指标，而且应该考虑典型的表占用而不是最坏的情况【10】。
关于流表占用最大值的第一个问题是它可能被一个孤立的事件所影响，造成流表占用率的增加。这可能是一个例如SYN泛洪攻击的异常【31】，或者是一个例如P2P应用尝试下载文件、在短时间内建立与另外对等端口的连接的情况。
第二个问题是尽管我们知道通信情况或者表占用的情况，也不能提供任何关于流表占用最大值的有用的理论基础。例如，尽管我们可以知道流表占用的均值与方差，但是也不能对占用率的最大值进行约束。
最后，流表占用也可以有一个heavy-tail distribution，我们使用三种不同的真实数据包跟踪检查了OpenFlow规范中默认的被动方法的流表占用情况（图1）。我们将在接下来的模块Ⅵ进行深入讨论，为流表占用的最大值有一个heavy-tail。例如，当流表占用最大值可能高于μ+40σ（μ是在模拟窗口期间流表占用平均值，σ是流表占用的标准差），95th percentile少于μ+2σ，99th percentile少于μ+5σ。这些结果涵盖了我们运用的不同的测试方法（包括，基于大小的heavy hitter，基于速率的heavy hitter，默认的OpenFlow空闲超时机制，背包解决方案，以及我们提出的新方法）。
结果，我们建议考虑平均表占用率（例如，如果我们考虑诸如功耗等因素）或者是99th percentile（例如，如果我们对表占用的极端情况感兴趣，这将与我们考虑最大表占用率类似）作为减少流表入口的标准。在99th percentile的情况下占用率少于μ+5σ，将这两个标准视为目标函数的结果是类似的，因为减少平均表占用率也会降低99th percentile（正如我们接下来会讨论的使用不同方法的结果所示）。例如，当我们在一个数据集中节省了41%的平均表占用率，我们还在99th percentile中节省了42%。在另一个数据集中，我们节省了62%的平均表占用率，我们在99th percentile中节省了67%。因此，我们将使用平均表占用率作为我们优化的目标函数。
我们注意到这个问题还有另一方面。表占用率指标只表示我们通过不建设一些流表来节省空间，但是同时，我们还应该定义一个成本函数来表示当我们不建设这些流表项时付出的代价。根据对用户应用程序的重要性的权衡，我们可以选择不同的成本函数。例如：
- 没有被建立流表项的数据流的数目
- 属于没有被建立流表项的数据流的数据包的数目
- 丢失的数据包的数目（由于没有被建立流表项，或者在建立流表项之前被丢失）
- 系统用于决定是否需要为一个新的流建立流表项的耗时
- 用于建立流表项或删除流表项的耗时
我们简单地假设我们可以使用单一的方法（例如，只关心“大象流量”）而不关注更高层次。最佳成本函数的选择主要取决于应用程序和网络特征。例如，那些没有被建立流表项的流可能对于安全应用（例如，访问控制）更加重要，因为这些流可能表示着违规的数量。另外，负载平衡应用程序主要关注命中率。最后，对于故障转移的应用程序，对于时间的优化可能更加重要，因为它可以代表响应时间。
本文并不讨论与选择最佳的成本函数，而是将我们的方法与先前报告的结果进行比较，希望选择与结果一致的成本函数。我们关注heavy hitters的主要动机是利用类似Zipf的互联网流量分布【39】，这可以表示我们的目标是最大化提升数据包的数量。因此，我们将命中率是为我们的成本函数。我们将promoted packets的数量视为命中，其余部分视为没有命中，并旨在最大化命中率（最小化未命中率）。
Ⅳ.背包解决方案
既然我们已经正式地定义了一个成本函数（命中率）和一个目标函数（平均流表占用率），我们可以解决通过哪一个最好的方法去选择流表项的问题。
考虑在一个oracle SDN控制器中，它知道整个网络的拓扑结构以及网络数据流。这样的控制器可以添加在数据包到达之前添加流表项规则或者在数据包传输完成后删除规则，并且没有任何限制。这个方法将会命中所有的数据包，即命中率为1，但是这个方法的流表几乎在任何时候都为0，因为在一个包到来之前的a（a->0）时间内创建流表项，该包结束后删除流表项，该方法命中率为1，流表占用率为0，这提供了一种完美的解决方案，但是不切实际。
我们需要结合实际情况的限制，使得在控制器上的规则能够实用、有效。本文中，我们假设SDN控制器只能在到达交换机的那个流的数据包与交换机中的个别规则不匹配时才安装给定流的流条目（即，当时没有提升流并且数据包是未命中）。此限制将阻止控制器在数据包到达时间之前安装规则，排除了之前讨论的不切实际的完美解决方案。然而，控制器可以在需要时修改表中的现有规则（例如，改变其空闲或硬超时，或驱逐它）。
这个新定义的限制为我们提供了一种简单的方法来建模和衡量解决单个数据包的成本和回报。所有数据包对命中率的值都有相同的影响：命中每个数据包的好处是相同的，无论这个数据包属于哪个流。但是与每个数据包相关的成本取决于它何时到达。
我们考虑一个给定的数据包x，这个数据包属于流flow(x)，在时间time(x)到达交换机。假设prev(x)是在flow(x)中这个数据包之前的数据包，如果x是第一个数据包，则prev(x)=空集，time(空集)=负无穷，我们可以定义包x的到达间隔是：
inter(x)=time(x)-time(prev(x))
平均流表占用率（ATO）是表占用率-时间图表下的面积除以间隔持续时间。因此，它也等于所有规则的活动时间之和除以间隔持续时间。如果我们假设规则永远不会在表中停留一段时间却不在该时间间隔结束时命中数据包，那么一个规则的活动时间将等于该规则提升的数据包的成本总和。我们将ATO重写为：
这为我们提供了一个完整的数据包促销成本/奖励模型：促销每个数据包的奖励为1，其成本为inter(x)。在实现特定命中率的同时找到用于促销的分组以最小化平均表占用率的问题可以被建模为背包问题。
问题：假设流表是一个背包，我们想用数据包来填充这个背包（即，选择需要推广的数据包）。选择每个分组x的成本（即权重）为inter(x)，并且奖励是1，目标是在填充背包的同时最小化权重（即，实现诸如N个分组的特定命中率）。
这是一个0/1背包问题的特例（因为我们最多可以选择每个对象的一个副本），这里所有物体的重量都等于1，这种限制允许我们使用简单的贪婪算法来解决问题，我们将此数据包推广方案成为背包解决方案。
解决方案：将数据包按照它们的成本（到达间隔时间）进行排序，开始推广具有最少到达间隔时间（inter(x)最小）的数据包，知道达到目标命中率（即，背包变满）。
运用这种贪婪算法解决我们问题的主要原因是权重相等，当所有权重相等时，可以轻松地将背包中的每个项目替换为一个未选中的项目，如果更换的项目的worth更多，则就具有了一个更好的解决方案。如下是上述的论证：
证据：假设我们的数据包为X={x1,x2,x3,…,xp}，有一个更好的解决方案为Y={y1,y2,y3,…,yp}，Y具有比X更低的ATO：
简单地说，假设每个数据集的数据包按照inter(x)来进行排序：
因为X≠Y，且|X|=|Y|，在X中至少有一个包在Y中没有出现，反之亦然。假设xa是X中inter(x)最小的数据包，但不是Y中的，yb是Y中最小的但不是X中的。我们将会得到inter(xa)≤inter(yb)，因为我们已经从最低到达时间到最高到达时间添加了数据包，在我们的解决方案中有xa，但是没有yb。
既然inter(xa)≤inter(yb)，我们可以将Y中的yb替换为xa，从而产生另一个解决方案Y2，其中|Y|=|Y2|，ATO(Y2)≤ATO(Y)，我们可以重复这个过程来创建Y3，Y4，……，Yk，直到X=Yk，因为在每个过程中，Yi都比Yi-1更多一个与X相同的数据包。因此：
ATO(X)=ATO(Yk)≤……≤ATO(Y2)≤ATO(Y)
这违背了ATO(Y)<ATO(X)的假设，完成了证明。
这个证明意味着，与heavy hitter推广方案中发生的情况不同的是，当我们想要选择最佳分组以促进最小化ATO时，每个流中的分组数量并不重要，另外，流的历史（例如，先前分组的到达间隔时间）对于是否应该提升这个流的下一个分组没有任何影响。唯一重要的因素是当前数据包的到达间隔时间。因此，最好使用较短的非“大象流量”替换具有较大到达间隔的“大象流量”。我们将在下个部分详细阐述。
A.背包与空闲超时
上一节中介绍的背包解决方案在理论上是最优的，但假设控制器事先知道每个数据包的到达时间，这是不切实际的。作为设计实际版本的背包解决方案的第一步，我们分析了背包解决方案与当前OpenFlow交换机使用的空闲超时机制之间的相似性。
当前的OpenFlow实现依赖于空闲超时来识别和驱逐来自流表的非活动和已完成的流：交换机驱逐任何超过空闲超时持续时间且未命中任何数据包（由控制器设置）的规则。我们将此方法称为静态空闲超时。
当一个流的第一个数据包到达交换机时，没有活动的流表项来处理该数据包，数据包将被丢弃并发送到控制器，控制器安装一个属于同一流的未来数据包的新规则，具有空闲超时时间t，该规则匹配inter(xi)≤t的任何后续数据包，如果inter(xi)＞t，这条规则将会在xi数据包到达之前被丢弃。该数据包将被发送到控制器，并安装新的规则，这个过程一直将重复到该数据流结束。
在静态的空闲超时方案中，所有的满足inter(x)≤t的数据包x都将会被提升，其他的数据包将会被丢弃。这与背包问题的解决非常相似。背包解决方案选择inter(x)的截止值来提升与空闲超时机制中类似的数据包。这两个方案将产生完全相同的促进数据包集合。
但是，在这两种方案中有一个极大的不同之处。当使用静态空闲超时机制时，如果两个数据包的到达间隔大于静态超时时间t，那么第二个数据包将会丢失，但是流表项将会存活t：从第一个数据包到达时经过t。在背包解决方案中，当第一个数据包到达后，流表将被立即逐出。这样在两个数据包到达间隔内在流表内将没有流表项。
在流的最后一个数据包之后也会发生同样的情况：在静态超时时间机制下，流表中将会有t时间的流表项，而在背包解决方案中，流表项将被立即驱逐。这种比较强调了当前流量管理方案中表空间浪费的关键来源，正如我们将在模块Ⅵ所示，这将会产生重大影响。
B.及时驱逐
我们对背包模型的分析揭示了背包解决方案如何减少流表占用率。在本节中，我们提出了这种技术的弱化版本，我们称之为“及时驱逐”，只需知道每个流何时终止（即哪个数据包是流的最后一个数据包）。虽然及时驱逐不是一种实用的方法（它需要知道每个流程何时结束），但它是设计一个减少流表占用率的实用解决方案的第二步。
背包解决方案假定控制器事先知道每个数据包的到达时间，这是不切实际的。更加合理的假设是，控制器仅知道每个流的最后一个包的到达时间，在这个假设下，控制器可以在看到第一个数据包时立即在交换机中安装新规则（类似于静态空闲超时方法），但在最后一个数据包之后立即驱逐该规则。这个解决方案的行为类似于背包解决方案，当它们不再匹配任何数据包时，将规则驱逐。唯一需要注意的是，它仅适用于流的最后一个数据包（而不是中间未命中的数据包）。
显然，这种方法对于表占用率的节省将小于背包解决方案，但我们将在第Ⅵ节中显示增益仍然很大，并且对于更大的空闲超时时间，对于及时驱逐效果更好。目前的超时时间在几秒到几十秒的范围内。
V.本文推荐的方法
为了及时地驱逐，控制器需要知道每个流的最后一个数据包，为了使这种要求成为现时，我们需要定义每个流的最后一个数据包。我们使用两种方法来实现这样的定义：加急驱逐和延迟安装。
A.加急驱逐
幸运的是，对于TCP流，我们可以依赖FIN和RST标志作为流即将结束的指示。虽然FIN或RST数据包不一定是最后一个数据包，但通常是最后一个数据包之一：在我们分析的数据集中，超过97%的数据流中在FIN/RST数据包到达之后最多还有两个数据包，在一半的情况下，FIN/RST是流的最后一个数据包。因此，我们可以乐观地将FIN/RST数据包作为最后一个数据包，并在此之后驱逐规则。
我们将这种在收到FIN/RST数据包就判定一个TCP流结束的想法称为“加急驱逐”。下面概述了我们如何推广TCP流并执行“加急驱逐”：我们一看到属于该流的被丢的数据包就立即为TCP安装流规则。一旦我们看到FIN/RST数据包，就立即驱逐任何流表规则，并且在将来不会为该流安装任何规则（即，将此流程标记为已完成）。
B.延迟安装
加急驱逐技术不适用于非TCP流，我们使用另一种称为“流动孵化”的方法来处理非TCP流。“流动孵化”基于以下的观察（我们对不同的包迹线进行了分析，见第Ⅵ节）：
流量持续时间短：与当前的空闲超时时间相比，大多数流的持续时间非常小，对于这样的流，我们在流表占用方面存在很大的浪费，因为流表规则的大部分活跃时间都用于等待最后一个数据包之后的超时。
许多小的非TCP流：虽然大多数流由TCP承载，但是存在大量非TCP流（大约50%的流）。并且，这些非TCP流中的大多数都很小（例如DNS解析生成的两个单个的分组流）。为这种流安装规则的好处是不存在的（比如，单个数据包）或者是可以忽略不计的（比如，表在多秒中仅匹配1个或2个数据包）。
对于非TCP流，没有一个通用的方法来可靠地预测流何时终止。因此，我们无法在最后一个数据包之后快速驱逐流规则。另一方面，大多数非TCP流只有少量的数据包。因此，最好不要立即为新的非TCP流安装流规则（即，延迟安装），并需要等待一段时间以确保这个流不是很短。我们可以认为这是为了防止非常短的流量结束时会耗费的空闲超时时间，代价是会造成这个非TCP流前几个数据包的丢失。控制器可以从每个流追踪到丢失数据包的数量，并且仅当控制器从该流中接收到超过预定数量的数据包时才安装流规则。在本文中，我们将介绍使用不同阈值的结果。注意如果阈值为1，则相当于没有使用延迟策略（即，我们在看到每个流的第一个数据包后就安装规则）。
C.实施实验
可以在当前的OpenFlow交换机上实现延迟规则和加速驱逐的安装。这两种技术都完全在控制器中实现，无需更改交换机。流动孵化（即，延迟安装）策略仅当控制器由于数据包没有命中而在交换机中建立规则时会改变，这适用于所有的OpenFlow交换机。控制器将会追踪这些流量。
实施加速驱逐的唯一需要是将所有的TCP中RST/FIN数据包的副本发送到控制器。对于OpenFlow 1.1+，可以通过安装规则将这类数据包发送到控制器中的第一个流表，然后在其他表中继续使用其他控制应用程序安装的规则。1.1之前的OpenFlow版本不支持多个表，我们可以安装一个具有最高优先级的规则来匹配TCP的FIN/RST数据包，并将它们发送到控制器，发然后控制器将单独将这些FIN/RST数据包发送到正确的端口上。
Ⅵ.实验结果
A.数据集
我们比较了从具有不同网络拓扑的大型网络收集的三个公共可用的针对不同流量的数据包跟踪的促进方法（例如，静态空闲超时机制，背包解决方案，及时驱逐，我们提出的延迟安装和加急驱逐，以及不同的重击球手检测方法）。这三个分别是：两个大学数据中心【1】和一个ISP【44】。
第一个大学数据中心的数据包跟踪技术（以下称为大学1）包含1小时流量的数据包跟踪（2009年12月17日，星期四，当地时间8：30-9：30）。这个数据集代表典型的数据中心（例如，我们稍后讨论的，大多数流量是基于TCP的）。
第二个大学数据中心的数据包跟踪技术包含2小时40分钟的流量（2010年1月22日，星期五，当地时间11：00-13：40）。这个数据集表示针对特定的应用程序进行了优化的专用数据中心。例如，在这个数据集中，几乎整个流量都是基于UDP的，这可以代表使用QUIC协议的数据中心可以获得比TCP更好的性能【41】。
第三个数据集来自ISP网络：WITS ISPDSL-Ⅱ数据集【44】。这个数据集包括2010年1月来自新西兰ISP的一周数据包标题跟踪。它包含超过1.14亿个数据包，其中包含超过8TB的数据，包含来自ISP住宅客户的所有流量。这个数据集非常适合代表非数据中心的网络，例如，家庭网络、小型企业，甚至是拥有许多计算机的企业网络，但通常不运行在数据中心中看到的大型应用程序。数据包IP地址已使用保留前缀保密的Crypto-Pan AES加密匿名的方法进行匿名化。
我们首先快速分析这些数据集中的流量，我们将流定义为一组数据包中共享的五元组信息：（源IP，目的IP，协议，源端口号，目的端口号），以及每两个连续数据包到达的间隔时间最多为90s。每个TCP流或UDP流将由两个单向流表示。表1显示了每个数据集中的流、包和字节数：
图2描绘了流持续时间和大小（以包和字节为单位）的分布（CDF），大学2数据集中的流量通常较大，包括数据包计数和字节数。这些数据集中大量单个数据包流的占比：大学1：63%，大学2：30%，ISP：48%：
表1还包括了所有数据集中TCP流量的占比，可以看到，在大学1和ISP数据集中，TCP流量的字节数约占90%，数据包数量约占80%，超过UDP流量的一半。但是，大学2的流量分布完全不同，几乎所有的流量都是UDP。基于源端口和目标端口的进一步调查显示，几乎所有的流量都属于AFS（安德鲁文件系统）。
大多数UDP流只有一个数据包：大学1中98.7%、ISP中85.2%的UDP流只有一个数据包，即有很多非常短的非TCP流。考虑到为单个数据包流安装流规则没有任何好处（因为不会有其他的数据包匹配），从单个流管理中可以排除这些流，以减少表占用和管理开销。考虑到第一个数据包到达时，我们不知道是否还有第二个数据包，因此，当第一个数据包到达时，不能只安装一个用于流量超过一个数据包的流规则。我们的解决方案是在安装规则之前等待，从每个流中接收k个分组（在接受前k个分组时，孵化该流）。这种“孵化将阻止单个数据包流规则的安装。代价就是使前几个非短流数据包丢失。
影响我们设计的第二个方面是，大多数流的持续时间都很短。例如，大学1追踪超过90%的流量的持续时间小于1s，因此，使用固定的空闲超时（例如5s）将时每个完成的流规则保持5s，这与短流的持续时间相比，是一个巨大的开销。
B.表占用率的分布
正如第III部分所述，表占用率的最大值不是作为目标函数使用的最佳度量，为了证明这一点，我们测量默认的OpenFlow方法的流表占用率（即当看到一个丢失数据包时就建立规则，当空闲超时后就驱逐规则）。在上述三个数据集中测试使用不同的超时时间。
这个超时时间在OpenFlow规范中以秒为单位被定义【29】。现在在floodflight中默认的空闲超时时间是5s【15】，在POX中是10s【32】，在Juniper OpenFlow设备中是11s【19】，另外在一些OpenFlow交换机中可能高达60s。
考虑到大多数流持续的时间小于1s（例如，大学1的数据中超过92%的流持续时间小于1s，大学2中76%，ISP中64%，在图2中有显示）。我们测试使用了范围广泛的空闲超时，从1ms到1min，对于每个空闲超时值，我们使用用于管理流的默认静态空闲超市方法，并在模拟期间每10ms记录表占用率，最后我们从这些记录中计算表占用率的分布。
为了比较不同空闲超时时间的分布，我们将表占用率标准化，定义为减去平均表占用率/标准差。图1显示了三个数据集标准化的CDF。我们可以看到，95th percentile小于μ+2σ，99th percentile小于μ+5σ，表占用率最大值甚至可以高于μ+40σ。
第一个额外的信息是，最大表占用率不能提供大多数时间所发生事情的正确描述，而只关心了最坏的情况。第二个额外的信息是，平均表占用率与95th percentile和99th percentile密切相关。因此，减少平均表占用率将直接减少95th percentile和99th percentile的占用率。
C.背包解决方案，及时驱逐，我们的解决方案
我们开始我们的评估时，分析那些节省是可能的（背包解决方案），哪个部分是只知道何时流结束就可到达的（及时驱逐），以及我们提出的方案在实际情况下能否实现这些节省。
正如我们在第Ⅳ节中讨论的，背包解决方案为到达时间选择一个阈值，并且到达时间小于该阈值的所有数据包都将会被命中。我们可以使用“空闲超时”这一术语来定义这个阈值。及时驱逐是OpenFlow静态空闲超时机制的默认策略，同时附加了一个策略就是一旦到达最后一个数据包就驱逐任何活跃的流表项。我们提出的方法还有两个参数：孵化规模和空闲超时时间。在本节中，我们将空闲超时时间定义为1ms到1min，并适用于所有的四种方法（OpenFlow默认的静态空闲超时机制，背包解决方案，及时驱逐，以及我们提出的延迟安装和加急驱逐）。我们还为我们提出的解决方案使用了三种不同的孵化阈值：1，2，3。孵化阈值1等于没有设限，即当流的第一个数据包到达时就建立流表规则。
图3，4，5显示了不同方法下的表占用率与OpenFlow默认方法的表占用的比较。我们首先分析平均表占用率（图3），可以看到背包解决方案的平均表占用率节省了很多（通常高于70%）。例如，当空闲超时时间为10s时，在大学1的数据集中节省了84%，大学2节省了79%，ISP节省了74%。
及时驱逐也显示了极大的表占用的节省，并且接近于背包解决方案，特别是当我们增加空闲超时时间时。原因是，当我们增加空闲超时时间时，命中率增加，没有命中的数据包减少。及时驱逐与背包解决方案的不同之处在于：因到达时间高于空闲超时时间，下一个分组何时会被丢失。背包解决方案立即将这些规则驱逐，及时驱逐直到超时了才驱逐这些规则。这种情况的任何一种因素减少，都会使及时驱逐与背包解决方案的结果更加接近。因此，如果我们可以正确地定义一个流的最后一个数据包，我们可以获得很明显的节省（例如当空闲超时时间为10s时，在大学1的数据集中占74%，在大学2中占50%，在ISP中占51%）。
我们推荐的方法使用加急驱逐和延迟安装（流表孵化）来减少流表占用率。如果我们将孵化阈值设为1，即相当于没有设置阈值，仅使用了加急驱逐策略。如果我们依赖于TCP的FIN/RST数据包，这种方案将不如及时驱逐策略（例如，对于大学2数据集中的大部分流量：非TCP流，将没有显示出对流表占用率的节省）。但是，在另外两种数据集中仍然有客观的节省（例如，当空闲超时时间为10s时，在大学1的数据集中节省了20%，在ISP中节省了16%）。流表孵化能够通过防止非常小的非TCP流浪费表空间来弥补快速驱逐技术。如果简单地将孵化阈值设置为2（当接受到两个数据包后建立规则）可以带来的节省（孵化阈值为2，同时采用加急驱逐）接近于及时驱逐策略。例如，当空闲超时时间为10s时，在大学1的数据集中节省了62%，大学2中节省16%，ISP中节省41%。我们通过实验可以看到，对孵化阈值的继续增加对表空间的节省不会再有明显的影响。例如，当空闲超时时间为10s时，将孵化阈值从2增加到3，在大学1中仅多节省了1%，大学2中9%，ISP中3%。
图4显示的99th percentile的表占用率与图3显示的平均表占用率几乎相同。这与我们的预测是一致的，99th percentile接近于平均表占用率。
但是，图5所示的最大表占用率的结果与前两者不同。尽管我们可以看到一个相似的趋势（在背包解决方案中有更多的节省），最大表占用率的节省与平均表占用率的节省的联系依赖于数据集。在大学1的数据集中，对于较小的超时时间（小于1s），对于数据表的节省更加明显，在大于1s的超时中，节省几乎相同。大学2的数据集有相反的情况，较小的超时时间下节省地更少，较大的超时时间下节省地更多。在ISP数据集中，大多数方法显示了相似的结果，除了在较小超时时间下，及时驱逐节省更多。
这些结果突出了数据集对最大表占用率的影响，这使得它对于流促进方法的评估不太理想（因为我们不能容易地将结果推广到其他网络或流量）。这也支持我们使用平均表占用率或99th percentile来代替最大表占用率作为优化目标函数。
现在我们已经展示了我们提出的方法对于降低表占用率的效果，接下来将专注于它的成本。加速驱逐和延迟安装将导致一些包被丢失，我们将错过TCP流中第一个FIN/RST包之后的数据包，将错过非TCP流的前n个数据包（n是孵化阈值）。图6显示了我们提出的方法中命中率的降低（或者未命中包的增加），可以看到，在大多数情况下，命中率降低了大约1%。总之，我们提出的方法只丢失了1%的数据包（这些数据包在默认的OpenFlow方法中可以命中），同时显著减少了流表占用率。
D.与heavy hitter detection的比较
在上一部分中，我们报告了各种方法在各种情况下可以提供多少的节省，在本部分中，我们将我们的方法与“重击球手检测”进行比较，正如我们在第2节所回顾的，“重击球手”又名“大象流”，通常根据其大小或素的来定义。因此，在我们的比较中，包括基于大小和基于速率的重探测器。
对于基于大小的重探测器检测，当流的分组计数超过“重击者阈值”时，我们将其标记为“重击者”。例如，在一个方法【34】中具有超过20个分组的流被称为是“大象流”，但是在另一个方法【28】中需要超过1000个分组，或者甚至需要更高数量的分组（占总分组的1%【37】，甚至是10%【9】）。考虑到这一点，我们使用更加广泛的范围来作为重击阈值，从5个分组到15000个分组。
对于基于速率的重击检测器通过计数流在每个间隔期间发送的分组（或字节）的数量来测量固定时间间隔的流速。在每个间隔的开始，它们推进在前一个间隔内超过阈值的流。在一个间隔内可选的测量流速是1s【17】、5s【6】【24】。我们使用了三个不同的时间间隔：1s、5s、10s。对于每一个时间间隔，我们在2-1024的分组范围内使用不同的阈值。
我们在数据集上运行每个方法，在运行过程中测量命中率和表占用率。对于表占用率，我们测量了平均、99th percentile和最大值。我们针对每个数据集绘制了每个方法（背包、及时驱逐、默认方法、我们提出的延迟安装和加急驱逐、基于大小的重探测器检测、基于速率的重探测器检测）的结果，对于每个方法，都有一个参数需要减少/增加。我们使用XY分布图表示每种方法重表占用率和命中率之间的关系。
图7显示了平均表占用率和命中率的结果。第一个观察是背包解决方案相对于其他所有方案的显著优点。例如，在ISP数据集中，对于平均表大小为100的第二最佳解决方案，背包解决方案比第二最佳解决方案匹配大约多20%的分组，对于平均表大小为1000的情况，背包解决方案比第二最佳解决方案多匹配大约10%的分组。
我们提出的方法比默认的OpenFlow方法节省了10%-20%，尽管在对数比例图中很难注意到。
第二个是基于尺寸的“重击球手检测”，这种方法与其他方法相比大多数情况下效果较差。在ISP和数据集和大学1的数据集中，总是最差的方法（相同的表占用率比较不同的命中率）。在大学2的数据集中，当表大小超过200时，性能最糟糕，但是优于一些基于速率的重击检测器。这种方法的性能差的原因是：正如我们在背包解决方案中看到的，每时每刻性能更好的关键是更快地为即将接收的下一个数据包建立流规则，这可以被描述为选择具有较高瞬时速率的流，简单地将尺寸变大并不能保证一个较高的速率，也就不能保证有更好的性能。
第三，基于速率的重击球手检测比默认的OpenFlow规则和我们的方案差很多。虽然这个结果让人经他，并且与先前在“重击球手检测“中的报告不一致，主要原因是我们还考虑了非常低的空闲超时。我们使用从1ms到1min的空闲超时。当前系统的空闲超时时间：floodfight 5s【15】、POX 10s【32】、Juniper OpenFlow至少11s【19】，甚至在一些典型的OpenFlow交换机中高达60s【8】，这样的空闲超时值通常会导致非常高的表占用率。例如，当空闲超时为10秒时，大学1中的平均表占用超过2900，大学2中超过1200，ISP中超过16000，这远远超出了当前流表的大小。
但是，这并不意味着“重击球手检测“是无用的，如果我们重新查看图7，我们将注意到，只有通过”重击球手检测“才能达到一些表占用的范围。例如，基于空闲超时时间的方法（默认的OpenFlow、及时驱逐以及我们提出的方法）不能将ISP中的平均表占用降低到200，不能将大学1中的平均表占用降低到20。另外，基于速率的”重击球手检测“与默认的OpenFlow以及我们提出的方法在ISP数据集中平均表占用为200-800时，效果几乎一致。
图8显示了不同方法的99th percentile表占用率。同样，类似于我们在前一节看到的，99th percentile表占用结果与平均表占用结果几乎相同，这肯定了我们的预期，即减少平均表占用（我们通过理论分析所做的）也将直接减少99th percentile表占用率。
如果我们考虑最大表占用率，结果将会不同。如图9所示，重击球方式在最大表占用与99th percentile表占用几乎相同，基于空闲超时时间机制的方法的性能急剧下降。例如，基于尺寸的“重击球手检测“方法的性能与默认的OpenFlow以及我们建议的方案在表占用为500-10000范围内是可比的，而基于速率的“重击球手检测“方法在这个范围内好多了。这种突然改变的原因是：“重击球手检测“对诸如SYN洪水攻击或P2P文件共享启动之类的有免疫力，正如我们在第III模块讨论过的。上述两种流都是一股突然的很短的流（通常仅有一个数据包），因此完全被”重击球手检测“忽略。同时，基于空闲超时的方法可能会尝试处理所有这些流，这会导致表占用率大幅上升。我们将在第VII节的讨论中回到这一点。
最后，我们再次强调明确界定目标和成本函数的重要性。到目前为止，我们只考虑命中率作为目标函数，而平均表占用率作为成本函数，并且基于此，我们显示了简单地使用小的空闲超时（例如，100ms）并且提供以下结果：明显优于当前的“重击球手检测“的方法。
然而，安装更多的规则并不一定是一个缺点。我们必须为流安装多个规则的原因是因为每个规则只匹配流的一小部分，即具有非常短的到达时间的连续分组，即flowlet【36】，它已被用于Plank【36】中的子流路由。换句话说，这些频繁的超时隐式地识别了每个流中的小流，并使控制器能够实现子流技术，如Plank【36】。我们将这些扩展留给未来的工作。
此外，如果我们对子流的管理不感兴趣，我们可以在本地控制器和规则缓存的帮助下解决这个问题。这些规则中的大多数实际上是规则的重新安装，因为原规则已被删除，现在如果同一流的另一个包已经到达，我们可以简单地缓存最近过期的规则，并在联系中央控制器之前对其进行搜索，那么这些被遗漏的表和规则中的大多数将在本地以非常低的开销处理。这可以通过使用本地控制器来解决（如Kandoo【16】）或规则缓存系统【21】来实现。
这激发了一种新的替代方法，可以替代重击者：不关注要为哪些流安装规则（即，安装长时间留在表中的规则），而是频繁地驱逐规则（例如，通过设置小的超时时间）以保持表占用小，同时提供一种机制来快速重新安装最近被驱逐的规则（即，Cache）。虽然最近在SDN中有关于规则缓存的工作【21】【38】，但是它们主要关注于规则依赖性。我们留待以后的工作来研究高级缓存和非常短的空闲超时是否是重击手检测的实用替代方案。
VII. 论述
A.为什么需要大的流表
与以往的”重击球手检测“解决方案所建议的不同，网络中活动流的数目大并不是我们需要大流表的原因。背包解决方案表明，流表中不必要的流规则停止（等待通过空闲超时机制被删除）是我们需要大流表的主要原因。
我们对背包方案的仿真结果表明，该方案还有很大的改进空间。然而，它需要直到分组到达的时间。幸运的是，较低版本的背包解决方案（即，及时驱逐）在较大的空闲超时时间下仍然可以提供显著的改进。
我们还提出了一种实用的加急驱逐的方法。使用TCP的FIN/RST包模拟及时驱逐记忆预测TCP流何时中止。但是，模拟结果显示，与及时驱逐相比，节省的效果大幅下降。主要有两个原因：第一：只对TCP流起作用，对网络中的大部分流——非TCP流没有效果（表1）；第二：即使对于TCP流，RST/FIN数据包也不能保证数据流的中止，一些TCP流缺乏任何RST/FIN分组，例如失败的TCP连接，在RST/FIN包之后仍有更多的数据包。这可以解释为什么有些研究人员认为以RST/FIN数据包判定流的中止不能有效【25】。
在本文中，我们引入了流孵化（延迟规则安装）的概念，它可以克服对非TCP流（例如，UDP流【25】）无效的缺点。尽管从RST/FIN分组预测TCP流终止的想法并不新颖，但我们的贡献在于将它与流孵化配对，并使之成为一个实用的解决方案。
我们可以通过应用针对短流的技术来改善孵化流的性能，例如通过不同的路由发送每个分组的多个副本【42】。我们计划之后再研究这种优化的效果。
B.非常小的空闲超时时间
这项工作的另一个重要贡献是展示了非常短的空闲超时的好处。正如我们前面所讨论的，当前OpenFlow规范使用秒粒度定义空闲超时，并且实际系统使用5秒或更多秒的值。在这里，我们演示了非常小的空闲超时（例如，200毫秒）也是有用的，并且甚至可以在相同表占用率的情况下比“重击球手检测”的命中率要高。
此外，当前范围的可能的超时很少使用（1-216）。例如，我们没有发现任何系统使用（或提议）使用超过60秒的空闲超时。因此，我们建议在OpenFlow规范中将空闲超时定义的粒度从秒更改为毫秒（这将使应用程序能够将空闲超时从1毫秒设置为65秒）。
我们还演示了更短的空闲超时将导致为每个流安装更多的规则。虽然在本地控制器（例如，Kandoo【16】）和规则缓存（例如，【21】）的帮助下这可以减轻，但是它肯定了明确定义成本函数的必要性。我们将它留给将来的工作来研究规则缓存在非常短的空闲超时下的好处和挑战。
C.我们何时需要使用“重击球手检测”
我们还分析了基于尺寸的和基于速率的“重击球手检测”的性能。令人惊讶的结果是，如果我们使用较小的空闲超时，大多数时候使用默认的OpenFlow静态空闲超时方法可以获得更好的结果。然而，这并不意味着之前讨论的结果是错误的。在这里，我们讨论造成这种情况的原因。首先，以前的“重击球手检测”解决方案仅考虑通常的多秒空闲超时（例如，10秒），这种大的空闲超时通常导致非常高的表占用率（图7、8和9中的右上数据点），比现在的“重击球手检测”方法高一两个数量级。虽然忽略非常短的空闲超时可能是由OpenFlow标准所激发的，该标准强制空闲超时为整数秒，但是另一个可能的原因是为了避免太多的规则安装或删除。然而，如果对于可以安装或删除的规则的数量也有严格的限制，则应该将其定义为成本函数的一部分。
其次，以前的方法只关注最大表占用率，正如之前所讨论的，“重击球手检测”方法的性能不会随着新流的到来而变化，因为大多数流没有被标记为“大象流”，并且将被忽略。另外，基于空闲超时时间的方法中，当我们比较最大表占用率（图9）和99th percentile（图8）可以发现，表占用率会突然增加。因此，以前的“重击球手检测”关注每个方法的最坏情况，而不是考虑在大多数时间该方法是如何执行的。这就是我们考虑平均表占用率的原因，平均表占用率同时也与99th percentile高度耦合，可以将其作为优化的目标函数。
第三，以前的方法可能关注于非常低的表占用率。如突图7、8、9所示，基于空闲超时时间的方法无法达到非常低的表占用率（例如，在ISP数据集中低于100）。这是因为只有很少的流量非常大。
我们还表明，基于尺寸的“重击球手检测”不是很有效，因为我们只知道流在过去是如何执行的，忽略流的执行时间，我们并不能很好地直到流在未来将如何执行。此外，在基于速率的“重击球手检测”中，明确地从“大象流”的定义中排除具有高速率的非常短的流是没有意义的，正如【3】所示。
VIII.结论
本篇文章中，我们重新审视了有限流表大小问题，它是SDN中所有流单独管理的主要障碍。我们明确地定义了我们的目标函数和成本函数，并且提出了用于流促进的最优的（即理论上可能的最佳）解决方案以实现它。然后，我们使用最佳解决方案作为灵感，提出了一个新的流促进，预测TCP流终止（加速驱逐）和孵化非TCP流（延迟安装）。
我们提供了仿真结果，将新提出的延迟安装和加速驱逐方法与默认的OpenFlow方法、最佳方法以及基于大小和基于速率的重击检测方法进行比较。结果表明，与默认的OpenFlow方法相比，我们的方法不仅提供了显著的节省，而且当我们使用小的空闲超时时，它还可以比“重击检测器”执行得更好。
要强调的是，我们的方法不一定总是比“重击检测方案”更好，因为最好的解决方案取决于底层系统的需求。例如，在某些情况下，我们提出的方法可能比“重击检测”执行得更差：如果流表非常小（例如，小于100个条目），对我们可以安装或驱逐的规则数量或者最坏的情况（即，最大表占用率）有严格的限制。
我们只考虑命中率作为成本函数（基于先前工作的假设，以最大化命中率），其他成本函数可以用来模拟其他应用程序。在第三节中，我们还提供了很少的其他潜在的成本函数，这可以在以后进行研究。