文章目录

交换机实现
bucket generation
- bucket generation problem
- bucket generation algorithm
PERFORMANCE EVALUATION
- Simulation Setup
- Simulation results
- 调参
conclusion
CAB后续ACME 11/18更新
什么是ACME
improvements
- initial bucket generation
- large rule preloading
- bucket adjustment
- - why
  - 如何检测traffic pattern变化
  - 如何修改buckets——M&S
  - - merge
    - split
    - 增益
- Bucket Adjustment Trigger
实验细节
原型评估
discussion
数据概念
术语
- IPC
- Traffic steering
- PolicyBench
- Pyretic
- source && sink
边看边疑惑，后面解释清楚了的内容
没弄明白的
思考

首先还是得明白什么是wildcard rule叭

一个123.132.8.0/22的wildcard rule就要缓存1024个microflow rules
网络地址占22位，主机地址占10位
。。。没找到比较好的解释
参考文献
M. Yu, J. Rexford, M. J. Freedman, and J. Wang.Scalable flow-based networking with difane. ACM
SIGCOMM Computer Communication Review,41(4):351–362, 2011.

在处理wildcard rules的时候，把R3分割开来(F[1]=[6,7], F[2]=[0,15])这个是不具备依赖性的，可以直接加进去
那像R2和R3交叠的地方就建两次，有两个不同的优先级
我应该直接看这一部分的，SIGCOMM看起来真是令人头禿。

N. McKeown, T. Anderson, H. Balakrishnan,G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and
J. Turner. Openflow: enabling innovation in campus networks. ACM SIGCOMM Computer Communication Review, 38(2):69–74, 2008.

Each header field can be a wildcard to allow for aggregation of flows, such as flows in which only the VLAN ID is defined would apply to all traffic on a particular VLAN.

1、bucket 相当于锁定了一个局部范围，超过这个局部范围的依赖规则我就不管啦，我的流压根不可能去匹配那些规则，我何必加载呢~
2、而且有利于临近的流，过来就不用setup了

交换机实现

两级表：bucket filter 和 flow table
关于bucket
1、所有的bucket优先级相同，action都是把包传给流表，去匹配规则它相当于起了个请求install 流的作用，如果bucket已在，那么规则已安装，bucket不在，规则还没安装
2、是安装和破坏流表条目的最小单位。删除一条entry的时候，必须把所有和它相关的bucket在bucket表里删掉=>给bucket和所有它的关联规则分配相同的timeout value。规则的timeout更新至最新进入一级表的bucket的timeout

question：那我如果再来一次f2，二级表是不变的
二级表的这个时间究竟有什么意义呢？
从删条目转过来删bucket ，流表放不下了，想replace掉rule 3，它和bucket C的时间戳一样，那怎么定位到bucket F？
如果一开始就有映射，那么时间戳的意义是什么？
F t1
C t3
I t4
2 t3 3 t3 4 t4
假设f4 在bucket I里，那么rule 4 为 t4
时间戳的意义在于我要删rule 3 -> 删掉C/F
-> 删掉C的时候查表发现rule 2 和它一起，就把rule 2也删了
-> 删掉F的时候查表发现rule 4是属于I的，我就不删了

不和bucket绑定的rule是无意义的，包又看不到你，你还空占位置，说不定就把别的rule挤走了，然后那个rule还把自己bucket给连带删掉

bucket generation

bucket generation problem

怎么划分？按照d-dimension field space将rules划分开，形成若干个bucket

要求：最低的cache miss rate
考虑的要素：bucket size N
bucket size：关联规则的个数
bucket size过大的坏处（最大就是cover所有规则）：用不到的rules加载很浪费流表，每次都要加载所有的rules，可能造成overflow
bucket size过小的坏处：无法利用traffic locality；向controller请求次数过多；bucket filter里会存很多的bucket
N取决于规则的分布以及traffic pattern，利用历史数据调参，默认认为traffic pattern短时间不变？？？
所以后续还要对变化更快的动态调整

bucket generation algorithm

决策树

要处理的任务：给定规则集R，将

为了能在TCAM中实现，采用二分或multi-binary
size不大于预设的N就停止迭代，叶子节点就是bucket
每次从d维中选出m维来划分节点
这样的划分总共cdmc_d^mcdm种，按照顺序记做ci(i=0,1,...,cdm−1)c_i(i=0,1,...,c_d^m-1)ci(i=0,1,...,cdm−1) ，每次划分产生2m2^m2m个子节点，记做SkciS_{k}^{c_{i}}Skci
如何确定cic_ici?尝试在cic_ici上分割，考察它分割出来的2m2^m2m个子节点size的sum and the deviation
维度选择的cost function是：
cost⁡ci(S)=∑k=02m−1A(Skci)+δ∑k=02m−1(A(Skci)−∑k=02m−1A(Skci)/2m)\operatorname{cost}_{c_{i}}(S)=\sum_{k=0}^{2^{m}-1} A\left(S_{k}^{c_{i}}\right)+\delta \sum_{k=0}^{2^{m}-1}\left(A\left(S_{k}^{c_{i}}\right)-\sum_{k=0}^{2^{m}-1} A\left(S_{k}^{c_{i}}\right) / 2^{m}\right)costci(S)=∑k=02m−1A(Skci)+δ∑k=02m−1(A(Skci)−∑k=02m−1A(Skci)/2m)

A(Skci)A\left(S_{k}^{c_{i}}\right)A(Skci)代表关联规则的数目或the size of hyper-rectangleSkciS_{k}^{c_{i}}Skci
δ\deltaδ是调整sum与deviation权值的正值
具体来看一下公式
前一项代表分割出来的2m2^m2m个子节点中一共有多少条规则（肯定大于规则集R的大小）
∑k=02m−1A(Skci)/2m\sum_{k=0}^{2^{m}-1} A\left(S_{k}^{c_{i}}\right) / 2^{m}∑k=02m−1A(Skci)/2m 每个子节点关联规则个数除以子节点总数之和
A(Skci)−∑k=02m−1A(Skci)/2mA\left(S_{k}^{c_{i}}\right)-\sum_{k=0}^{2^{m}-1} A\left(S_{k}^{c_{i}}\right) / 2^{m}A(Skci)−∑k=02m−1A(Skci)/2m 代表每个子节点的deviation
那么δ∑k=02m−1(A(Skci)−∑k=02m−1A(Skci)/2m)\delta \sum_{k=0}^{2^{m}-1}\left(A\left(S_{k}^{c_{i}}\right)-\sum_{k=0}^{2^{m}-1} A\left(S_{k}^{c_{i}}\right) / 2^{m}\right)δ∑k=02m−1(A(Skci)−∑k=02m−1A(Skci)/2m)是权值调整后的偏差之和

这个cost function真的歹啾不？ 嗯嗯
减少节点的和？可以减少不同buckets与相同规则关联造成的冗余
平衡各节点的大小能避免树过深
它是如何和cache miss rate联系起来的？想想以Source IP为例，从哪切鸭应该就是在这里训练出来的

PERFORMANCE EVALUATION

Simulation Setup

合成规则，已有trace不能直接用，不然会造成大量的miss

header mapping technique
将真实的traces映射到合成的规则上，保留流的包大小、inter-arrival rate、流持续的时间等信息。Trace pruning and interpolation are designed for tuning traffic load.
这里没有想明白。

交换机服务器 TCAM 1500条 288bits RTT=2ms forwarding =5ns rule installation 排队未考虑
CEM 精准匹配
CMR 无依赖的micro-rules
CDR 有连带关系的都install

Simulation results

Resource Consumption
测试时间长达20min
CAB可以支持15000flows/sec

Flow setup time
1000 flows/sec的速率到达下每个交换机上流的平均setup time，流数一大，交换机一多，差距就上来了

CMR也很好因为localized traffic
CDR要存的多
CEM就最差了平均建立时间接近RTT

调参

bucket size太小
bucket size过大的坏处（最大就是cover所有规则）：用不到的rules加载很浪费流表，每次都要加载所有的rules，可能造成overflow
bucket size过小的坏处：micro-rules既视感。。无法利用traffic locality；向controller请求次数过多；bucket filter里会存很多的bucket
基于上述原因要有个平衡，进行调参，最终判断9-16为佳

conclusion

仍需继续改进
traffic pattern changes more frequently and buckets are
generated and tuned dynamically

CAB后续ACME 11/18更新

从MNP做的标注导入Adobe Acrobat全错位了，重新导出好了，但是我在电脑上做的标注又要丢失了。得同时看两个，感觉真难受。

什么是ACME

Adaptive Cache ManagEment (ACME)
根据来的流量动态调整buckets的形状和大小，以达到最小占用流表的目的。

improvements

预加载范围很大的规则，比如default rule，把它剔除和bucket的绑定，不然每个bucket install的时候都要install它，减少控制通道带宽使用

initial bucket generation

large rule preloading

计算每个规则的关联bucket数，将最大的K个预加载入流表
define a rule to be ‘larger’ when it is associated with a larger number of buckets.
By sorting the rules by the number of associated buckets, the top K rules are identified as large rules to be preloaded.

bucket adjustment

why

a图要存4buckets+10rules，b图要存3buckets+9rules
两个点：

减少需要cache的buckets数目
减少cached但未命中的rules
节省空间

如何检测traffic pattern变化

维护三元组P(B,t)P(\mathbf{B}, t)P(B,t)
包括cached buckets Bc\mathbf{B_c}Bc, cached rules Rc\mathbf{R_c}Rc ，matched rules Rm\mathbf{R_m}Rm

如何修改buckets——M&S

merge

merge执行在孩子节点都是叶节点的节点上。合并后所有的孩子变成一个bucket，通过树的后续遍历来实现。

split

原来的节点成为中间节点，产生多个小一点的孩子作为buckets,通过树的前序遍历来实现。

增益

在M&S前后需要安装的表项之差，M&S后安装的表项减少则增益为正，只要增益为正就执行。
何时终止操作：
贪心会导致局部最优，当增益为负值的时候，以一定概率merge或split
Prob⁡M(hi)={1,G(hi)≥0exp⁡(ρMG(hi)),G(hi)<0\operatorname{Prob}_{M}\left(h_{i}\right)=\left\{\begin{array}{ll}{1,} & {G\left(h_{i}\right) \geq 0} \\ {\exp \left(\rho_{M} G\left(h_{i}\right)\right),} & {G\left(h_{i}\right)<0}\end{array}\right.ProbM(hi)={1,exp(ρMG(hi)),G(hi)≥0G(hi)<0
ρM\rho MρM is a positive value for tuning the greediness of the
algorithm. A larger ρM\rho MρMindicates greedier operations, which
tend to generate suboptimal results, while a smaller ρM\rho MρM leads
to more trials and better results.
选择指数函数的原因：凸函数，能很好地“惩罚”负数；实行简单

Bucket Adjustment Trigger

Nu=∣Rc−Rm∣N_{u}=\left|R_{c}-R_{m}\right|Nu=∣Rc−Rm∣ 是缓存了但是未命中的数量，如果它在增多，冗余的规则数太多了，我们应该减小bucket的size了，不要包含那些冗余的
平均每条规则关联的buckets数增加，我们可以把一些buckets给合并了，节省buckets占用的空间
当增幅比上次调整后的最小值？大的超过一个阈值的时候，就发起调整
tight threshold会导致aggressive adjustments and fewer entries to be cached，增加计算复杂度，以及CAB 控制器更新复杂度

为了防止突发的流量，集合差值会计算连续采样周期来决定pattern是否收敛了

实验细节

policyBench是一种基于classBench的新的SDN规则生成器（生成规则和traffic）
8k个wildcard rules，在流表中只能承载4k个wildcard rules以及32k exact-match rules
增量阈值是20%
在bucket adjustment时， trial number设置为5。
保留了22.5%的flow table进行pre-load

CAB-ACME Achieves a Low Miss Rate and Control Channel Bandwidth Consumption:

each piece of trace is 1-hour ; flow arrival rate vary from 500-9500 flows/sec
miss rate减少一个数量级，控制通道带宽减少一半，稳定支持9.5k flows/sec。
CEM耗最多的带宽，CMR稍微好一点
ACME Helps Maintain Minimal Flow Table Usage Under Traffic Dynamics

调整算法触发阈值是20%。bucket条目数大概稳定在总是的1/4
比baseline CAB剩下了一半的空间
在2500s时突发流量导致buckets被过度分割，ACME能够平滑这个
大概133s会进行一次调整，认为controller调整bucket大小是不频繁的
Bucket Adjustment Costs Controllable Computational Complexity

考察了bucket调整算法复杂度与规则集大小和没有gain的最大尝试次数之间的关系
the maximum trials without gain before terminating the M&S algorithm.
即使规则集高达20k，调整可以在10s内完成，是完全满足不频繁的触发事件的
the bucket tree converges as we take more than five trials，避免不必要的计算，将最大尝试次数设为5

Preloading Large Rules Saves Control Channel Bandwidth

流速8k flow/s，持续30min。
大于22.5%的时候出现了overflow，将pre-load百分比定为了22.5%
CAB-ACME’s Performance With Non-Localized Workloads

As a caching system, the performance of CAB-ACME can be workload-dependent？？？不是说在non-locality下效果没那么好
However, for pure
random traffic, CAB-ACME can have less gain or even get slightly inferior to CMR.在随机的情况下，ACME将bucket调整至只含有一条规则，因此，最坏情况下流表是CMR流表大小的2倍。
考虑一种将CMR和CAB-ACME结合的方式：
当一个新流请求来的时候，只有micro rule被cache。当流被识别为具有局部性且变化缓慢的时候，controller剔除micro rule，将规则和bucket一起存起来。

原型评估

与OpenFlow switch兼容，用OpenDayLight控制Pica8 P3297交换机和Hewlett Packard HP2920交换机，使用OpenFLow协议1.3版本，set up two hosts as the traffic generator and the sink，所有的traffic都经过硬件交换机。还实现了CMR和CEM来做比较。
2k wildcard rules with 2-tuple and 4-tuple matching fields are composed.

Profiling Control Channel Throughput

测试了control channel throughput
Data Plane Throughput Stress Test
Traces with different new flow arrival rates are injected into the prototype. Each test lasts 30 minutes. We record the average flow setup request rates (or Packet-In message rates) collected at the OpenFlow controller. The results are shown in Fig. 15.

Note that the throughput here is defined as the new flow arrival rates;
请求的规则没有立刻装载在硬件原型里，无连接traffic时会生成多个setup queries for a single flow。这个延迟给CMR带来很大的麻烦，因为在规则集中找到请求的规则很耗时
System Stability Evaluation

Use-Case Implementation
首先验证包转发的语义准确性。generator host产生包发送至sink host。每个包都被打上了匹配的规则的标签。在sink host，验证程序将tagged rule identifier和包应该匹配的规则对比。结果证明了转发按正确性。
接着测试Firewalls和IPCs下的RTT。sink host响应所有generator发过来的流。
most packets matches rules in the switch and are forwarded at line rate for both firewall
and IPCs.

IPCs for software-based systems have fewer wildcard rules than firewalls. Therefore IPCs suffer from more cache misses.

discussion

Reduce Controller loads
need to store one copy of the shared part, and store the switch-specific subtrees separately.
为了减少计算复杂度，只调整最影响流表的子树。系统的performance由经常matched rules来主导，因此跟踪hot entries,可以极大降低计算负荷
Enable Multilevel Caching
分层管理，例如Infinite CacheFLow using multiple hardware and software switches

数据概念

TCAM一般就几百条entries
（只是从14年的这篇论文里得到的结论，现在应该更多了）

术语

IPC

contains a mixture of security, VPN and NAT poicies for software-based systems

Traffic steering

Traffic steering is a capability that sorts network traffic based on defined match conditions and steers as directed by the chosen traffic steering behavior.

PolicyBench

PolicyBench is a novel SDN rule generator motivated by ClassBench, a rule set and traffic
generator for benchmarking packet classifications [40], [47].

Pyretic

Pyretic是高级语言，它的目标是隐藏SDN编程的复杂性和减少出错概率。这个语言的研发在Frenetic Project的整体框架中进行。Pyretic基于Python，可以操作POX控制器。

source && sink

Source 发送端, 流的起点, 可直观理解为生产者, 负责读取文件或网络流的信息.
Sink 接收端, 流的终点, 可理解为是消费者, 直译为水槽 .

边看边疑惑，后面解释清楚了的内容

重新分割的时间成本：
Bucket Adjustment Costs Controllable Computational Complexity:

到底如何选多少个preload rule

所以到底迭代几次终止？

没弄明白的

Trace pruning

header mapping technique
将真实的traces映射到合成的规则上，保留流的包大小、inter-arrival rate、流持续的时间等信息。Trace pruning and interpolation are designed for tuning traffic load.
Q :它那个训练算法我不是很明白。它没有说2m2^m2m个子节点是怎么生成的。
A:均分切出来的。
While
some research raises concerns regarding the stability of traditional flow-based caching [27], we will address
these issues through engineered wildcard rule caching mechanisms.
Such pipelined processing actually already exists in traditional switches for different packet-processing tasks including VLAN/MPLS encapsulation, L2/L3 forwarding, and access control [42].
the increment of Nu or Nb exceeds a threshold compared to the minimum value since the last adjustment.
when flows matching a certain bucket are identified to have locality and change slowly, the controller evicts the micro-rules and caches the rules along with their bucket instead.流被识别为具有局部性且变化缓慢怎么识别流的traffic locality
policyBench究竟是什么呢？

思考

只要增益为正就没问题吗？好像是的

bound N还是未做吗？

ACME Helps Maintain Minimal Flow Table Usage Under Traffic Dynamics:
maintains a minimized table usage
真的是最小的了吗？
不能再小了吗

combining both CAB-ACME and CMR. 如何来判定流是否traffic locality

[论文笔记]CAB:CAching in Buckets CAB-ACME相关推荐

论文笔记 -- Communication Lower Bound in Convolution Accelerators 卷积加速器中的通信下界
论文笔记 – Communication Lower Bound in Convolution Accelerators 卷积加速器中的通信下界 @(论文笔记) 文章目录论文笔记 -- Commun ...
论文笔记 | 【CVPR-2023】Activating More Pixels in Image Super-Resolution Transformer
论文笔记 | [CVPR-2023]Activating More Pixels in Image Super-Resolution Transformer 抛砖引玉了,如有不同意见欢迎讨论. 目录 ...
论文笔记（十七）：Brax - A Differentiable Physics Engine for Large Scale Rigid Body Simulation
Brax - A Differentiable Physics Engine for Large Scale Rigid Body Simulation 文章概括摘要 1 捐款摘要 2 动机 3 使 ...
论文笔记（十七）：Brax — A Differentiable Physics Engine for Large Scale Rigid Body Simulation
Brax - A Differentiable Physics Engine for Large Scale Rigid Body Simulation 文章概括摘要 1 捐款摘要 2 动机 3 使 ...
论文笔记-infocomm2021-Maximizing the Benefit of RDMA at End Hosts
论文笔记-最大化RDMA在终端主机上的优势论文: Maximizing the Benefit of RDMA at End Hosts: 作者:NJU–王晓亮 (博导)-[IPADS] : 王晓亮 ...
「ArXiv2020」【Efficient Transformers: A Survey】论文笔记（更新中）
「ArXiv2020」[Efficient Transformers: A Survey]论文笔记 Abstract 1. Introduction 2. Background on Transfor ...
ORB-SLAM3 论文笔记
ORB-SLAM3 论文笔记这篇博客 ORB-SLAM3系统相机模型的抽象(Camera Model) 重定位的问题图片矫正的问题视觉惯性SLAM的工作原理相关公式 IMU初始化跟踪和建图 ...
【论文笔记】 LSTM-BASED DEEP LEARNING MODELS FOR NONFACTOID ANSWER SELECTION
一.简介这篇论文由IBM Watson发表在2016 ICLR,目前引用量92.这篇论文的研究主题是answer selection,作者在这篇论文基础上[Applying Deep Learnin ...
最新图神经网络论文笔记汇总（附pdf下载）
点击上方,选择星标或置顶,不定期资源大放送! 阅读大概需要15分钟 Follow小博主,每天更新前沿干货 [导读]近年来,图神经网络变得非常火热,每年顶会在该领域内都会出现大量的研究论文,本文为大家提 ...

[论文笔记]CAB:CAching in Buckets CAB-ACME