来源：TSNLAB 微信公众号
TSN近期技术系列文章第一篇，从以下几点，写写ATS（Asychronous Traffic Shaping，异步流量整形）。
•ATS原理简述与标准沿袭
•ATS对比CBS
•ATS对比HQoS
•ATS的未来
关于ATS的技术细节，公众号
中写了一个系列7篇关于ATS的文章，很详细，推荐感兴趣的读者去观看。
一、ATS原理简述与标准沿袭
回顾一下《TSN调度机制，看这一篇就够了！》，其中ATS相关内容原文拷贝过来：
异步流量调度（ATS，Asynchronous Traffic Shaping），也和单速令牌桶机制有点像，甚至ATS调度器的关键配置参数就是cir（CommittedInformationRate）和cbs（CommittedBurstSize）。简单来讲，cir控制整形器允许通过的整体速率，cbs控制整形器能容忍的突发程度。TSN标准中，ATS核心算法部分写了一大堆伪代码，看得人云里雾里，但实际上这段伪代码本质上就是在描述单速令牌桶的整形机制。不过，ATS的优点在于，通过在报文入队时运行算法，给报文分配一个允许调度时间（EligibilityTime）。这样，在传输选择机制进行判断的时候，不需要再重新执行令牌桶的计算。另外，ATS还有一个调度器组的概念，即多个ATS调度器可属于一个ATS调度器组。ATS的伪代码还描述了当ATS调度器组对应一个物理上先入先出（FIFO）队列时的情况。反过来，ATS调度器不依赖于和硬件调度队列进行绑定，因此，ATS调度器可以进行灵活的整形，逐流、或逐汇聚流整形，均可。通过使用ATS进行逐跳整形，网络中不产生大突发和突发汇聚，整体的网络性能会得到改善。
《TSN的异步整形（ATS）(1)：基本思想》里面也提到，ATS最早源自Johannes Specht（802.1Qcr标准的Editor）在2013年提出的基于紧急度的调度器（UBS）。我在2019年的时候和Johannes本人聊过为什么在标准讨论过程中，UBS逐渐演变成了ATS，从他的回答中总结出最核心的原因是，IEEE 802.1需要定义出来的新调度器/整形器在工程上是相对易于实践的。可以看到，现在的ATS允许多流在同一个队列中调度，例如有1000条流经过交换机，交换机还是只支持经典的8队列，那也是可以用ATS的。这样，ATS终于成为了802.1Q中继SP、CBS、ETS、TAS之后的第五个传输选择算法。
二、ATS对比CBS
在技术上，我们认为ATS显著优于CBS，原因如下。1，CBS约等于桶深为0的、可以欠一个报文的令牌桶整形器（不完全等于，因为CBS中队列在等待时credit会累积到超过“桶深”），而ATS可以配置“桶深”，即CommittedBurstSize，所以ATS在可以实现类似CBS的整形效果的同时，配置更灵活；2，CBS是基于class的整形，同class流量之间的干扰无法消除，而ATS可以基于流、汇聚流、class进行交织整形，可以较好地按需保持流之间的隔离性；3，CBS早期缺乏对时延保障的准确量化计算，仅对七跳拓扑提供配置推荐，虽然后续也可以通过理论分析进行准确计算，但ATS的量化方式扩展性更好，在任意拓扑、任意流量下，可以基于流量模型计算出配置，难度显著低于CBS。
但是CBS目前在商业上更成功，虽然这得益于AVB的先发优势，但其中也有值得借鉴的经验。AVB profile中进一步限制了CBS只能用于最高、次高优先级队列，分别调度音频、视频，再配合SRP资源预留和1588v2时间同步，形成了虽有局限但能解决特定场景问题的完整网络方案，提供给上层使用。这是ATS未来可以参考的部分。
三、ATS对比HQoS
我认为仅就ATS在标准中的定义而言，是可以通过两层HQoS来等效实现的。
HQoS（Hierarchical Quality of Service），层次化QoS，是很常见的用在路由器、交换机上的方案。HQoS可以是两层、三层、四层、五层等，而且一般每一层都能单独配置一个令牌桶整形器，更多信息读者可以自行查找。从公开的文档里随便找了个图：
假设一个支持8个ATS整形器组、每组支持8个ATS整形器的ATS设备。那它的功能就是：基于流量识别把报文放入64个ATS整形器中的一个，并且依照该ATS整形器的cir和cbs的配置为该报文计算EligibilityTime；随后，这个报文在其所属的ATS整形器所对应的ATS整形器组中遵循FIFO排队，并且轮到自己时，当前时间必须大于等于EligibilityTime方可被调度。ATS整形器组之间的调度方式可任意配置，如SP。
好，接下来我们来看一个两层HQoS队列，上层8队列，每个上层队列又对应下层8个队列，每个下层队列可以配置令牌桶整形器的cir和cbs。同样的，基于流量识别把报文放入64个下层队列中的一个，并且依照该下层队列对于令牌桶所配置的cir和cbs来维护令牌桶状态，当且仅当报文能取走足够的令牌桶时（令牌桶的具体机制不清楚的读者请自行查资料），该报文可以进入上层队列，并在其中遵循FIFO排队。上层队列之间的调度方式可任意配置，如SP。
这里的关键，一是计算EligibilityTime的本质，就是在基于注入速率cir、桶深cbs的情况下，计算到什么时间才能有足够的令牌，所以和传统令牌桶机制中，令牌够了才允许调度是一个道理；二是，ATS中的当前时间大于EligibilityTime，和HQoS中的令牌桶中获取了足够的令牌，都是该报文被选择发送的必要不充分条件，即不满足条件一定不能被发送，但满足条件也不一定马上能被发送（因为ATS调度器组或HQoS上层队列之间还有调度上的竞争）。
另外，ATS中的最大驻留时间，可以通过配置缓存、配置流量监管等方式等效实现。
欢迎读者们讨论或尝试证伪“ATS可以由HQoS实现”这个命题。如果这个命题成立，对于加速ATS的应用，是个利好。
四、ATS的未来？
如果不局限于IEEE 802.1Q标准的ATS本身，即不把ATS仅仅当做单节点整形器来看待，而是考虑ATS作为一种网络端到端的确定性方案，再联系到学术界关于ATS广泛的研究，其实ATS的核心理念就是，“在源端或网络入节点，尽量把流量突发整形为相对平滑的模式，从而改善整个网络的性能。同时可以通过数学分析给出流量的时延上界”。
我们十分认同这个理念，尤其是在大规模网络中。就好比交通系统，辅路汇入主路时，如果辅路只有一条道，即使辅路车流大，也只会在辅路上排队，对主路的影响较小；反之，如果辅路三条道，主路三条道，汇聚后还是三条道，那只要车流量较大时，必定就会形成一个拥塞点。
大规模网络中，很多问题都是突发引起的，有大尺度的突发（例如著名的TCP全局同步问题），也有小尺度的突发（例如一个视频业务，其流量就有显著的突发特征）。ATS中通过合理配置cir和cbs就可以分别处理这两个问题。甚至我们可以用博弈论中经典的囚徒困境来类比（简单理解，在各方无法有效沟通的前提下，招供是每个人的最优策略，但每个人都招供，会造成总体结果非最优，即损人不利己的结果）：
从小尺度突发的角度，例如一个视频APP，对于开发者而言，不做额外的平滑流量的操作是更优、更简单的，但是成千上万的微突发最终可能会造成某一跳的拥塞。而有了ATS，可以在网络边缘侧（网络入口）直接通过配置较小的cbs“吃掉”突发。
从大尺度突发的角度，TCP的各种拥塞控制算法，包括QUIC里面的拥塞控制算法，都需要尽快给用户探到一个更高且相对合理的发送速率。在这方面就先不过多展开，但整体看来，网络中无时无刻都有千千万万组终端在各自为战的做这件事，这就是个非合作博弈的过程，最终的结果也终究难以逃离“损人不利己”的纳什均衡。而有了ATS，可以在边缘侧直接用cir控制流量平均速率的上限，对于用户而言，就是花多少钱，买多少服务，不需要自己去探索了。（ATS是否伤害到网络的统计复用性？一种简单的解决方法是，对于对服务质量有要求的业务，可以“购买”ATS的服务，即成为ATS业务，并且对于非ATS业务而言是绝对高优先级，而非ATS业务可以复用所有剩余带宽。）
也就是说，ATS直接“堵死了”招供这条路，从而破解了囚徒困境（想必我是第一个从ATS讲到博弈论的人哈哈哈）。
当然，实际的模型会更复杂。大规模网络下的性能研究，就好比宏观经济学一样，影响因素太多，但又经常很难判断哪些因素是主要因素，建模也很难建的准。所以虽然我们猜测，如果广泛在网络边缘节点部署ATS，可能可以大幅度改善网络整体性能，但也没有能力自己去证明这个事情啦。所以在此抛出来，写给有缘的读者吧。