进度表

组会记录

2020年2月14日

建站记录进度。
将SketchLearn、flow radar、ElasticSketch的算法实现，使用CAIDA数据集测试。
同时测量以上算法IO数据。

2020年2月21日

可能的查询任务从两方面考虑：

一段长时间内的heavy hitter检测。
多个交换机（甚至跨地域）的数据协同查询。

目前主要考虑1。也可关注相关论文内的有关问题。关于数据平面的测试：

减少生成时间间隔，测试硬件下能够存储的最大存储带宽。
考虑进行K-V存储时时的键值。

实验时，可以考虑l=64，即flowkey只包含源和目的IP的问题。

2020年2月28日

下一步考虑使用树状结构存储小时间间隔下的Sketch，用以支持不同时间间隔的查询。

阅读 SwitchPointer (NSDI 2016)，查看现有树结构是如何实现的。
考虑是否可用上层（大时间间隔）的结果加速下层的推理。（可以尝试测试上下层间的相关性。）

2020年3月6日

继续之前的任务：

继续阅读近年的Sketch论文，可以进行适当的实验，明确需要达到的目标。
考虑树的结构。

2020年3月13日

尝试实现朴素方案，进行实验找出需要改进问题。
分析CAIDA数据集中的流分布情况。
继续考虑树状存储结构。

2020年3月20日

朴素方案数据平面暂时采用FlowRadar实现。实现完成后测量数据。

2020年3月27日

测量FlowRadar数据平面的带宽等数据。
考虑并整理存储系统部分的需求。

2020年4月10日

尝试时间联合解码。
查看SketchVisor、SketchLearn、OpenSketch中的Analyzer部分，看看目前的网络测量的需求。
第二天向做K-V的师兄学习RocksDB的使用方法，讨论组织形式。

20204月11日

最简单的方法：用时间戳作为Key，将每个时间戳的所有流列表信息存入RocksDB。
在内存中维护一个Hash表，作为索引记录每个流出现的时间。
即可实现两种查询。

2020年4月17日

继续实现最基本的存储方法。
考虑为什么要这么做，这么做的开销。
特别是Hash表的（内存）开销有多大。
数据一致性、可靠性的问题。

2020年4月24日

关于测量：

design的overhead：hash表的内存开销，CPU开销
系统性能测试：两种查询：吞吐延迟（workload构造：数据生成的速度，目标：系统最好边界：多大带宽的网络流的测量数据存储多大时间尺度）
还有数据插入的性能（吞吐和延迟）
对比baseline：把存储格式抽象出来：流格式，数据库mysql？rocksdb？大文件Ext？
baseline：上界对比，即和完全在内存中的情况进行对比
一些应用case的测试，黄群老师Paper中的一些应用的测量

2020年10月16日

重新启动。

多维度的聚合任务。
先生成一些简单的benchmark，将二维表建立起来，然后简单生成一些带聚合的查询。如查询dst ip和src ip相同，但port任意的所有流的流量。

进度记录

2月16日：建立本站。
2月18日：阅读SketchLearn。
2月19日：成功运行SketchLearn开源代码。
2月27日：初步完成SketchLearn代码修改，进行I/O测试。
3月 8日：阅读FlowRadar。
3月 9日：阅读ElasticSketch。
3月11日：阅读UnivMon、SketchVisor。
3月12日：设计朴素的存储系统方案。
4月 7日：完成了对FLowRadar的一系列测量。
4月23日：完成了使用时间戳作为Key + Hash表存储流出现时间信息的简单存储系统。