2种低延迟服务的通用优化技术
郭雅宁1, 徐明伟1,2    
1. 清华大学 网络科学与网络空间研究院, 北京 100084;
2. 中关村国家实验室, 北京 100097
摘要:近年来, 各种低延迟服务吸引了越来越多的用户关注, 部署规模不断扩大。为提升低延迟服务性能, 工业界和学术界提出多种优化方案并部署在网络传输路径的不同位置, 其中部署在端侧的各种低延迟拥塞控制算法和部署在网络侧的主动队列管理算法应用较广泛, 这2种算法的设计目标都是尽量避免数据包排队, 减少端到端延迟, 但是由于这2种算法是独立的, 存在潜在的不适配问题, 影响应用的性能表现。因此, 有关这2种算法的协同优化也成为一个研究方向, 基于机器学习的通用算法和端网联合优化是最具代表性的方案。该文总结了低延迟拥塞控制算法和主动队列管理算法的设计思路、组合使用时的性能测试结果以及协同优化的问题, 认为跨层联合优化是解决现有不适配问题并进一步提高应用性能的可行思路, 建议低延迟服务性能优化的研究应重视通用性和实际部署性。
关键词拥塞控制算法    主动队列管理    低延迟服务    跨层联合优化    机器学习    性能优化    
Two general optimization techniques for low-latency services
GUO Yaning1, XU Mingwei1,2    
1. Institute for Network Sciences and Cyberspace, Tsinghua University, Beijing 100084, China;
2. Zhongguancun National Laboratory, Beijing 100097, China
Abstract: [Significance] Low-latency services have become indispensable in people's work and daily life. Various low-latency services exist, including video conferences for online communication and cloud games for entertainment, which can meet different requirements of users. These services make it convenient for users to interact anywhere in real time, thereby overcoming the limitations of traditional applications. Therefore, these services have recently attracted numerous users, and their deployment scale has rapidly expanded. With the development of 5G technology, the coverage of low-latency services will spread further; these services have broad development prospects. Therefore, performance optimization of low-latency services is a hotspot in academia and industry. The most critical performance indicator for low-latency services is end-to-end latency. In addition to maintaining low latency, achieving high throughput and link usage to improve service quality and attract more users is also necessary. Therefore, performance optimization is key in the further development of low-latency services. [Progress] Various performance optimization schemes used at different positions of the transmission path were proposed by researchers. Among them, the two most widely used schemes were the low-latency congestion control algorithm (CCA) deployed on the server side and the active queue management algorithm (AQM) deployed in the network. Their design tried to avoid queuing as much as possible and to reduce end-to-end delay. The CCA and AQM constantly updated their design to solve the limitations of previous algorithms, improved their performance, and enhanced the practicality of the algorithms for large-scale deployment. Specifically, CCA improved the estimation strategy of congestion signals to make them more accurate, completed the logic of the adjustment of the sending rate and incorporated consideration for fairness into the design. AQM focused on queuing delay and minimized the amount of parameters, trying to implement a more lightweight algorithm. Although CCA and AQM shared similar goals, they were researched in parallel and independently. Being in the same control loop and both affecting the quality of low-latency services, the synergistic effect between CCA and AQM attracted considerable academic attention. Existing evaluations indicated a potential mismatch, resulting in poor performance when they were used together. To achieve superior collaboration between CCA and AQM, various optimization solutions were proposed. Among them, general CCA and AQM based on machine learning and cross-layer joint optimization were representative schemes. Although these solutions aimed to solve the mismatch problem and proposed general algorithms, they faced challenges in real-world deployment. [Conclusions and Prospects] This paper summarizes the main design ideas and performance evaluation of important low-latency CCA and AQM, sorts the performance and theoretical analysis of the combined use of the two algorithm types, analyzes the potential coordination problems between them, and further elaborates on the research work on the collaborative optimization of CCA and AQM. Through the summary, we propose that future research on low-latency services performance optimization must emphasize versatility and practical deployment and believe that cross-layer joint optimization is a practical idea to solve the existing mismatch, make CCA and AQM work well together and further improve the performance of low-latency services, which can be the focus of future research.
Key words: congestion control algorithm    active queue management    low-latency services    cross-layer joint optimization    machine learning    performance optimization    

低延迟服务类别丰富,可以满足用户的不同需求,广泛应用于用户日常生活和工作中。近年来,低延迟服务也在不断扩大使用范围和部署规模[1-2],用户数量和使用时间都在逐步增加。随着移动蜂窝网络和5G等技术进一步发展,低延迟服务的可覆盖范围有望进一步扩大,服务质量也将得到提升,发展潜力巨大。

学术界和工业界都在不断优化低延迟服务的性能。低延迟服务最关键的性能指标是延迟,其次是在满足延迟要求的基础上保持较高的吞吐。低延迟应用在传输延迟上有较严格的限制,如云游戏的延迟限制为96 ms[3]。这些限制要求应用具有良好的往返时延(round-trip time, RTT)或端到端的延迟表现。在满足低延迟要求的基础上,用户更倾向于高质量的传输内容,一般而言,保持高吞吐可以使应用以较高的码率传输更清晰的画面,优化用户使用体验。

为满足低延迟服务的应用需求,数据的传输需要保持较低的延迟。造成传输延迟较高的主要原因是端侧发送速率和网络可用带宽不匹配致使数据包在瓶颈处排队。常见的解决思路是在端侧调整发送速率以适应网络状态,或在网内瓶颈处抑制队列持续增长。在端侧,拥塞控制算法(congestion control algorithm, CCA)控制拥塞窗口或发送速率,是影响延迟和吞吐性能的主要算法。目前低延迟CCA通过速率调节避免数据包在瓶颈队列堆积,以保持较低的延迟。在网内,主动队列管理(active queue management, AQM)算法通过主动丢包缓解瓶颈处的排队。低延迟CCA和AQM算法是低延迟服务性能优化的关键技术,但是这2种算法独立地部署在控制回路的不同位置,缺少对彼此的兼容性,这导致一些CCA和AQM算法组合性能不佳。为解决上述问题,一部分工作通过设计通用算法或实现跨层优化使端侧的CCA和网内的AQM算法协作,从而达到更好的性能效果。

1 低延迟CCA

CCA是传输层重要的控制算法之一,依托TCP(transmission control protocol)、UDP(user datagram protocol)和QUIC(quick UDP internet connections)等传输协议,通过调整端侧的拥塞窗口或发送速率,既能在网络出现拥塞时避免因发送超量的数据包而导致缓冲区队列堆积、排队延迟上升,使端到端的延迟较低,又能实现合理的吞吐量和较高的链路利用率。因此,CCA是延迟、丢包率和链路利用率等传输指标表现良好的关键。CCA根据其对网络状态的实时判断调整拥塞窗口或发送速率,其依据的信号被称为拥塞信号,该信号可以是丢包、延迟和带宽,此外,端侧还可能同时考虑多种信号判断网络状态。

传统基于丢包的CCA较可靠且设计简单,但是对延迟有严格要求的低延迟应用来说,其存在明显不足。基于丢包的CCA倾向于填满缓冲区,直到缓冲区溢出并使端侧接收到丢包信号才开始减小拥塞窗口,这会导致瓶颈队列长度和排队延迟保持在较高水平。考虑到低延迟应用的特点,较高的端到端延迟降低了网络服务质量,而且丢包会影响低延迟应用的传输质量,降低用户的体验感。

因此低延迟应用倾向于使用一些以低延迟为优化目标的CCA,这些算法对于上升的延迟比较敏感,避免数据包排队,满足应用需求。相对于丢包信号,延迟及带宽的测量可以提供更丰富的信息,端侧可以针对延迟和带宽信号进行各种计算处理,因此拥塞信号的具体形式有更多选择,不同算法的实现也有所区别。

本文对部署在广域网中并被应用于低延迟服务的CCA进行梳理。由于CCA数量繁多,本文仅选择目前常见且规模较大的低延迟应用使用的CCA,以及在相关拥塞控制研究中提及频率较高的CCA进行研究。本文首先介绍各种CCA的实现逻辑,然后进行综合性的对比和总结,对于CCA的评价包括CCA的具体性能表现和可部署性2个方面。

1.1 CCA的算法逻辑 1.1.1 基于延迟的CCA

延迟的测量和统计处理有多种方式, 因此不同算法中延迟信号的具体表现形式也存在差异。本小节涉及的一些CCA虽然在感知丢包后也会减小拥塞窗口, 但是仍然将这些CCA归为基于延迟的CCA这一类别。这是因为一方面这些CCA对延迟信号的处理比对丢包信号的处理更加复杂和精细;另一方面,这些CCA没有单独维护一个基于丢包的窗口,仍主要依赖于延迟信号来调整窗口,因此不能认为它们是同时考虑多种信号的CCA。

Brakmo等[4]提出的Vegas算法采用RTT延迟信号,根据实时RTT和连接中的最小RTT估计目前在瓶颈处排队的数据量,并将排队数量维持在较低范围。为此,引入αβ这2个阈值,根据估计的排队数量与2个阈值的相对大小关系相应地增加或减少拥塞窗口,窗口更新规则如下:

$ D=\left(\frac{c}{\mathrm{RTT}_{\min }}-\frac{c}{\mathrm{RTT}}\right) \cdot \mathrm{RTT}_{\min } ; $ (1)
$ \begin{gather*} c= \begin{cases}c+1, & D<\alpha ;\\ c-1, & D>\beta ;\\ c, & \alpha \leqslant D \leqslant \beta.\end{cases} \end{gather*} $ (2)

其中:c表示拥塞窗口,RTTmin表示连接中最小实时往返时延,D表示估计的排队数据包数量。实验表明,相比于丢包的CCA,Vegas算法减少了丢包和重传。虽然Vegas算法基于延迟信号的窗口大小决策有助于实现低延迟,但是存在一些性能问题[5]。首先,延迟抖动带来的测量误差影响端侧的决策,导致链路利用率较低;其次,对于存在持久拥塞的链路,Vegas算法测量的最小RTT偏大,估计排队数据包数量偏小,因此不会减小拥塞窗口,也不能缓解拥塞现象;最后,在公平性上,使用Vegas算法的流与使用基于丢包CCA的流在同一瓶颈竞争时的链路利用率较低,若2条流均使用Vegas算法,则后建立连接的流可能获得更大的带宽。

Jin等[6]提出的FAST算法与Vegas算法相似,使用RTT作为拥塞信号调整拥塞窗口,但该算法比Vegas算法更加可靠,其建模方式更加复杂,且需要引入更多参数以建立更合理的RTT和拥塞窗口的关系,表示如下:

$ c=(1-\gamma) c+\gamma\left(\frac{\mathrm{RTT}_{\min }}{\mathrm{RTT}} c+b\right) . $ (3)

其中:bγ分别表示偏置系数和滑动平均系数。

FAST算法可以获得较好的吞吐和延迟性能表现,但是与Vagas存在相似的缺点,不仅因拥塞信号测量存在误差而在链路利用率上表现不佳,还存在各种公平性的问题。

当来自类似文件传输应用的流和对延迟敏感的应用的流共享一个瓶颈时,前者需要主动让出带宽以保证后者正常传输,为此,前者会采用低优先级CCA,这类CCA对延迟增加非常敏感。Aramani等[7]提出的Nice算法是一种基于Vegas算法的低优先级CCA。端侧根据RTT估计排队延迟,在所有关于排队延迟的统计结果中,只要超过目标值的样本数量占比大于一定阈值,窗口就立即减半,窗口更新规则为:

$ Q_{\text {delay }}=\mathrm{RTT}-\mathrm{RTT}_{\min } . $ (4)

其中Qdelay表示排队延迟。

Kuehlewind等[8]提出LEDBAT(low extra delay background transport)算法,以端到端延迟作为拥塞信号,估计排队延迟,并据此计算当前排队延迟与目标阈值的差,然后相应地改变拥塞窗口。在LEDBAT算法中,当排队延迟超过阈值时,端侧会立即降低拥塞窗口,窗口更新规则为

$ \partial c=\frac{G\left(t+O_{\min }-O\right) A}{M \cdot t \cdot c} . $ (5)

其中: $O$表示端到端延迟, $O_{\text {min }}$表示连接中的最小端到端延迟; $t$表示目标延迟; $M$表示最大报文段长度; $G$为系数; $A$$\partial$表示ACK (acknowledge character)包确认的字节数和取微分操作。LEDBAT算法的局限性在于其依赖于对阈值的设置,如果阈值设置不符合某种网络条件的要求,就不能对排队及时响应,而且也存在新旧连接的公平性问题[9]

随着移动网络技术的发展,一些研究开始专注于移动蜂窝网络的CCA。蜂窝网络的带宽变化幅度和频率比其他网络更大,高速变化的接收端速率容易造成响应式CCA决策滞后。Zaki等[10]提出的Verus算法引入了预测思路,拥塞信号是RTT梯度,算法保留延迟和拥塞窗口的历史数据,并不断刻画二者的函数关系。Verus算法根据延迟梯度估计未来的延迟,结合关系函数推测合理的窗口大小。Verus算法强调了移动网络的带宽变化,但其不能准确估计链路可用容量,而且引入了多个需要调试的参数。Abbasloo等[11]提出的C2TCP(cellular controlled delay transmission control protocol)算法也是针对蜂窝网络设计的CCA,其主要拥塞信号是RTT,当RTT超过目标值时,算法模拟网内的AQM机制更新拥塞窗口,RTT超过目标值的时间越长,减少拥塞窗口动作的时间间隔越短。

新的网络场景会推动研究者提出新的CCA,早期基于延迟的CCA存在的一些性能问题也促进CCA不断发展。Arun等[12]提出的Copa算法根据目标速率和实际速率的差距调整窗口,其延迟拥塞信号是RTT。Copa算法不断估计排队延迟,并按照其对网络建模公式进行计算得到目标速率。考虑基于延迟的CCA与基于丢包的CCA竞争存在不公平现象,因此在普遍模式之外,Copa算法还增加了竞争模式。Copa算法通过设计2种模式,同时实现了低延迟与良好的公平性,实际部署的结果也表明其在大多数情况下可以获得高吞吐和低延迟。

1.1.2 综合考虑延迟和丢包的CCA

混合模式的CCA同时将丢包和延迟信号作为调整窗口的依据,但是在不同设计中这2个拥塞信号的重要程度和对窗口大小的影响程度有差别,因此实际的算法设计及性能效果不同。

Liu等[13]提出的Illinois算法在拥塞避免和快速恢复阶段考虑了延迟信号,但是仍然将丢包信号作为主要的拥塞信号,延迟信号用来调整这2个阶段窗口的系数。虽然Illinois算法考虑了延迟信号,避免在排队延迟较大时仍大幅增加窗口,但是主要拥塞信号仍为丢包,也即本质的拥塞响应机制没有变化,因此瓶颈队列仍然不可避免地出现堆积。

为解决基于延迟的CCA公平性问题以及无法与基于丢包的CCA竞争的问题,Tan等[14]提出的CompoundTCP将拥塞和延迟信号放在了同等位置。CompoundTCP的目标是在网络状态良好时提高吞吐,在出现排队但并未填满缓冲区时及时减小窗口。CompoundTCP的拥塞窗口由2部分组成,一部分是基于丢包的窗口,该窗口的更新逻辑和基于丢包的CCA算法相似;另一部分是基于延迟的窗口d,延迟信号是RTT, d的更新规则如下:

$ d= \begin{cases}d+\left(\vartheta c^{k}-1\right), & D<\gamma ;\\ d-\delta D, & D \geqslant \gamma ;\\ c(1-\mu)-\frac{l}{2}, & \text { loss }.\end{cases} $ (6)

其中:l表示基于丢包的窗口,ϑkμδ均为使用者可根据需求调整的参数。

CompoundTCP同时考虑了延迟和丢包2种拥塞信号,既可以兼顾延迟和吞吐方面的性能,又可以保证与TCP流量竞争的公平性。但是这种延迟处理可能存在测量上的偏差,延迟的波动会引发端侧窗口的明显变化。

Illionis和CompoundTCP均为基于TCP协议的CCA,一些低延迟应用选择使用UDP协议进行传输,建立在UDP协议上的低延迟CCA也有相应的研究成果。

Carlucci等[15]提出的GCC(Google congestion control)算法包括基于延迟和基于丢包2部分,其中:基于延迟部分根据端到端延迟的梯度判断网络状态,端侧将网络分为3个状态,GCC算法根据延迟梯度变化在3个状态之间转化,并相应地选择增速、降速和保持现有发送速率;基于丢包的部分则根据丢包率与阈值的大小关系改变发送速率。GCC算法在保持较低的排队延迟的同时也能较好地实现公平性。

Zhu等[16]提出的NADA(network-assisted dynamic adaption) 算法的延迟拥塞信号是端到端延迟和丢包,二者以一定系数融合并得到一个融合指标,端侧依据融合的结果调整发送速率。NADA算法的参数设置根据经验调试,缺乏应对多种网络环境的普遍适用能力。

Johansson[17]提出的SCReAM(self-clocked rate adaptation for multimedia) 根据估计的排队延迟和目标延迟之差调整发送窗口,限制传输中的数据数量,同时动态调整数据包的发送间隔以减少排队。

1.1.3 基于带宽估计的CCA

Cardwell等[18]提出的BBR(bottleneck bandwidth and RTT) 算法将拥塞控制的稳定工作点保持在没有数据包排队的状态。目前各种基于延迟的算法主要关注重点实时延迟或者RTT的变化,而BBR算法则尝试估计链路的BDP并以此作为拥塞窗口的设置依据,试图在维持数据包不排队的同时尽可能地提高链路利用率。BBR算法相关测试表明相比于基于丢包的CCA,其提高了吞吐量并减少了延迟,同时能够实现一定的公平性,但是文[19]评估工作表明,其在不同大小的缓冲区仍存在各种公平性和性能问题。

BBR算法和Copa算法通过对拥塞信号多种处理减小了测量误差,也针对竞争和RTT不公平的问题进行了相应设计,实现了较好的公平性。Copa算法相比于BBR算法,具有更小的延迟和吞吐。Copa算法在非竞争模式下对上升的延迟非常敏感,因此可较好地保持低延迟,而BBR算法为了实现公平性会选择更加保守的参数,从而导致排队较长。

针对蜂窝网络带宽多变及CCA响应速度较慢的问题,Winstein等[20]提出的Sprout算法使用数据包到达时间作为主要延迟拥塞信号。Sprout算法并没有采用根据拥塞信号到网络状态的某种映射关系调整拥塞窗口,而是直接利用数据包的到达时间并通过概率推断的方法推断瓶颈处的可用带宽,进而确定发送速率。Sprout算法的优化目标是在保证较高吞吐的同时控制排队延迟。Sprout算法没有针对丢包设计响应机制。

1.2 CCA对比与总结

本节对低延迟的CCA进行综合对比,从CCA的设计目标、设计思路和性能等3个方面进行总结。

1.2.1 CCA的设计目标变化趋势

相比于基于丢包的CCA,低延迟的CCA对延迟的上升更加敏感,在缓冲区队列开始堆积后能够及时调整窗口或发送速率,有效抑制排队延迟持续上升。

低延迟CCA的研究是逐步推进的。1) 从算法设计的实现来说,不稳定的性能表现使CCA不断更新设计。如初始处理延迟拥塞信号的方式缺乏鲁棒性,将RTT的测量值直接映射到相应网络状态会造成一些性能问题。CCA针对这些问题逐步迭代设计,首先拓展拥塞信号类型和处理方法,综合考虑端到端延迟、延迟梯度和带宽等多种信号, 或者通过转换多种竞争模式改善延迟、吞吐性能及公平性表现;然后,通过对网络建模以及改进RTT和带宽等指标的测量方式使算法逻辑更加完善,性能更稳定。2) 从算法的设计目标来说,网络背景的更新也促进CCA的发展。例如,无线技术的发展给CCA算法设计提出了更多挑战, 比如需要算法具有适应高度变化的移动链路带宽的能力。因此,为蜂窝网络而设计的CCA在反馈式算法逻辑的基础上增加了基于学习、概率预测等新思路,使发送速率及时与快速变化的链路带宽适配。

1.2.2 CCA的设计思路

关于CCA的综述可以分为2类,一类是对于拥塞控制原理设计的理论性分析,另一类则关注CCA的实际性能。前一类工作大多以拥塞信号作为CCA的分类依据,如文[21]将CCA分为基于丢包、基于延迟、基于网络容量估计及同时考虑延迟和丢包共4种类别;文[22]则划分得更详细,将基于丢包的CCA进一步划分为完全基于丢包和基于丢包但对带宽敏感2种算法,同时更细致地划分混合算法。此外,一些算法的归属也有差异,如文[21]认为BBR算法属于同时考虑多个指标的算法,但文[22]则将其归为基于带宽测量类型的CCA。文[23]从算法逻辑上对应用在蜂窝网络中的CCA进行了细致划分,将在设计中引入了对网络状态预测的Sprout算法和Verus算法归为基于预测的CCA,其余CCA则仍属于基于传统响应式的CCA。文[24]也对可以在蜂窝网络使用的CCA进行总结,分为基于丢包、基于延迟、混合算法和机器学习这4类。

1.2.3 CCA的性能对比

在具体网络指标的表现上,一系列工作对CCA进行了全面的测试。Abbasloo等[25]搭建了一个涵盖多种网络环境的server-client测试框架,测试结果显示,在跨洲连接(纽约-孟买)中,Copa、C2TCP、LEDBAT、Vegas和BBR算法的延迟表现相似,均集中在约110 ms。在带宽方面,BBR算法的平均带宽为150 Mbps,C2TCP算法约为125 Mbps,其余CCA的带宽表现与C2TCP算法有较大差距,平均带宽仅约10 Mbps。在同一洲内的连接中, Copa和LEDBAT算法的延迟小于20 ms, BBR和C2TCP算法的延迟表现最差, 几乎是Copa算法的2倍。在带宽方面, BBR和C2TCP算法的平均带宽为95 Mbps,Copa和LEDBAT算法的平均带宽分别为65和55 Mbps。在蜂窝网络中, Copa、Vegas和C2TCP算法的延迟均约20 ms, 而BBR算法的延迟则达到60 ms。在针对蜂窝网络设计的CCA中,C2TCP算法非常适用,延迟、带宽均表现良好;Sprout算法带宽性能较好, 但延迟表现处于居中水平。Goyal等[26]将测试建立在Wi-Fi和蜂窝网络场景中,Wi-Fi场景采用802.11n无线传输协议,蜂窝网络的最小RTT为100 ms。测试结果表明:在延迟性能上,Copa算法表现最好,其次是Sprout、Verus和BBR算法;在带宽方面,BBR算法优于Verus算法。Du等[27]采用带宽分别为12、24、48和96 Mbps 4个有线网络以及网络模拟器生成的蜂窝网络数据进行测试。结果表明,对于延迟而言,Copa、BBR和Sprout算法均实现了较低的延迟;对于带宽而言,BBR算法的表现最好,Sprout算法次之,Copa算法最差,BBR算法的平均带宽相比于Copa算法,提升了50%。Dong等[28]的测试模拟了4G网络,结果表明在延迟方面,Sprout算法的性能最好,其次是Vegas算法和BBR算法;带宽方面,按照由好及差的顺序依次是BBR、Vegas和Sprout算法。综上所述,Vegas、Sprout、Verus和Copa算法都对延迟比较敏感,其中Copa算法无论是在蜂窝网络还是Wi-Fi网络都可以保持较低的延迟,Sprout和Verus算法则在蜂窝网络下具有良好的延迟性能表现。但是在带宽表现上,这4个CCA与BBR算法有较大差距。除了部署在蜂窝网络中的C2TCP算法,其他CCA无法在延迟和带宽2个性能指标上均获得良好表现,只能以牺牲一个指标为代价来优化另一个指标。

在CCA与不同网络环境适应性方面,本节首先关注接入网络类型对CCA性能的影响,涉及的低延迟CCA主要针对应用于广域网的传输,瓶颈通常在最后一跳且通过Wi-Fi、移动蜂窝网络等多种方式接入。除了接入网络类型,网络场景的特点还包括中间节点队列和连接的网络特征。一个CCA既可能针对一种网络环境设计其算法逻辑,也可能不要求特定网络环境获得通用性。Sprout、Verus和C2TCP算法针对蜂窝网络点而设计,目标是适应网络带宽的快速变化,实现低延迟和高带宽利用率;Copa算法则针对无线网络,不限于蜂窝或Wi-Fi网络;其余CCA对目标网络场景没有具体要求,各自适用的网络场景也受这些算法的时间限制,如早期提出的Vegas没有明确的网络类型。在网络特征方面,FAST和CompoundTCP的设计目标是形成较大的BDP连接。CCA在不同网络场景中的性能评估结果也验证CCA适合的使用场景,如Sprout算法在蜂窝网络背景中性能良好就说明其适用于蜂窝网络。

在CCA与上层应用的适配性方面,本文梳理了各种低延迟应用选择CCA的情况。Facebook公司推出的直播软件MetaLive,采用带外反馈的传输协议及Copa算法;面向游戏的实时流媒体视频平台Twitch和Microsoft推出的云电脑应用Windows365均使用TCP协议,采用Copa和BBR算法等;Google推出的云游戏平台stadia和视频会议Zoom使用UDP,对应的CCA为GCC和NADA算法。

上述直播应用、实时音视频平台、云电脑、视频会议和云游戏为目前市场上使用规模最大的低延迟应用代表。CCA动态调整拥塞窗口或发送速率,也指导着应用层的编解码器生成一定质量的传输内容,CCA在影响传输层指标RTT和带宽的同时,也在影响应用指标帧延迟和画面质量。在网络不断波动的情况下,不完善的CCA可能出现由于对拥塞不敏感而使队列堆积或者过度降速,进而导致链路利用率过低的情况。队列堆积会引起RTT和帧延迟上升,如果帧无法在要求时限内到达客户端,画面会出现卡顿,而较低的链路利用率会导致画面质量差,清晰度下降。良好的CCA可以使发送速率适配网络带宽,满足用户需求。

2 AQM算法 2.1 AQM算法设计思路

控制排队延迟的一个常见机制是主动队列管理策略。先进先出(first-in first-out, FIFO)队列保持简单模式易出现缓冲区膨胀现象,造成较大的排队延迟,因此一些AQM算法被提出,通过在包填满缓冲区之前开始主动丢包,从而控制队列长度,丢包概率随队列状态变化而变化。AQM算法也是从性能和可实际部署2方面进行评估,其中可实际部署性评价的是AQM在实际部署中的难度。

Floyd等[29]提出的随机早期检测(random early drop, RED) 算法的丢包概率与队列长度呈正向关系。为使丢包率变化更加平稳,RED算法将队列长度做滑动平均处理,并在计算丢包概率时考虑与前一个被丢掉的包的间隔,间隔距离越远表明这个包被丢掉的概率越大。RED算法主要存在2方面限制:一方面,RED算法根据队列长度改变丢包概率,但是无论是网络质量指标还是用户体验质量评估,其都需要关注延迟,而队列长度并不能直接与延迟对应;另一方面,RED算法具有多个参数,调参成本较大,且实际效果难以预测,这也导致RED难以大规模部署。为应对上述问题,Floyd等[30]提出的RED算法的变式ARED(adaptive random early drop)算法中,参数将自适应进行更新,从而降低调参的复杂度。

Wydrowski等[31]提出Green算法,根据队列的出口速率、每条流的RTT以及包大小的关系得到丢包率。

Nichols等[32]提出的CoDel算法直接利用排队延迟决策丢包,涉及的参数较少,其目标是使队列中的包的排队延迟始终在目标值以下。当队列出现排队延迟超过目标值并保持该状态一段时间后,端侧将通过逐渐减小丢包的时间间隔以越来越快速地丢包,直到排队延迟小于目标值。

Pan等[33]提出的PIE算法同样关注排队延迟,采用比例积分控制器将排队延迟的相关函数结果作为更新丢包概率的依据。Feng等[34]提出了BLUE算法,具体思路是在队列超过一定阈值后每隔一段时间为丢包率增加一个固定值,当队列不再排队时再每隔一段时间逐渐减小丢包率。BLUE算法也仅关注队列长度,因此存在一定局限。CoDel算法在后期线性化丢包间隔,丢包力度不足以有效缓解队列堆积,而且当队列在目标值上下浮动时,即使队列并没有完全消除排队,丢包间隔也可能直接变成较大的初始值。Palmei等[35]针对这些CoDel算法设计的问题提出COBALT算法,将CoDel算法与BLUE结合,当队列堆积到一定程度时在CoDel算法丢包的基础上引入BLUE算法的丢包概率,增加丢包数量;当排队缓解后,CoDel算法的丢包间隔逐渐减小,且不会立即恢复到初始值。

AQM算法的发展历程,如表 1所示。AQM算法在设计上仍有多种尝试,AQM算法的可部署性取决于AQM算法参数调整的复杂度以及算法逻辑在交换机路由器实现的难度,一些设计由于缺乏可部署性而无法得到实际应用。

表 1 AQM算法发展历程
算法名称 年份 特点
RED 1993 基于队列长度确定丢包率,存在调整参数的挑战
ARED 2001 自适应性调整参数
Green 2002 根据每条流的RTT属性自适应计算丢包率
BLUE 2002 基于队列长度自动更新丢包率
CoDel 2012 基于排队延迟更新丢包率,在出队列处丢包
PIE 2013 基于排队延迟更新丢包率,在入队列处丢包,轻量级实现
COBALT 2019 结合了CoDel算法与BLUE算法的丢包率计算逻辑,可避免丢包率突然减小

2.2 AQM算法性能对比

Khademi等[36]对部署在Linux中的CoDel、PIE和ARED算法进行了性能测试并使用多种AQM算法参数,比较不同参数和网络环境下3种AQM算法排队延迟的表现。结果表明:随着网络拥塞程度增加,CoDel和PIE算法的排队延迟相应增加,并出现较大的尾部延迟,而且延迟表现并未受到目标延迟参数变化的明显影响。相比而言,ARED算法实现了更低的延迟,尤其是在链路较拥塞时,该算法仍能控制尾部延迟不过多超出目标延迟。ARED、CoDel和PIE算法性能产生差异的原因在于,当瓶颈队列较长时,ARED算法的丢包更多,能够更好地控制队列堆积。针对丢包间隔参数,以CoDel算法为例,若减小默认的丢包间隔,使其丢更多的包,则可以在不损失大量带宽的条件下减小排队延迟。

Muhammad等[37]评估CoDel和RED算法与多种CCA组合的性能效果,并在实验中改变数据包尺寸和瓶颈链路拥塞程度,针对链路利用率、排队延迟、丢包率和重传包数等指标进行评估。结果表明:在大多数实验环境下CoDel算法可以实现更低的延迟及更高的链路利用率,而RED算法的丢包率和重传包数普遍更低。该评估在相对良好的网络状态下进行[36],工作中排队延迟的95分位超过100 ms,而这个评估在链路拥塞时的最大队列延迟仅为15 ms。

综上所述,在大多数网络较拥塞的情况下,ARED算法相较于CoDel算法和PIE算法,能更好地控制队列长度,延迟性能更佳,而CoDel算法和PIE算法的延迟性能又优于RED算法。在链路利用率上,ARED、CoDel和PIE算法的表现较相似,而RED算法不能充分利用带宽,因此表现相较于前3种算法更差。但是上述性能评估结果并不固定,AQM的表现和参数设置有很大关系,参数变化直接影响丢包行为,进而决定具体性能表现。同时,AQM的具体性能也与网络环境及端侧使用的CCA相关,一些AQM在不同网络环境下会呈现明显的性能差异。

3 低延迟CCA与AQM算法的组合

低延迟CCA与AQM算法的目标都是控制排队延迟以获得较低的端到端延迟,这2种算法都可以应用在对延迟有严格要求的低延迟服务中。但是由于二者的研究独立进行,缺乏针对另一种机制对自身算法性能影响的分析,这导致2种算法组合使用之后的性能效果无法保证。此外,低延迟CCA和AQM的算法设计都包含对网络或端侧的一些假设,而这些假设可能与实际情况不符。具体来说,低延迟的CCA假设队列是持续堆积,实际上AQM算法会使队列在开始排队后就主动丢包;AQM算法则假设端侧会对丢包立即做出反应, 但是低延迟CCA并不会将丢包信号作为主要的拥塞信号,甚至一些低延迟CCA对丢包并不敏感。

Al-Saadi等[22]从理论上分析低延迟CCA和AQM的组合效应,得出结论如下:1) AQM和CCA处于网络传输路径的不同位置,控制排队的方式也明显不同,AQM部署在网内,没有直接改变拥塞窗口或发送速率的能力,与之相反,低延迟的CCA在没有网内设备的反馈下可以实现端到端的拥塞控制,这说明二者缺乏互相协同的能力,如图 1所示。2) AQM和CCA的拥塞信号有区别,AQM有效控制队列长度,弱化了低延迟CCA算法的重要拥塞信号,也即延迟的变化,这种弱化使端侧对网络真实状态的估计出现偏差,影响算法的判断和发送速率的决策。最极端的情况是,丢包较多的AQM使延迟的波动减小到被低延迟的CCA忽略的状态,使低延迟的CCA无法调整速率适配网络带宽。

图 1 CCA和AQM算法的协同关系

3.1 不同低延迟CCA与AQM算法组合性能表现

Grazia等[38]将各种CCA与AQM算法进行组合,并测试各种组合的性能表现。其中,CCA包括基于丢包的CCA、基于延迟的CCA以及同时考虑延迟信号的CCA,AQM算法包括FIFO、ARED、CoDel和PIE算法,评估指标包括延迟和带宽。该研究认为从各种CCA与AQM算法的组合性能来看,基于丢包的CCA与提前丢包的AQM算法,如CoDel算法组合,可以大幅降低延迟。ARED和CoDel算法的吞吐性能表现与CCA种类相关,而PIE算法和各种CCA组合的吞吐表现均较为良好,Vegas和CoDel算法的组合相比Vegas和FIFO算法的组合,在相对不太拥塞的链路上几乎不能优化RTT,但可以降低带宽,在比较拥塞的链路上则在降低RTT的同时还可以保持相似的吞吐量。

Piotrowska[39]对不同网络环境下基于丢包的CCA、CompoundTCP算法,以及FIFO、CoDel和PIE算法等进行了性能测试,涉及的指标有延迟、队列长度和公平性等。主要结论包括:从CCA和AQM的组合性能来看,无论拥塞程度或RTT怎样变化,各种CCA和AQM的组合都无法同时实现公平性最优与排队延迟最低。在相对不拥塞的网络中,CoDel与CompoundTCP算法组合可以保持最短的队列并改善流与流之间的公平性。Ha等[40]提出的CUBIC与PIE算法组合则在高速网络和接入链路2种网络环境中展示了相对良好的性能,这是由于该算法组合可以在低延迟的背景下保持相对较高的吞吐。

Carlucci等[41]将GCC与FIFO算法、CoDel与PIE算法分别组合进行性能测试,评估指标为延迟、带宽和丢包。结果表明:GCC和FIFO算法组合,在不拥塞的链路上可以在不丢包的情况下有效控制队列长度;当处于拥塞链路时,则会出现较高延迟。与之相对应,GCC算法、PIE算法和CoDel算法在不拥塞链路上与FIFO的排队延迟相似,但引入了更多的丢包,从应用需求来讲,这不仅不能提升性能,还影响传输质量和用户的体验效果。当处于拥塞链路时,与FIFO相比,PIE和CoDel算法都能够有效地减少排队延迟,但会导致丢包,且丢包的数量随拥塞程度增加而增加。

BBR、Sprout和Copa算法对丢包并不敏感,关于这3种算法与AQM的组合性能测试方面的研究较少,Zhang等[42]发现如果在与使用基于丢包的CCA的竞争流共享的瓶颈中部署AQM,可以提高流与流之间的公平性,但是这个研究的重点在于基于丢包的CCA与AQM的组合性能,而非低延迟CCA本身。在Abbasloo[43]的研究中BBR、Sprout、CoDel或PIE算法组合在延迟和吞吐上的性能大致类似于与FIFO的组合。由此可以推断,这类对丢包不敏感的CCA与提前丢包的AQM组合相比于与FIFO组合在延迟方面的表现相似,但是对于TCP协议而言,AQM引入的丢包会导致重传并带来额外的延迟,而且瓶颈队列丢包率较高可能触发RTO (retransmission time out)。

3.2 不同低延迟CCA与AQM算法组合的原理分析

低延迟的CCA根据对丢包信号的不同响应方式分为对丢包不敏感和敏感2种。对丢包不敏感的CCA在与提前丢包的AQM算法组合时会忽视AQM算法初始反馈的丢包信号,而且AQM在一定程度上控制排队延迟,因此这类CCA接收到的延迟信号偏小,对网络拥塞程度的判断低于实际情况,降速动作反而会更加保守,导致队列继续保持在超过AQM算法阈值的状态下并引起更多丢包。虽然AQM算法可以在一定程度上减小排队延迟,但丢包可能影响用户使用体验。一些CCA对延迟和丢包信号均能给出即时响应。出现网络拥塞时,若队列上升伴随丢包,则在同一个拥塞事件中,CCA会对延迟上升和丢包2种信号做出冗余的反应。

3.3 不同低延迟CCA与AQM算法组合效果

综合在不同测量条件和算法参数下得到的AQM算法与CCA的组合效果不尽相同,但可以确定的是:相同的AQM算法对不同CCA的性能表现有不同的影响。对于基于丢包的CCA来说,使用除FIFO之外的AQM算法可以显著降低延迟。低延迟的CCA与AQM算法组合可以进一步降低延迟,但是降低的幅度以及是否以牺牲带宽为代价是不确定的。AQM与不同CCA组合时,性能也有明显区别。

另一个相对明确的结论是不存在某种AQM算法对所有的CCA来说都是最优的选择,也不存在某种低延迟的CCA可以做到任意AQM算法在与其组合时均可以获得最佳性能。某些AQM算法可能对CCA性能产生负面影响,而且也不存在某一种CCA与AQM算法组合适用于所有的网络环境或在所有性能指标上超越其他组合。低延迟的CCA和AQM算法虽然同为低延迟策略,但是组合使用时其性能可能出现恶化。由于二者都独立存在于网内或者部署在端侧,很难同时控制使其相互配合实现较好的效果。

此外,目前尚缺乏一些全面评估各种CCA和AQM算法组合效果的工作,现有工作大多围绕传统的CCA,而针对各种网络环境中AQM算法和低延迟CCA组合的性能表现仍需更多理论分析和实践探索。

4 CCA与AQM算法协作优化方案

由于CCA和AQM算法存在潜在的不适配问题,为进一步提高二者协调性能,一些研究提出了相关优化工作,主要分为3个方向: 1) 修改端侧的CCA以使其适用于所有AQM算法; 2) 在网内设备中部署对所有CCA都适用的AQM算法; 3) 端网融合,即CCA和AQM算法共同决定发送策略。

4.1 适用于各种AQM算法的CCA

Dong等[44]提出的PCC(performance-oriented congestion control)算法是一种基于学习的CCA,该算法不依靠反馈信息调整发送速率,而是在端侧尝试不同的发送速率后统计对应的网络指标并带入效用函数中,根据效用函数结果选择适合的发送速率。PCC算法通过改变效用函数从而改变其依赖的拥塞信号,避免受到AQM算法的影响。Dong等[28]提出的PCC-Vivace算法同样使用了PCC算法的效用函数框架,但该算法可以进一步改善延迟、吞吐等性能,并同时实现对网络状态变化的快速反应,缩短收敛时间。

Abbasloo等[25]提出的Orca算法有2个决定拥塞窗口的策略,先利用深度强化学习给出一个基础窗口,为防止机器学习的模型在某些环境下决策失误,该算法还会运行传统TCP算法,在根据深度强化学习模型得到的窗口决策的基础上进行微调,然后给出最终的窗口决策。对Orca算法进行全面的性能实验发现,Orca算法与各种常见的AQM算法组合性能均良好,说明其对AQM算法的兼容性较好。

4.2 对各种CCA适用的AQM算法

为使AQM算法适应不同CCA的流,Bachl等[45]提出基于深度学习和强化学习的AQM算法——LFQ(learning fair qdisc)算法,该算法提取每条流的特征用以代表流的拥塞控制机制等属性,运行神经网络得到最适配的缓冲区队列尺寸。评估表明,与设定固定缓冲区大小的普通AQM相比,LFQ可在获得更小队列长度的同时实现更高的吞吐。

为保证不同CCA的流性能均表现良好,Nadas等[46]提出了CSAQM。该仿真结果表明:当使用DCTCP与CUBIC流一起通过部署有CSAQM的瓶颈时,相比于其他AQM算法,CSAQM可以提供更小的排队延迟波动,并缩短2条流的CCA的收敛时间。

Ma等[47]认为难以对CCA和AQM算法共存的多样化系统建模,而且自适应对AQM算法进行调参具有一定挑战,因此提出了DRL-AQM(deep reinforcement learning-active queue management) 算法,使用深度强化学习训练得到可以应对各种网络环境的AQM。DRL-AQM算法可以在路由器处获取队列长度等特征,输出丢包率的决策。实验结果表明:DRL-AQM算法在各种复杂的网络场景中都优于传统的AQM算法,而且能提升不同CCA的性能,表明该学习模式可以使AQM算法更好地与不同CCA配合。

Abbasloo等[43]认为一种AQM算法需要特定的CCA给予支持,为突破这种限制,提出了通用的BoDe算法。BoDe算法的设计比较简单,在队列入口标记数据包的到达时间,在队列出口,若数据包的排队延迟大于某个阈值,则丢掉该数据包。评估模拟了BoDe算法与不同AQM算法的组合,结果表明:在AQM算法为CoDel算法和PIE算法时,BoDe相比于PCC-Vivace算法可以使排队延迟大幅降低,而且这种低延迟并不会使吞吐明显减少。

各种通用算法和技术如表 2所示。这些算法倾向于利用机器学习的技术,然而机器学习具有黑盒的特点,在未知的网络环境中可能做出不适当的决策。

表 2 CCA和AQM算法协作优化方案技术对比
算法名称 涉及技术
Orca 深度强化学习
PCC 根据效用函数在线选择最优决策
LFQ 深度学习和强化学习
CSAQM 传统定义丢包规则
DRL-AQM 深度强化学习
BoDe 传统定义丢包规则

4.3 端网协同方案

除通用的CCA和AQM算法,还有一些优化方案, 如将网内设备主动队列管理机制和端侧的拥塞控制相结合,使CCA和AQM算法作为一个整体以共同对变化的网络环境做出速率决策,也可以避免出现前述不适配的问题。

为解决CCA和AQM算法难以协同优化性能的问题,Bai等[48]提出基于深度强化学习的跨层拥塞控制机制MACC (multi-agent-based congestion control)算法,采用2个agent分别代替CCA和AQM算法,一个agent学习如何决定拥塞窗口的大小,另一个agent学习如何决定入队速率及丢包率。将这2个agent进行联合优化可以获得更好的性能。MACC算法在NS3网络模拟器中实现,在各种网络场景中的评估表明,与各种常见的CCA和AQM算法组合相比,MACC算法不仅可以通过强化学习更好地适应网络环境,还能达到CCA和AQM算法的跨层良好协作。

显式反馈的拥塞控制方案(explicit congestion notification, ECN)也属于跨层优化方案。这类算法的特点是使端侧和网内设备合作实现跨层优化。首先,网内的路由器设备根据其内部的队列长度和链路容量判断网络状态,并将这些信息输入数据包的报头中,端侧接收反馈的网内信息后调整发送速率。端侧可以在短时间内监测网络状态的变化,而且反馈信息更加准确。

Katabi等[49]提出的XCP(explicit control protocol)算法对ECN方案进行了拓展,重新构造了拥塞报头,利用多个字段在端侧和路由器之间传递信息,协助路由器做出合理的反馈并指导端侧适时调整拥塞窗口。XCP的性能测试表明,当XCP的流量受网络状态影响时,仍能保持良好的性能。

Tai等[50]提出的RCP(rate control protocol)算法中路由器直接给出发送速率的建议值,在数据包从发送端到接收端的过程中,链路上的所有路由器根据各自的出口速率和共享流的数量计算端侧合适的发送速率,其中最小值被反馈至发送端。RCP算法需要构造一个12字节的RCP报头。

Xia等[51]提出的VCP (variable-structure congestion control protocol) 算法不需要使用多个字节为端侧提供信息,而需要报头的ECN位传递信息。路由器定期估计负载因子,并据此在ECN位上做3种标记,分别对应网络空闲、高利用状态和拥塞状态,端侧对这3种状态相应地进行窗口乘性增、加性增和乘性减的操作。VCP算法的反馈信息对端侧窗口的改变幅度较小,因此无法快速实时匹配网络状态。

Goyal等[26]提出的ABC(accel-brake contronl)算法是一种简单且可部署的ECN方案。ABC算法中的路由器通过链路容量、排队延迟和当前出队速率计算目标速率和标记比例,以此为依据给每个数据包标记A或B,分别表示端侧相应地增加或减少其拥塞窗口。ABC算法相比于XCP算法不需要使用多位比特或额外的数据包报头字段传递信息,相比于VCP可以更快地适应网络变化。实验结果表明:在各种网络环境的仿真模拟中,ABC算法相比于各种部署在端侧的CCA,可以在不影响延迟表现的前提下实现更高的吞吐或更低的延迟。

4.4 3种方案对比

端侧采用对AQM算法通用的CCA或者网内部署对CCA通用的AQM算法都不需要硬件设备额外支持,因此相对容易实现,也具有一定的可拓展性。但是上述2种方法存在2方面的限制:1) 采用机器学习的方法存在训练鲁棒性的挑战,而且缺少可解释性,尤其是在复杂的实际使用场景中这种方法难以保证应用性能;2) 模型具有复杂性,实际部署成本高。

跨层优化方法的性能在理论上优于独立决策,但是需要网内设备支持。具体来说,传输路径中的多个交换机和路由器均需要接受额外的升级以具备处理报文的能力,这带来了额外的开销。而且,这种联合优化需要端侧的内容提供商和网内的设备制造商共同确定算法的具体要求,鉴于这二者通常由不同的厂商完成,端侧和网内协同优化的想法并不易在实际中实现。

5 结论与展望

对于低延迟应用,众多研究从传输层或网络层的角度提出了优化的算法。受限于测量误差、参数的敏感性,以及理论与真实网络的差距,早期的低延迟CCA面临实际性能不足的问题,后续的CCA算法不断弥补缺点并提升性能,得到了实际部署。AQM算法也通过新的算法设计克服参数过多、难以自适应性调节等问题。尽管低延迟CCA和AQM算法都优化了各自性能,但是同时部署时可能相应地带来不良的后果。此后,一些研究致力于借助机器学习设计通用的CCA和AQM算法,也有一些工作提出端侧和网内设备应协同优化,但是这些方案都面临实际部署的挑战。

对于未来的工作设计,本文建议如下:

1) 提高算法的通用性。无论是在CCA算法还是AQM算法中,都应该减少对参数的依赖,良好的算法应该可以自适应地面对各种网络环境。此外,在独立运行良好的基础上,各种新技术在提出时也应考虑与其他方案的兼容性。

2) 提高算法的实际可部署性。为保证新算法可以在实际中应用,设计者应该尽选择轻量级的模型,避免对原有系统做过多修改。

3) 未来的算法设计可以在联合优化方面多做尝试。由于端到端算法存在测量偏差,网内设备的反馈信号又不一定可以被端侧识别,因此联合跨层优化成为一个可行方案,由网内设备提供准确的网络状态信息,端侧接收信号及时调整带宽,同时,不同的厂商合作制定统一的标准,也将成为未来的一个发展趋势。

参考文献
[1]
LIN X S, MA Y F, ZHANG J S, et al. GSO-simulcast: Global stream orchestration in simulcast video conferencing systems[C]//Proceedings of the ACM SIGCOMM 2022 Conference. Amsterdam, the Netherlands: ACM, 2022: 826-839.
[2]
KARL K A, PELUCHETTE J V, AGH AKHANI N. Virtual work meetings during the COVID-19 pandemic: The good, bad, and ugly[J]. Small Group Research, 2022, 53(3): 343-365. DOI:10.1177/10464964211015286
[3]
KÄMÄRÄINEN T, SIEKKINEN M, YLÄ-JÄÄSKI A, et al. A measurement study on achieving imperceptible latency in mobile cloud gaming[C]//Proceedings of the 8th ACM on Multimedia Systems Conference. Taibei, China: ACM, 2017: 88-99.
[4]
BRAKMO L S, O'MALLEY S W, PETERSON L L. TCP Vegas: New techniques for congestion detection and avoidance[J]. ACM SIGCOMM Computer Communication Review, 1994, 24(4): 24-35. DOI:10.1145/190809.190317
[5]
HENGARTNER U, BOLLIGER J, GROSS T. TCP Vegas revisited[C]//Proceedings IEEE INFOCOM 2000. Tel Aviv, Israel: IEEE, 2000: 1546-1555.
[6]
JIN C, WEI D, LOW S H, et al. FAST TCP: From theory to experiments[J]. IEEE Network, 2005, 19(1): 4-11. DOI:10.1109/MNET.2005.1383434
[7]
ARAMANI A, KOKKU R, DAHLIN M. TCP Nice: A mechanism for background transfers[J]. ACM SIGOPS Operating Systems Review, 2002, 36(SI): 329-343.
[8]
KUEHLEWIND M, HAZEL G, SHALUNOV S, et al. Low extra delay background transport (ledbat)[R/OL]. (2012-12-19)[2023-7-15]. https://www.rfc-editor.org/rfc/rfc6817.
[9]
MENG T, SCHIFF N R, GODFREY P B, et al. PCC proteus: Scavenger transport and beyond[C]//Proceedings of the Annual Conference of the ACM Special Interest Group on Data Communication on the Applications, Technologies, Architectures, and Protocols for Computer Communication. New York, USA: ACM, 2020: 615-631.
[10]
ZAKI Y, PÖTSCH T, CHEN J, et al. Adaptive congestion control for unpredictable cellular networks[C]//Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication. London, UK: ACM, 2015: 509-522.
[11]
ABBASLOO S, XU Y, CHAO H J. C2TCP: A flexible cellular TCP to meet stringent delay requirements[J]. IEEE Journal on Selected Areas in Communications, 2019, 37(4): 918-932. DOI:10.1109/JSAC.2019.2898758
[12]
ARUN V, BALAKRISHNAN H. Copa: Practical delay-based congestion control for the internet[C]//15th USENIX Symposium on Networked Systems Design and Implementation (NSDI 18). Renton, USA: USENIX Association, 2018: 329-342.
[13]
LIU S, BAȘAR T, SRIKANT R. TCP-Illinois: A loss and delay-based congestion control algorithm for high-speed networks[C]//Proceedings of the 1st International Conference on Performance Evaluation Methodolgies and Tools. Pisa, Italy: ACM, 2006: 55-es.
[14]
TAN K, SONG J, ZHANG Q, et al. A compound TCP approach for high-speed and long distance networks[C]//Proceedings of the 25th IEEE International Conference on Computer Communications. Barcelona, Spain: IEEE, 2006: 1-12.
[15]
CARLUCCI G, DE CICCO L, HOLMER S, et al. Congestion control for web real-time communication[J]. IEEE/ACM Transactions on Networking, 2017, 25(5): 2629-2642. DOI:10.1109/TNET.2017.2703615
[16]
ZHU X Q, PAN R. NADA: A unified congestion control scheme for low-latency interactive video[C]//2013 20th International Packet Video Workshop. San Jose, USA: IEEE, 2013: 1-8.
[17]
JOHANSSON I. Self-clocked rate adaptation for conversational video in LTE[C]//Proceedings of the 2014 ACM SIGCOMM Workshop on Capacity Sharing Workshop. Chicago, USA: ACM, 2014: 51-56.
[18]
CARDWELL N, CHENG Y C, GUNN C S, et al. BBR: Congestion-based congestion control: Measuring bottleneck bandwidth and round-trip propagation time[J]. Queue, 2016, 14(5): 20-53. DOI:10.1145/3012426.3022184
[19]
HOCK M, BLESS R, ZITTERBART M. Experimental evaluation of BBR congestion control[C]//2017 IEEE 25th International Conference on Network Protocols (ICNP). Toronto, Canada: IEEE, 2017: 1-10.
[20]
WINSTEIN K, SIVARAMAN A, BALAKRISHNAN H. Stochastic forecasts achieve high throughput and low delay over cellular networks[C]//10th USENIX Symposium on Networked Systems Design and Implementation. Lombard, USA: USENIX Association, 2013: 459-472.
[21]
POLESE M, CHIARIOTTI F, BONETTO E, et al. A survey on recent advances in transport layer protocols[J]. IEEE Communications Surveys & Tutorials, 2019, 21(4): 3584-3608.
[22]
AL-SAADI R, ARMITAGE G, BUT J, et al. A survey of delay-based and hybrid TCP congestion control algorithms[J]. IEEE Communications Surveys & Tutorials, 2019, 21(4): 3609-3638.
[23]
HAILE H, GRINNEMO K J, FERLIN S, et al. End-to-end congestion control approaches for high throughput and low delay in 4G/5G cellular networks[J]. Computer Networks, 2021, 186: 107692. DOI:10.1016/j.comnet.2020.107692
[24]
LORINCZ J, KLARIN Z, OŹEGOVIĆ J. A comprehensive overview of TCP congestion control in 5G networks: Research challenges and future perspectives[J]. Sensors, 2021, 21(13): 4510. DOI:10.3390/s21134510
[25]
ABBASLOO S, YEN C Y, CHAO H J. Classic meets modern: A pragmatic learning-based congestion control for the internet[C]//Proceedings of the Annual Conference of the ACM Special Interest Group on Data Communication on the Applications, Technologies, Architectures, and Protocols for Computer Communication. New York, USA: ACM, 2020: 632-647.
[26]
GOYAL P, AGARWAL A, NETRAVALI R, et al. ABC: A simple explicit congestion controller for wireless networks[C]//17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 20). Santa Clara, USA: USENIX Association, 2020: 353-372.
[27]
DU Z, ZHENG J, YU H, et al. A unified congestion control framework for diverse application preferences and network conditions[C]//Proceedings of the 17th International Conference on emerging Networking Experiments and Technologies. New York, USA: ACM, 2021: 282-296.
[28]
DONG M, MENG T, ZARCHY D, et al. PCC vivace: Online-learning congestion control[C]//15th USENIX Symposium on Networked Systems Design and Implementation (NSDI 18). Renton, USA: USENIX Assosiation, 2018: 343-356.
[29]
FLOYD S, JACOBSON V. Random early detection gateways for congestion avoidance[J]. IEEE/ACM Transactions on Networking, 1993, 1(4): 397-413. DOI:10.1109/90.251892
[30]
FLOYD S, GUMMADI R, SHENKER S J. Adaptive RED: An algorithm for increasing the robustness of RED's active queue management[R]. Berkeley, USA: International Computer Science Institute, 2001.
[31]
WYDROWSKI B, ZUKERMAN M. GREEN: An active queue management algorithm for a self managed internet[C]//2002 IEEE International Conference on Communications. Conference Proceedings. New York, USA: IEEE, 2002: 2368-2372.
[32]
NICHOLS K, JACOBSON V. Controlling queue delay[J]. Communications of the ACM, 2012, 55(7): 42-50. DOI:10.1145/2209249.2209264
[33]
PAN R, NATARAJAN P, PIGLIONE C, et al. PIE: A lightweight control scheme to address the bufferbloat problem[C]//2013 IEEE 14th International Conference on High Performance Switching and Routing (HPSR). Taipei, China: IEEE, 2013: 148-155.
[34]
FENG W C, SHIN K G, KANDLUR D D, et al. The BLUE active queue management algorithms[J]. IEEE/ACM Transactions on Networking, 2002, 10(4): 513-528. DOI:10.1109/TNET.2002.801399
[35]
PALMEI J, GUPTA S, IMPUTATO P, et al. Design and evaluation of COBALT queue discipline[C]//2019 IEEE International Symposium on Local and Metropolitan Area Networks (LANMAN). Paris, France: IEEE, 2019: 1-6.
[36]
KHADEMI N, ROS D, WELZL M. The new AQM kids on the block: An experimental evaluation of CoDel and PIE[C]//2014 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS). Toronto, Canada: IEEE, 2014: 85-90.
[37]
MUHAMMAD S, CHAUDHERY T J, NOH Y. Study on performance of AQM schemes over TCP variants in different network environments[J]. IET Communications, 2021, 15(1): 93-111. DOI:10.1049/cmu2.12061
[38]
GRAZIA C A, PATRICIELLO N, KLAPEZ M, et al. A cross-comparison between TCP and AQM algorithms: Which is the best couple for congestion control?[C]//2017 14th International Conference on Telecommunications (ConTEL). Zagreb, Croatia: IEEE, 2017: 75-82.
[39]
PIOTROWSKA A. On cross-layer interactions for congestion control in the internet[J]. Applied Sciences, 2021, 11(17): 7808. DOI:10.3390/app11177808
[40]
HA S, RHEE I, XU L S. CUBIC: A new TCP-friendly high-speed TCP variant[J]. ACM SIGOPS Operating Systems Review, 2008, 42(5): 64-74. DOI:10.1145/1400097.1400105
[41]
CARLUCCI G, DE CICCO L, MASCOLO S. Controlling queuing delays for real-time communication: The interplay of E2E and AQM algorithms[J]. ACM SIGCOMM Computer Communication Review, 2016, 46(3): 1.
[42]
ZHANG H, ZHU H T, XIA Y, et al. Performance analysis of BBR congestion control protocol based on NS3[C]//2019 Seventh International Conference on Advanced Cloud and Big Data (CBD). Suzhou, China: IEEE, 2019: 363-368.
[43]
ABBASLOO S, CHAO H J. Bounding queue delay in cellular networks to support ultra-low latency applications[J/OL]. arXiv. (2019-08-02)[2023-07-15]. https://arxiv.org/pdf/1908.00953.pdf.
[44]
DONG M, LI Q X, ZARCHY D, et al. PCC: Re-architecting congestion control for consistent high performance[C]//12th USENIX Symposium on Networked Systems Design and Implementation (NSDI 15). Oakland, USA: USENIX Association, 2015: 395-408.
[45]
BACHL M, FABINI J, ZSEBY T. LFQ: Online learning of per-flow queuing policies using deep reinforcement learning[C]//2020 IEEE 45th Conference on Local Computer Networks (LCN). Sydney, Australia: IEEE, 2020: 417-420.
[46]
NÁDAS S, GOMBOS G, HUDOBA P, et al. Towards a congestion control-independent core-stateless AQM[C]//Proceedings of the Applied Networking Research Workshop. Montreal, Canada: ACM, 2018: 84-90.
[47]
MA H H, XU D, DAI Y Y, et al. An intelligent scheme for congestion control: When active queue management meets deep reinforcement learning[J]. Computer Networks, 2021, 200: 108515. DOI:10.1016/j.comnet.2021.108515
[48]
BAI J N, ZHANG T H, XIE G M. MACC: Cross-layer multi-agent congestion control with deep reinforcement learning[J/OL]. arXiv. (2022-06-04)[2023-07-15]. https://arxiv.org/pdf/2206.01972.pdf.
[49]
KATABI D, HANDLEY M, ROHRS C. Congestion control for high bandwidth-delay product networks[J]. ACM SIGCOMM Computer Communication Review, 2002, 32(4): 89-102. DOI:10.1145/964725.633035
[50]
TAI C H, ZHU J, DUKKIPATI N. Making large scale deployment of RCP practical for real networks[C]//IEEE INFOCOM 2008—The 27th Conference on Computer Communications. Phoenix, USA: IEEE, 2008: 2180-2188.
[51]
XIA Y, SUBRAMANIAN L, STOICA I, et al. One more bit is enough[C]//Proceedings of the 2005 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications. Philadelphia, USA: ACM, 2005: 37-48.