IncastBridge: A Middleware to Enhance Congestion Control Performance in Incast Scenarios 论文复盘
23 年啥也没干，24 年初也没啥方向，被学弟喊醒才开始瞄准一些已有工作，主要瞄准的是 Bolt。从第一步实验复现就开始出问题，只用仓库代码实际上是跑不起来的，因为有各种 bug。那时候没有 GPT 只能手动改 bug，但还是改好了（改好后的版本）。
当时就想如果只在 ToR 上运行 Bolt 是否会有收益，但至于怎么想到这点的我已经忘了，现在想想感觉可能是看了某些 incast 方面的东西，然后跟着瞎搞但最后搞出来了。测了之后发现确实有收益，但是单这么写也形成不了论文，所以就想换条路。那个时候一直看皮鞋哥的知乎，（或者说现在也）一直在说不要再发明新的拥塞控制算法了，深感认同，但不发明新拥塞控制又毕不了业，所以就很纠结。
但是纠结也没持续太长时间，如果我们把拥塞控制看成一种随机流量的管理方案，incast 显然不是一种随机流量，而是一种 case，为了单处理这个 case 显然重新发明一种拥控算法是不必要的，所以产生了中间件辅助的想法。端侧拥控处理大部分随机流量，中间件解决一个 case 就是了。处理 incast 就设计一些简单算法，直接均分完事，并且考虑到就 ToR 可能 incast（核心层假设无 oversubscription），方案部署性可能也很好，所以就按这个方案开整了。当时测的结果十分不好，没啥效果，直到后面分离方案之后重新整理代码，才发现可能是代码哪里写错了导致的效果不好。
首先投的 ICNP，但是意见全是说没 testbed，实现不了，其他的意见倒也不算太尖锐，但是最后还是挂了。挂了之后补了一些模拟实验，改了改论文就转投 FGCS 了。当时想的是 FGCS 审稿快，并且也不是纯网络的，可能对实验要求没那么高（但是最大的问题是当时没有实际环境），然后 FGCS 上来就审了半年，这半年里实际实验环境都搭好了，P4 和 DPDK 也实现了，然后半年回来的审稿意见还是要加实际实验，甚至还要加不同拓扑的和更大规模的模拟。补了两个月实验之后又审了小半年稿，整体折腾了一年才结束。
整篇文章都想表达一个观点：端侧拥塞控制解决随机流量，中间件解决特殊流量。incast 这种特殊流量特殊得恰到好处，所以可以有一个简单的算法来解决。但至于中间的数学分析，感觉还是看个乐。
实验代码在这里。