NSDI’16 FlowRadar: A Better NetFlow for Data Centers-阅读笔记
还是按照老一套：Background & motivation, Difficulty, Design & Implementation, Future work, Related work…
Pre-intro
NetFlow是什么。以下为一个NetFlow系统整体的示意图：
支持NetFlow的交换机/路由器，会将流经它的数据包根据源/目的IP、端口、协议等聚合为流（flow），并记录下数据包计数、起止时间等属性，当一个流超时结束后，该设备会将流记录上报到远程的NetFlow收集器，用于进一步的存储、分析。
Background
NetFlow是广泛使用的监控工具，其在哈希表中维持着一组流，支持流插入、冲突解决和流移除，这在现在的数据中心交换机上的商用芯片上是很难实现的1，因其每包处理时间有限。因此许多NetFlow的实现和监控方案必须使用采样或选取一部分包进行监控。然而数据中心有在小时间尺度上监控所有流而不采样的需求，如检测顺势循环（transient loops），黑洞（blackholes）和交换故障（switch faults），这些问题仅在少数流上可以检测出来，此外还有细粒度的流量分析，如异常检测（anomaly detection）也需要监控所有流，论文第三章对这些需求有所介绍。
对于如何在硬件上实现NetFlow的重点在于——如何使用更小的时间和空间复杂度的数据结构维护一组活动流（how to maintain an active working set of flows using a data structure with low time and space complexity.）。解决流插入产生的哈希碰撞，并移除旧的流以给新的流腾出空间。由于现有数据中心交换机上的商用芯片每包处理时间有限，实现这些是很困难的。
Related work
为解决这个问题,现有的实现主要分两种：
- 使用复杂的定制化芯片。仅适用于高端设备，对于数据中心过于昂贵；
- 使用软件2去对硬件采样得到的数据包进行计数。这会消耗过多的交换机CPU资源；
由于数据中心缺乏可用的NetFlow，人们只能对数据包进行采样或根据一定规则拿到部分镜像数据包，在远程的收集器上进行分析。对所有的数据包进行镜像是不可能的，这将耗费远程收集器大量计算和存储资源，文章中第二章有所介绍。
本文来源：https://blog.csdn.net/tunmang5421/article/details/121940154
Design
论文中提出FlowRadar，使用低内存开销存储所有流的计数器，并可以在短时间尺度（如10ms）将流计数上报。
FlowRadar的关键在于：在商用交换机有限的每包处理时间和远程收集器大量的计算资源之间找到最佳分工。
论文提出了“编码流集”（encoded flowsets），每包只需固定时间的指令，因此在商用交换机上实现较为容易。之后对这些流量集进行解码，并在远程采集器上进行跨时间和跨交换机的全网分析。——这也是论文的两个主要的贡献。
编码流集：是一数组的“cells”，将流的5元组和其对应的计数器编码。保证了每包处理时间是固定的。编码流集选择“拥抱”而非解决哈希冲突，它将一个流映射到多个cells，允许一个cell中发生流冲突，但保证了每个cell都具有保持不变的内存使用。编码流集是很小的，因此可以在小时间尺度上周期性 将所有流集上报给远程收集器。编码流集的数据结构是可逆式布隆查找表的拓展，对计数器更新提供更好的支持。
在远程收集器上的全网解码与分析：大部分流会经过多个交换机，而每个交换机是独立编码流和其计数器的。利用交换机的冗余，我们使得编码流集更加紧凑。论文提出全网范围的解码模式，对跨交换机的流和计数器进行解码。这种解码模式与NetFlow的理想实现模式（完美哈希，即无哈希碰撞）相比，将跟踪10万条流所需的内存减少了5.6%，同时提供了99%的解码成功率。
Evaluation
除去对FlowRadar本身的评估，论文还提了两种分析证明FlowRadar的有效性。详见论文第5、6章。
最后自己的感觉
如论文题目所说的，它实现的是一个“更优的NetFlow”，但和原本的NetFlow还兼容吗？——很不一样了
论文主要关注的是交换机上的流存储问题，collector部分只是做了一个全网解码的工作。
2493
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
