使用ACK包来携带路径和拥塞情况
以往的做法在主机上处理ACK包，受限于已有流的数量。ACK包实际上会穿过大部分的链路，如果有交换机的支持，到同一目的地的不同流可以共享信息，能更有效地发现路径。
CAVER可以在交换机上共享多个流的信息，这一交流允许我们探测包实际没有经过的路径的拥塞程度通过将每跳之间的信息进行组合拼接
三张表：
用CE用32-bit Discounting Rate Estimator即DRE计算
DRE是累加端口发出数据大小，定时乘以小于1的系数来衰减
$$CE = \frac{DRE}{C} \times 255$$
C是链路带宽，最终会得到带宽利用率
Path: 32位，记录出向端口，每个8位，三层胖树足够。
CE:8位
Time: 32位，最后更新时间
一个ACK包携带当前经过的路径和CE，ACK是ECMP的，所以路径选择多，用Give-and-Take策略与交换机交换拥塞信息，交换机与本地信息比较来维护BestTable和GoodTable
存储的时候Acceptable Path也只存一条
ACK包进来，看携带的路径，如果是不可接受的，先用best path换掉，再和good table交换。如果是可接受的，不用best path替换，而是直接和good table的path交换。这样ack中信息的交换更频繁，并且用best path进行替换的过程也保证了不会传播垃圾信息。
255减去CE(代表占用率)，乘上一个系数，大于这个值的认为可以接受
选路时，不能像HULA那样只考虑一个流最优，需要多条可接受路径。
信息的来源是ToR，集合了最好路径和可接受路径。
维护四张表：
K个可接受路径发送方：带上CE然后ECMP
接收方：看看BestTable要不要更新，如果Good Path可接受，就加到PathTable
首先检查是不是老流。这里用了FlowId作为索引的位数组，对应1/0标识
由于PathTable基于目标路由存储，所以就算哈希冲突，不过是走了旧路，不会发错。
为了缓解哈希碰撞，位数组有老化机制
新流的话，选路结果会写入包头
路径选择原则：
选路时，每张PathTable（对应一个目标），用top和counter来实现循环存储。选路时会检查添加时间有没有比阈值旧，太老的话会ECMP
DCQCN（数据中心量化拥塞通知） 是运行在服务器网卡之间的端到端传输层拥塞控制算法，它通过ECN标记和CNP通知包让发送端“快降慢升”地调节速率，从源头消除拥塞。
PFC（优先级流量控制） 是运行在相邻交换机之间的逐跳链路层反压机制，它通过PAUSE帧直接暂停上游设备发送，用“急刹车”的方式防止缓冲区溢出丢包。
需要专用硬件
方法：包头加路径和CE拥塞标签，Spine队列深度超过阈值，将CE更新,下游Leaf收到，用ACK向原发送端，原发送端存入表中记录该路径拥塞情况。原Leaf要记录通往一个目的地的多个路径的拥塞情况
每一跳记录通往目标的最佳下一跳
正向探测包发过去，每一跳检查本地队列深度，更新拥塞率，反向回来的时候更新路径上的每一跳
适用于RDMA
路径是由ECMP生成的，因为是二层Spine-Leaf，路径少。
注：CAVER设定考虑三层Fat-Tree
RTT_REQUEST，在超时时间里没有拿到RTT_REPLY将这条路放进黑名单。目标ToR收到ECN则通知上游，上游也将其设为不可用此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。