文章目录
首先还是得明白什么是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维来划分节点
这样的划分总共
c
d
m
c_d^m
cdm种，按照顺序记做
c
i
(
i
=
0
,
1
,
.
.
.
,
c
d
m
−
1
)
c_i(i=0,1,...,c_d^m-1)
ci(i=0,1,...,cdm−1) ，每次划分产生
2
m
2^m
2m个子节点，记做
S
k
c
i
S_{k}^{c_{i}}
Skci
如何确定
c
i
c_i
ci?尝试在
c
i
c_i
ci上分割，考察它分割出来的
2
m
2^m
2m个子节点size的sum and the deviation
维度选择的cost function是：
cost
c
i
(
S
)
=
∑
k
=
0
2
m
−
1
A
(
S
k
c
i
)
+
δ
∑
k
=
0
2
m
−
1
(
A
(
S
k
c
i
)
−
∑
k
=
0
2
m
−
1
A
(
S
k
c
i
)
/
2
m
)
\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
(
S
k
c
i
)
A\left(S_{k}^{c_{i}}\right)
A(Skci)代表关联规则的数目或the size of hyper-rectangle
S
k
c
i
S_{k}^{c_{i}}
Skci
δ
\delta
δ是调整sum与deviation权值的正值
具体来看一下公式
前一项代表分割出来的
2
m
2^m
2m个子节点中一共有多少条规则（肯定大于规则集R的大小）
∑
k
=
0
2
m
−
1
A
(
S
k
c
i
)
/
2
m
\sum_{k=0}^{2^{m}-1} A\left(S_{k}^{c_{i}}\right) / 2^{m}
∑k=02m−1A(Skci)/2m 每个子节点关联规则个数除以子节点总数 之和
A
(
S
k
c
i
)
−
∑
k
=
0
2
m
−
1
A
(
S
k
c
i
)
/
2
m
A\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
=
0
2
m
−
1
(
A
(
S
k
c
i
)
−
∑
k
=
0
2
m
−
1
A
(
S
k
c
i
)
/
2
m
)
\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
B
c
\mathbf{B_c}
Bc, cached rules
R
c
\mathbf{R_c}
Rc ，matched rules
R
m
\mathbf{R_m}
Rm
如何修改buckets——M&S
merge
merge执行在孩子节点都是叶节点的节点上。合并后所有的孩子变成一个bucket，通过树的后续遍历来实现。
split
原来的节点成为中间节点，产生多个小一点的孩子作为buckets,通过树的前序遍历来实现。
增益
在M&S前后需要安装的表项之差，M&S后安装的表项减少则增益为正，只要增益为正就执行。
何时终止操作：
贪心会导致局部最优，当增益为负值的时候，以一定概率merge或split
Prob
M
(
h
i
)
=
{
1
,
G
(
h
i
)
≥
0
exp
(
ρ
M
G
(
h
i
)
)
,
G
(
h
i
)
<
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
- N u = ∣ R c − R m ∣ 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 :它那个训练算法我不是很明白。它没有说
2
m
2^m
2m个子节点是怎么生成的。
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
扫一扫
834
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
