关于CDN网络质量感知的一些论文阅读
Staying Alive: Connection Path Reselection at the Edge NSDI21
fastly的工作
当节点到用户有多条链路可以选择，主要是经过不同的AS的时候，一条链路阻塞了可以考虑使用第二条链路。这种case主要是适合海外的网络场景。
做到了TCP协议栈里，这样普适性强，并且可以做到流粒度，只要路由信息有记录就可以。
有两类切换。第一类是建连之前，当回复超过n次syn ack没有响应时切换出口回复。第二类是传输时，当超过t没有收到(s)ack时切换，t与rto有关。
没有什么链路感知的能力，粒度太细，帮助不大。
related work里有inflex和blink，需要可编程交换机在数据平面的支持。还有swift，这些都是侧重于reroute，不是感知。
espresso, edge fabric, mptcp这些也提到了。
Zooming in on Wide-area Latencies to a Global Cloud Provider SIGCOMM19
微软的工作
关注的是tcp 建连时间，区分cloud位置，移动设备和非移动设备，5min粒度，以ip/24粒度加以聚合，至少10个数据。相当于对被动数据的观察，不追求全量的感知，按照ip段内用户数量对优先级排序。可能不是给CDN而是给云用的？
定义了质量差的阈值，研究质量差的ip段在区域内的比例、时序分布、持续的时间。
被动探测用来发现问题是出在节点、中间还是用户侧，主动探测用teraceroute来确定中间哪个
AS出了问题。
related work有 tomography edgefabric panetseer iplane trinocular odin whyhigh 前三个是被动的，中间两个是主动的，最后两个是hybrid
Odin: Microsoft’s Scalable Fault-Tolerant CDN Measurement System NSDI18
微软的工作
CDN规模也不大，100个PoP；微软自己的服务用anycast，第三方业务用dns；
探测规模：5分钟每城市-节点上千次。探测准确性与要求的精度有关。
考虑使用client端的探测有几个好处：1.用户连不上server的case也能诊断到；2.可以探测其他家的服务器，验证是不是我们自家的问题；3. 可以进行A/B测试
使用用户主动发起探测，7层，结合3层探测。
Engineering Egress with Edge Fabric Steering Oceans of Content to theWorld SIGCOMM17
facebook的路由调度系统
三个点 1. 节点各出口链路负载不平衡，需要进行动态调度优化 2. BGP调度系统 3.通过小规模流量调度实现的路径实时感知（节点*路径*prefix）
关于facebook cdn的一些信息：节点会接入不同的AS；DNS-based 调度；edge fabric不会控制调度策略；PoP 量级 dozens of，似乎不多；调度策略似乎是基于IP前缀的
这篇文章是节点出口链路的选择，相对于ECMP的升级版WCMP，这个方法收敛快，更准确，迭代更快。
测量的部分会随机抽一部分（0.5%)流量走非最优的链路，保证有量来监控，这一部分是用DSCP头实现的，参考价值不大。检测也是抽样的，1/1000抽样率（非最优链路1/10），指标有重传率，RTO，SRTT，发送接受数据包数，goodput。
几个related work
footprint PECAN Rntact Espresso 还有sdwan 的b4 和SWAN