用于可靠传输协议的速率更新引擎

摘要

本公开涉及用于可靠传输协议的速率更新引擎。一种系统包括被配置为分析通过通信协议系统所接收的分组并且根据该数据分组的分析确定一个或多个拥塞指示符的第一处理器，该一个或多个拥塞指示符指示通过该通信协议系统的可靠传输协议层所传送的数据分组的网络拥塞。该系统还包括速率更新引擎，其与分组数据路径分离并且被配置为操作第二处理器接收所确定的一个或多个拥塞指示符，基于所接收的一个或多个拥塞指示符确定用于控制数据分组的传输的一个或多个拥塞控制参数并且输出基于所确定的一个或多个拥塞控制参数的拥塞控制结果。

说明书

技术领域

本公开涉及用于可靠传输协议的速率更新引擎。

背景技术

互联网协议组是用于为通过互联网或其它计算机网络传达信息的两个设备之间的数据传输服务的通信协议的集合。传输控制协议(“TCP”)是例如通过局域网或广域网在客户端设备上运行的web浏览器应用和在服务器设备上运行的web服务器应用之间提供面向连接、可靠且有序的数据分组流传递的互联网协议组的一部分。目前，使用诸如TCP的通信协议的数据中心遇到了某些问题。例如，聚播(incast)是一种通常在数据中心中发现的多对一通信模式，其在多个同步计算设备并行地向相同的接收器计算设备发送数据时可能导致聚播拥塞。

发明内容

本公开提供了一种可编程的拥塞控制引擎，其可以被用来实施各种拥塞控制例程以便避免或缓解通信网络的远程节点处的聚播拥塞，所述远程节点诸如接收器计算设备。该拥塞控制引擎从远程节点采集信息以监视拥塞，并且因此可以使用速率更新引擎(RUE)更新到远程节点的分组传输的速率。该RUE可以与分组数据路径分离。这将执行拥塞控制所需的处理卸载到具有充分处理能力的硬件或软件，并且进一步允许可以使用的一种或多种拥塞控制算法的类型的灵活性。

本公开的一个方面针对一种拥塞控制系统，包括通信网络中的第一节点的一个或多个第一处理器，其中该一个或多个第一处理器通信耦合至用于使用可靠传输协议接收数据分组的该通信网络的分组数据路径并且被配置为分析从第二节点所接收的分组并且根据对该数据分组的分析确定一个或多个拥塞指示符，该一个或多个拥塞指示符指示通过可靠传输协议层向该第二节点传送的数据分组的网络拥塞，以及与该分组数据路径分离的速率更新引擎，其中该速率更新引擎被配置为操作一个或多个第二处理器以接收所确定的一个或多个拥塞指示符，基于所接收的一个或多个拥塞指示符确定用于控制数据分组通过该通信网络到该第二节点的传输的一个或多个拥塞控制参数，并且输出基于所确定的一个或多个拥塞控制参数的拥塞控制结果。

在一些示例中，该一个或多个第一处理器可以被配置为响应于分组传输事件的发生而将所确定的一个或多个拥塞指示符提供至该一个或多个第二处理器。该分组传输事件可以是确认消息、非确认消息或分组重传之一。

在一些示例中，该一个或多个拥塞指示符可以包括针对向该第二节点传送的数据分组的以下至少一项：拥塞窗口、重传超时、往返延迟、第二节点所确认的分组数量、重传数量或所接收的明确拥塞通知的数量。

在一些示例中，该速率更新引擎可以包括专用硬件引擎。该速率更新引擎、一个或多个第一处理器和一个或多个第二处理器可以被包括在相同的硬件组件中。

在一些示例中，该速率更新引擎可以包括存储指令的存储器。该存储器可以进一步包括被配置为对从该一个或多个第一处理器提供的输入数据进行排队的第一队列，以及被配置为对提供至该一个或多个第一处理器的输出数据进行排队的第二队列。该第一队列可以是具有第一头部指针和第一尾部指针的第一环形缓冲器。该第二队列可以是具有第二头部指针和第二尾部指针的第二环形缓冲器。该一个或多个第一处理器可以被配置为根据该第一尾部指针将速率更新请求推送至该第一环形缓冲器，并且根据该第二头部指针从该第二环形缓冲器读出速率更新请求。针对每个速率更新请求，该一个或多个第一处理器可以被配置为基于自前一个速率更新请求起的时间量是否超过预定延时阈值或者针对被传送至第二节点的数据分组所接收到的ACK分组的数量是否超过预定吞吐量阈值中的至少一个而确定是否将速率更新请求推送至该第一环形缓冲器。该一个或多个第一处理器可以被配置为确定在该第一环形缓冲器中排队的速率更新请求的当时数量，如果在该第一环形缓冲器中排队的速率更新请求的当时数量小于第一阈值量，则将速率更新请求推送该第一环形缓冲器，如果在该第一环形缓冲器中排队的速率更新请求的当时数量大于第一阈值量且小于第二阈值量，自前一个速率更新请求起的时间量并未超过预定延时阈值，并且针对被传送至第二节点的数据分组所接收到的ACK分组的数量未超过预定吞吐量阈值，则避免该速率更新请求被推送至该第一环形缓冲器，如果在该第一环形缓冲器中排队的速率更新请求的当时数量大于第二阈值量且小于第三阈值量，自前一个速率更新请求起的时间量未超过预定延时阈值，则避免该速率更新请求被推送该第一环形缓冲器，并且如果在该第一环形缓冲器中排队的速率更新请求的当时数量大于第三阈值量、且以下两个条件中的至少一个也被满足：(i)自前一个速率更新请求起的时间量未超过预定延时阈值、以及(ii)针对被传送至第二节点的数据分组所接收到的ACK分组的数量未超过预定吞吐量阈值，则避免该速率更新请求被推送至该第一环形缓冲器。

本公开的另一个方面针对一种方法，包括：由通信协议系统中的第一节点的一个或多个处理器分析通过分组数据路径从第二节点所接收的数据分组；由该一个或多个处理器根据该数据分组的分析确定一个或多个拥塞指示符，其中该一个或多个拥塞指示符指示针对通过该通信协议系统的可靠传输协议层向该第二节点传送的数据分组的网络拥塞；由该一个或多个处理器将所确定的一个或多个拥塞指示符传送至与该分组数据路径分离的速率更新引擎；由该一个或多个处理器从该速率更新引擎接收基于所确定的一个或多个拥塞控制参数的拥塞控制结果；并且由该一个或多个处理器基于该拥塞控制结果控制数据分组到该第二节点的传输。

在一些示例中，该方法可以进一步包括由该一个或多个处理器响应于接收到确认消息、接收到非确认消息或重传分组而生成速率更新请求。该方法可以进一步包括由该一个或多个处理器将该速率更新请求和与该速率更新请求相关联的拥塞指示符传送至邮箱机制的第一队列，并且由该一个或多个处理器从该邮箱机制的第二队列获得该拥塞控制结果。该方法可以进一步包括至少部分基于该第一队列的可用剩余容量限制向该第一队列传送的所生成的速率更新请求的数量。

在一些示例中，限制所生成的速率更新请求的数量可以涉及由该一个或多个处理器访问该第一队列的可用剩余容量，如果该第一队列的可用剩余容量小于第一阈值量，则由该一个或多个处理器将该速率更新请求和与该速率更新请求相关联的拥塞指示符传送至该第一队列，如果该第一队列的可用剩余容量大于或等于第一阈值量，则由该一个或多个处理器确定自最近速率更新起已流逝的时间量，如果自最近速率更新起已流逝的时间量大于预定延时阈值，则由该一个或多个处理器将该速率更新请求和与该速率更新请求相关联的拥塞指示符传送至该第一队列，并且如果自最近速率更新起已流逝的时间量小于或等于预定延时阈值，则由该一个或多个处理器避免向该第一队列传送速率更新请求，由此限制向该第一队列传送的速率更新请求的数量。

在一些示例中，限制所生成的速率更新请求的数量可以涉及由该一个或多个处理器访问该第一队列的可用剩余容量，如果该第一队列的可用剩余容量小于第一阈值量，则由该一个或多个处理器将该速率更新请求和与该速率更新请求相关联的拥塞指示符传送至该第一队列，并且如果该第一队列的可用剩余容量大于或等于第一阈值量，则由该一个或多个处理器确定针对被传送至第二节点的数据分组所接收到的ACK分组的数量，如果所接收到的ACK分组的数量大于预定吞吐量阈值，则由该一个或多个处理器将该速率更新请求和与该速率更新请求相关联的拥塞指示符传送至该第一队列，并且如果所接收到的ACK分组的数量小于或等于预定吞吐量阈值，则由该一个或多个处理器避免向该第一队列传送速率更新请求，由此限制向该第一队列传送的速率更新请求的数量。

在一些示例中，限制所生成的速率更新请求的数量可以涉及由该一个或多个处理器访问该第一队列的可用剩余容量，如果该第一队列的可用剩余容量小于第一阈值量，则由该一个或多个处理器将该速率更新请求和与该速率更新请求相关联的拥塞指示符传送至该第一队列，如果该第一队列的可用剩余容量大于或等于第一阈值量，则由该一个或多个处理器确定自最近速率更新起已流逝的时间量以及针对被传送至第二节点的数据分组所接收到的ACK分组的数量，如果该第一队列的可用剩余容量大于第一阈值量且小于第二阈值量，则如果自最近速率更新起已流逝的时间量大于预定延时阈值或者所接收到的ACK分组的数量大于预定吞吐量阈值中的至少一个，则由该一个或多个处理器将该速率更新请求和与该速率更新请求相关联的拥塞指示符传送至该第一队列，并且如果自最近速率更新起已流逝的时间量小于或等于预定延时阈值且所接收到的ACK分组的数量小于或等于预定吞吐量阈值，则由该一个或多个处理器避免向该第一队列传送速率更新请求，由此限制向该第一队列传送的速率更新请求的数量，如果该第一队列的可用剩余容量大于第二阈值量且小于第三阈值量，则如果自最近速率更新起已流逝的时间量大于预定延时阈值，则由该一个或多个处理器将该速率更新请求和与该速率更新请求相关联的拥塞指示符传送至该第一队列，并且如果自最近速率更新起已流逝的时间量小于或等于预定延时阈值，则由该一个或多个处理器避免向该第一队列传送速率更新请求，由此限制向该第一队列传送的速率更新请求的数量，并且如果该第一队列的可用剩余容量大于第三阈值量，则如果自最近速率更新起已流逝的时间量大于预定延时阈值且所接收到的ACK分组的数量大于预定吞吐量阈值，则由该一个或多个处理器将该速率更新请求和与该速率更新请求相关联的拥塞指示符传送至该第一队列；并且如果自最近速率更新起已流逝的时间量小于或等于预定延时阈值或者所接收到的ACK分组的数量小于或等于预定吞吐量阈值中的至少一个，则由该一个或多个处理器避免向该第一队列传送速率更新请求，由此限制向该第一队列传送的速率更新请求的数量。

在一些方面，该方法可以进一步包括由被该速率更新引擎所控制的一个或多个第二处理器从该第一队列接收该速率更新请求和与该速率更新请求相关联的拥塞指示符，由该一个或多个第二处理器基于所接收的一个或多个拥塞指示符确定用于控制数据分组到该第二节点的传输的一个或多个控制参数，并且由该一个或多个第二处理器将基于所确定的一个或多个拥塞控制参数的拥塞控制结果输出至该第二队列。

本公开的又一个方面针对一种具有存储于其上的指令的非瞬态计算机可读介质，所述指令用于控制通信协议系统中的第一节点的一个或多个处理器执行以下步骤：分析通过分组数据路径从第二节点所接收的数据分组；根据对该数据分组的分析确定一个或多个拥塞指示符，其中该一个或多个拥塞指示符指示通过该通信协议系统的可靠传输协议层向该第二节点传送的数据分组的网络拥塞；将所确定的一个或多个拥塞指示符传送至与该分组数据路径分离的速率更新引擎；从该速率更新引擎接收基于所确定的一个或多个拥塞控制参数的拥塞控制结果；并且基于该拥塞控制结果控制数据分组到该第二节点的传输。

附图说明

图1是根据本公开的方面的示例通信网络的框图。

图2是根据本公开的方面的示例系统的框图。

图3是图2的系统的一种示例实施方式的框图。

图4是图3的示例系统中所包括的示例计算设备的框图。

图5是图2的系统的另一种示例实施方式的框图。

图6是图5的示例系统中所包括的示例存储器的示图。

图7是图5的示例系统所执行的示例协议的图形描绘。

图8是根据本公开的方面的示例速率更新例程的流程图。

图9是根据本公开的方面的示例速率更新请求子例程的流程图。

具体实施方式

该技术总体上涉及与通信协议系统的可靠传输协议(RTP)层的主要数据路径分离地实施针对该RTP层的拥塞控制。该主要数据路径可以包括一个或多个第一处理器，用于分析到来分组并且确定何时发起速率更新事件。该第一处理器可以向速率更新引擎发送速率更新请求，所述速率更新引擎控制定位于该主要数据路径之外的一个或多个第二处理器。该第二处理器可以执行速率更新算法以便确定用于拥塞控制的控制参数。该第二处理器随后可以将该控制参数提供回该第一处理器以便在该主要数据路径实施拥塞控制。

速率更新请求可以被诸如ACK分组、NACK分组或分组重传之类的硬件事件触发。这些事件中的任一个可以指示经由RTP层接收数据分组的远程节点处的拥塞条件的变化，其进而可以保证针对传送节点处的拥塞控制的更新。

该速率更新算法的执行可以由专用硬件或者由软件模块在该主要数据路径之外实行。在专用硬件的示例中，该第二处理器可以被包括在作为用于在通信协议系统中实施RTP的硬件的一部分的专用硬件引擎中，其例如包括数据路径节点硬件。

在软件模块的示例中，该软件模块可以包括用于在一个或多个第二处理器处实施拥塞控制算法的指令。可以使用一对环形缓冲器对在主要数据路径的速率更新调度器和离线的基于软件的速率更新引擎之间往来的数据进行排队。

在使用环形缓冲器对从主要数据路径送往离线速率更新引擎的数据进行排队的示例中，可以使用速率限制器来控制被推送至该离线速率更新引擎的速率更新请求的数量。限制速率更新请求的数量在速率更新引擎以软件实施的那些示例中可能是特别有利的，这是因为软件在能够处理的拥塞控制事件的数量方面可能受到比专用硬件更多的限制。该速率限制器可以分析环形缓冲器的剩余容量以及增加速率更新请求的重要性，并且可以基于该信息来确定是否将速率更新请求推送到该环形缓冲器。速率更新请求的重要性可以根据事件的延时、所传送数据分组的吞吐量或者它们的组合来衡量。

以上实施方式可以将处理步骤从主要数据路径卸载到单独的离线位置，同时同样提供鲁棒的拥塞控制。此外，拥塞控制的离线实施方式是灵活的，原因在于所提出的架构并不局限于任何特定类型的拥塞控制或速率更新算法。此外，主要数据路径和离线引擎之间的突发和临时反向压力可以使用速率限制器而被吸收从而确保主要数据路径并不失速。

图1图示了包括一个或多个节点的示例通信网络100。该节点可以表示经由网络连接互相连接的各种计算设备。在图1的示例中，第一节点110和第二节点120被示为经由网络130被连接。

节点110、120中的每一个都可以包括相应处理器112、122、存储器114、124以及用于接收输入并传送输出的通信设备116、126。

处理器112、122可以是公知处理器或者其它不太公知的处理器类型。可替换地，处理器112、122可以是诸如ASIC的专用控制器。

存储器114、124可以存储能够由处理器112、122所访问的信息，包括能够由处理器取得、操控或存储的数据，可以由处理器执行的指令，或者它们的组合。存储器114、124可以是能够存储可由处理器110、120访问的信息的非瞬时计算机可读介质的类型，诸如硬盘驱动器、固态驱动器、带式驱动器、光学存储、存储卡、ROM、RAM、DVD、CD-ROM、可写入和只读存储器。

虽然图1在功能上将每个节点的处理器112、122和对应存储器114、124图示为被包括在单个框之内，但是处理器和存储器实际上可以包括可能或无法被存放在相同物理外壳内的多个处理器和存储器。例如，一些数据和指令可以被存储在可移除的CD-ROM上，而其它则被存储在只读计算机芯片内。一些或所有的指令和数据可以被存储在物理上远离处理器但是仍然能够被其访问的位置。类似地，该处理器实际上可以包括处理器的集合，它们可能或无法并行操作。

该通信网络的每个节点的通信设备116、126可以促成节点与和该节点通信的其它远程设备之间的通信。该远程设备可以包括通信网络100的其它节点，与该节点通信的一个或多个用户设备，或者它们的任意组合。通信设备116、126可能能够往来于诸如调制解调器(例如，拨号、线缆或光纤)和无线接口的其它计算机传送数据。例如，每个节点可以经由网络连接130(诸如通过互联网、广域网、企业内部网、虚拟私人网络、广域网、本地网络、使用一个或多个公司所专有的通信协议的私人网络、以太网、WiFi(例如，702.71、702.71b,g,n或者其它这样的标准)，和RPC、HTTP，以及上述的各种组合)接收通信。

通信网络100的节点110、120之间的网络连接130可以支持由该节点的相应处理器112、122所实施的通信协议的多个层级。例如，每个节点可以支持使用上层协议(ULP)和可靠传输协议(RTP)的通信。

ULP可以在任何数量的硬件或软件设备上实施，诸如远程直接存储器访问(RDMA)或非易失性存储器标准(Non-Volatile Memory Express，NVMe)，并且可以负责实施硬件/软件接口、消息的处理、完成通知、端对端流程控制，或者以上的任意组合。RTP可以被用来跟踪目标节点处的数据分组的接收。例如，对于使用RTP被推送至目标节点的数据分组，该目标节点可以发送确认消息(ACK)以确认该数据分组的收到和放置。收到可以通过网络连接130来传递，诸如通过使用ULP或RTP。在其它实例中，目标节点可以发送否定确认(NACK)以指示该目标节点并未准备接收数据分组，并且传送节点应当在稍后时间尝试再次发送该数据分组。在接收到NACK的情况下，传送节点可以在稍后时间尝试该数据分组的重传。可以通过网络100在每个层级的相对应协议之间形成对等连接。此外，在每个节点之内，每个节点的ULP可以被配置为与其它节点的RTP进行通信。

除其它因素之外，ACK和NACK信号可以指示远程节点处是否存在拥塞，诸如是否有过多的分组在过短的时段内从一个或多个传送节点被传送至远程节点。为了解决拥塞，传送节点可以调节向目标节点传送数据分组的速率。

图2是用于在诸如图1的通信网络100的通信网络内进行拥塞控制的系统200的框图。图2的系统200可以被包括在通信网络的第一节点(诸如图1的节点A 110)中，并且可以被配置为通过从通信网络的第二节点(诸如图1的节点B 120)收集信息并且基于所收集的信息更新到该第二节点的分组传输的速率来控制该第二节点处的拥塞。

主要数据路径201被配置为在第一节点和第二节点之间双向传送数据。在第一节点，传入分组流202可以沿主要数据路径201被接收并且被临时存储在第一节点的存储器处，所述存储器在图2中被表示为数据缓存210。传出分组流204可以由第一节点的通信设备沿主要数据路径201传送，所述通信设备在图2中被表示为传送器220。

通过传入分组流202从第二节点接收并且被存储在数据缓存210的数据分组可以被分析以确定到第二节点的分组传输的速率是否应当被更新。该分析可以被划分为两个不同阶段。在第一阶段，确定是否发起速率更新事件。该第一阶段可以使用包括在第一节点的硬件中并且通信耦合至主要数据路径201的一个或多个计算设备230来实施。在第二阶段，响应于速率更新事件的发起而确定用于数据分组传输的经更新参数。该第二阶段可以使用与主要数据路径201分离的速率更新引擎204来实施。例如，来自传入分组流201的数据可以独立于数据缓存210被存储，并且速率更新引擎240可以分析该单独存储的数据以便确定用于数据分组传输的经更新参数。在这两个阶段之间分离拥塞控制过程有助于从主要数据路径卸载处理，并且因此避免主要数据路径上的拥塞。卸载该拥塞控制过程的其它优势包括定义拥塞控制算法时的灵活度有所提高，以及在至少一些示例中，控制是否发起速率更新事件时的灵活度有所提高。在本文更详细地描述该两阶段的拥塞控制过程的这些和其它方面。

图3是图2的系统200的第一示例实施方式的框图。在图3的示例实施方式中，图2的缓存210和传送器220被简化成称为“传送/缓存/接收”310的单个框。框310可以包括与图2中的缓存210和传送器220的框相当的功能，并且可以通过主要数据路径301传送和接收传入数据分组流302和传出数据分组流304。在一些示例中，框310可以是能够管理并跟踪拥塞指示符以便在各种拥塞控制算法中使用的连接场境缓存(connection context cache)。

在图3中，第一节点的硬件由虚线框320所表示。如能够从图3看到的，该拥塞控制系统的第一阶段和第二阶段中的每一个被包括在第一节点的硬件中。例如，速率更新引擎340可以是使用第一节点的处理器所执行并且具有在第一节点的存储器处编程的指令的硬件引擎。在该示例中，通过主要数据路径301所接收的数据可以被存储在框310的缓存中，所述缓存可以是连接场境缓存。第一阶段的一个或多个计算设备330可以分析所存储的数据，并且可以响应于该分析而触发速率更新引擎340。速率更新引擎340随后可以发起速率更新事件以便与在主要数据路径301处执行的处理分离地进行拥塞控制分析。该拥塞控制分析的结果随后可以从速率更新引擎340馈送到框310以便实施针对数据分组传输的经更新参数。

图4是第一节点的硬件中所包括的示例计算设备的框图，其可以被配置为实施图3的拥塞控制系统300。在图4的示例中，第一阶段的计算设备330可以包括一个或多个处理器410、存储器420、以及用于与第一节点的硬件中所包括的诸如速率更新引擎340的其它组件以及第一节点外部的组件接收和传送数据的输入/输出组件450。而且，在图4的示例中，第二阶段的速率更新引擎可以包括一个或多个处理器460、存储器470、以及与用于与第一节点的硬件中所包括的诸如第一阶段的计算设备330的其它组件以及第一节点外部的组件接收和传送数据的输入/输出组件490。虽然框330和340的处理器和存储器被示为是完全互相分离的，但是在一些示例中，这两个框可以共享一些或全部的处理器、一些或全部的存储器，或者它们的任何组合。

第一阶段的存储器420可以包括指令424，并且可以进一步包括处理器410能够依据指令424而取得、存储或修改的数据422。例如，虽然系统和方法并不被特定数据结构所限制，但是数据422可以存储在计算机寄存器中，作为具有多个不同字段和记录的结构被存储在数据存储中，或者被存储在文档或缓冲器中。数据422还可以以计算机可读格式被格式化，所述格式诸如但并不局限于二进制数值、ASCII或Unicode。此外，数据422可以包括足以识别相关信息的信息，所述信息诸如编号、描述文本、属性代码、指针、对存储在其它存储器中的数据的引用，包括其它网络位置，或者被函数用来计算相关数据的信息。

指令424可以是被处理器410直接执行的指令集——诸如机器代码，或者是被处理器410间接执行的指令集——诸如脚本。就此而言，术语“指令”、“步骤”和“程序”在本文能够被可互换地使用。指令424可以以目标代码格式被存储以便由处理器410直接处理，或者以其它类型的计算机语言来存储，包括脚本或者按照要求被解释或者事先被编译的独立源代码模块的集合。

第二阶段的存储器470也可以包括数据472和指令474。数据472和指令474可以依据结合第一阶段的存储器420的数据和指令所描述的示例进行操作。

第一阶段330的处理器410可以能够从数据422访问分组传输数据432。分组传输数据432可以指示第二节点针对经由RTP层从第一节点传送至第二节点的数据分组的响应。例如，分组传输数据432可以指示是否从第二节点接收ACK分组或NACK分组。

第一阶段330的处理器410也可以能够从数据422访问拥塞控制设置434。拥塞控制设置434可以是用于控制第一节点和远程第二节点之间的数据传输的一个或多个参数，以便避免或缓解第二节点处的拥塞。一个示例参数可以是用于限制每往返时间(RTT)在第一和第二节点之间传送的分组数量的分组间间隙。例如，当第二节点被确定为正在经历聚播拥塞时，如经由RTP层被传送至第二节点的未解决分组的总数所指示，则该分组间间隙可以被减少为小于每个RTT1个分组。另一个示例参数可以是从第二节点所接收的明确拥塞通知(ECN)。该ECN可以指示在第二节点处存在拥塞，而并不丢弃第一节点所传送的分组。另一个示例参数可以是拥塞窗口大小，其可以被用来控制以RTT测量的每个连接的未解决分组的总数。另一个示例参数可以是重传超时(RTO)，这是第一节点在并未响应于分组的初始传输从第二节点接收到ACK的情况下经由RTP层向第二节点再次传送该分组之前等待的时间量。

指令424可以包括用于指示第一阶段的处理器410依据本文所描述的例程执行操作的各种算法。例如，指令424可以包括用于经由RTP层从第一节点向第二节点发送分组的分组传输例程442。针对另外的示例，指令424可以包括用于基于经由主要数据路径所接收的数据——诸如分组传输数据432——并且可能结合当前拥塞控制设置434而评估第二节点处的拥塞的拥塞指示符确定例程444。针对另外的示例，指令424可以包括用于触发速率更新引擎以发起速率更新事件的速率更新请求例程446。针对另外的示例，指令424可以包括用于基于向速率更新引擎发送速率更新请求的数据缓冲器中的剩余可用空间而确定队列是否接收到针对速率更新请求的数据的请求限制器例程448。

第二阶段340的处理器460可以能够从数据472访问拥塞指示符432。拥塞指示符432可以由第一阶段的处理设备所提供以便第二阶段的速率更新引擎确定用于到第二节点的分组传输的经更新参数。一个示例指示符可以是拥塞窗口，其可以指示第一节点传送至第二节点的尚未针对其接收到ACK或NACK分组的未解决数据分组的总数。另一个示例指示符可以是往返延迟，这是数据分组通过RTP层的传输与作为响应的ACK分组的收到之间的时间。其它示例指示符可以包括第二节点所确认的分组总数、重传数量、从第二节点所接收的明确拥塞通知的数量，或者它们的任意组合。

第二阶段340的处理器460还可以能够存储和访问数据472中的拥塞控制参数。该拥塞控制参数可以是用来由第一阶段330的计算设备设定拥塞控制设置的参数。

图5是图2的系统200的第二示例实施方式的框图。在图5的示例实施方式中，图2的缓存210和传送器220被简化成称为“传送/缓存/接收”510的单个框。框510可以包括与图2中的缓存210和传送器220的框相当的功能，并且可以通过主要数据路径501传送和接收传入数据分组流502和传出数据分组504。

在图5中，第一节点的硬件由虚线框520所表示。如能够从图5看到的，该拥塞控制系统的第一阶段被包括在第一节点的硬件中，但是该拥塞控制系统的第二阶段的至少一些由与第一节点的硬件分离的组件所管理。特别地，速率更新请求由软件模块来管理，而并不要求专用硬件或第一节点的硬件来处理速率更新请求。

在图5的示例中，第一阶段的一个或多个计算设备530被连接至邮箱机制540以便将速率更新请求转发至分离的软件模块以便处理。该邮箱机制包括用于临时存储速率更新请求和相关联信息的存储器，所述相关联信息诸如第一阶段的计算设备530所确定的拥塞指示符。在图5的示例中，邮箱机制540包括用于临时存储的第一队列542或缓冲器。邮箱机制540中还可以包括第二队列544或缓冲器以用于临时存储速率更新事件的结果，从而该结果可以被反馈至第一节点的硬件520并且被用来控制数据分组沿数据路径501的传输。在图5的示例中，该邮箱机制自身被包括在第一节点的硬件510中，但是在其它示例中，可以使用与第一节点的硬件分离的存储器来缓冲速率更新结果的传入流。

在图5的示例中，片上网络550被用来将系统500的硬件部分520对接至软件部分。片上网络550可以连接至与第一节点的硬件520分离并且速率更新引擎软件570能够对其进行访问的存储器560。速率更新引擎软件570可以进一步有权访问与第一节点的硬件520分离的一个或多个处理器580，由此速率更新引擎软件模块的指令可以控制处理器580依据所编程的速率更新算法处理存储在存储器560中的数据，从而从输入数据得出速率更新结果。片上网络550所提供的接口可以是双向的以便将速率更新结果提供回第一节点的硬件520。

图6是图示示例子系统600的示图，所述示例子系统600用于在第一节点的硬件的速率更新调度器610和与第一节点的硬件分离地存储的基于软件的速率更新引擎620之间进行对接。可以在速率更新调度器610和速率更新引擎620之间提供诸如图5的存储器560的存储器，以便临时存储从第一节点发送至该软件的速率更新请求以及从该软件反馈回到该第一节点的速率更新结果。在图6的示例中，该存储器以用于存储速率更新请求的第一环形缓冲器630和用于存储速率更新结果的第二环形缓冲器640的形式被示出。每个缓冲器可以被配置为充当队列，由此信息顺序地从第一节点的硬件的连接场境缓存向速率更新引擎软件进行交换，反之亦然。第一缓冲器在本文被称作事件队列，而第二缓冲器则被称作结果队列。

每个缓冲器630、640可以被存储在与软件模块570相关联的存储器空间中。该事件队列可以包括用于将速率更新请求添加至该队列的尾部指针632以及用于将排队的请求前移至软件模块的头部指针634。类似地，该结果队列可以包括用于将速率更新结果添加至该队列的尾部指针642以及用于将排队的结果前移至第一节点的头部指针644。指针632、634、642、644中的每一个以及每个缓冲器的整体大小可以被存储在第一节点的存储器的控制/状态寄存器中，从而硬件的读/写接口615可以向相应缓冲器的正确单元推送请求以及从那里拉取结果。该事件队列的头部指针634也可以存储在速率更新引擎620的读/写接口625的存储器中，该速率更新引擎620的读/写接口625能够从事件队列640的正确单元拉取请求。在速率更新引擎620的读/写接口625从相应缓冲器拉取请求或者向其推送结果时，诸如先进可扩展接口(AXI)之类的接口可以被用来更新速率更新调度器610的CSR中所存储的指针。在操作中，头部指针和尾部指针可以随着数据项被添加以及从队列移除而被速率更新调度器610和速率更新引擎620所前移，并且AXI写接口可以被用来保持速率更新引擎620和速率更新调度器610的存储器中的记录之间的一致性。

返回图5，该软件速率更新引擎可以在ARM计算复合体(ARM compute complex)(ACC)上实施，并且可以被设计为每秒钟应对多达1500万个拥塞控制事件。作为对比，速率更新引擎作为第一节点的附加硬件块的实施方式可以被设计为支持多至2亿个拥塞控制事件。因此，当拥塞控制以软件实施时，关于什么样的事件触发速率更新事件而什么样的事件则并不触发速率更新事件必须要更具选择性。此外，因为第一节点的硬件和速率更新引擎的软件之间的通信由具有有限存储器空间的数据缓冲器所维持，所以关于什么样的事件触发速率更新事件而什么样的事件则并不触发速率更新事件的选择性程度可以根据该缓冲器在给定时间有多满而有所变化。

通过在第一节点的控制/状态寄存器中存储缓冲器指针数据和大小数据，第一节点可能对甚至队列在给定时间有多满进行跟踪，并且对未来事件应当何时触发另一个速率更新事件时提供动态控制。图7图示了以对从速率更新调度器向速率更新引擎发送的请求加以限制为目的的示例例程，其之前在图4中被称作请求限制器例程448。

可以选择某些判断式或条件来确定是否需要速率更新，或者更确切地，速率更新的迫切性的程度。第一示例判断式可以基于自前一个速率更新请求起的时间量，因为新速率更新的迫切性随着自前一个速率更新请求起的时间的增加而增加。第二示例判断式可以基于自从第二节点接收到前一个ACK分组起的时间量，因为新速率更新的迫切性随着自接收到前一个ACK分组起的时间的增加而增加。这些条件在本文分别被称作判断式1和判断式2，或者简称为P1和P2。

在图7的示例中，事件队列由水平条栏所图示，对于其而言，该条栏的水平轴线从右端的空开始到左端的充满而表示该队列有多充满。该条栏被划分为多个分段，每个分段与用于将速率更新事件推送到事件队列上的不同条件集合相关联。第一分段被示为处于空和阈值1之间。当队列的充满度(fullness)处于这两个数量之间时，所有请求对被推送至队列。第二分段被示为处于阈值1和阈值2之间。当队列的充满度处于这两个数量之间时，请求可以在P1或P2中的任一个为真时被推送至队列，这指示由于自前一个更新起或者自前一个ACK分组起的时间所导致的速率更新的迫切性。第三分段被示为处于阈值2和阈值3之间。当队列的充满度处于这两个数量之间时，请求可以在P1为真时被推送至队列，这指示仅由于自前一个更新起的时间所导致的速率更新的迫切性，而并不考虑自接收到前一个ACK分组起已经多久。第四分段被示为处于阈值3和充满之间。当队列的充满度处于这两个数量之间时，更少的请求可以被推送队列以节省该队列中的空间，并且所推送的请求被限制为P1和P2都为真的时间。

在一些示例中，该请求限制器例程可以在软件端运行，而所有请求都可以基于如本文所描述的变化的迫切性程度而被推送至软件以及随后被丢弃。然而，由于软件可能具有有限的处理资源，所以另外从硬件端来操作该请求限制器例程经常是有利的。这就空出速率更新引擎软件模块以应对更加重要的事件并且避免超出软件模块的处理能力的界限。

由拥塞控制系统的第一和第二阶段所执行的例程以及其它例程结合图8和9的示图更详细地进行描述。应当理解的是，本文所描述的例程仅是作为示例，并且在其它示例中，某些步骤可以被增加、删减、替换或重新排序。

图8是图示用于拥塞控制的示例例程800的流程图。该例程的某些步骤被描述为由第一阶段的计算设备的一个或多个处理器所执行。其它步骤被描述为由第二阶段的计算设备的一个或多个处理器所执行。然而，在其它的示例例程中，负责这些步骤中的至少一些的处理器可以从第一阶段变换至第二阶段，反之亦然。

在框810，第一阶段的一个或多个处理器可以分析通过通信协议层从远程节点所接收的数据分组。在框820，第一阶段的一个或多个处理器可以根据框810的分析确定拥塞指示符。拥塞指示符可以包括但并不局限于拥塞窗口、往返延迟、远程节点所确认的分组总数、重传数量、从远程节点所接收的明确拥塞通知的数量，或者它们的任意组合。

在框830，第一阶段的一个或多个处理器可以确定是否向第二阶段发送速率更新请求。如果确定并不发送速率更新请求，则操作在框840结束，其中没有速率更新请求被发送，并且不执行速率更新事件。

可替换地，如果确定发送速率更新请求，则操作可以在框850继续，由此速率更新请求和拥塞指示符可以从第一阶段的处理器传送至第二阶段的速率更新引擎的一个或多个处理器。在一些实施方式中，发送速率更新请求可以涉及到指示第一节点的另一个硬件模块处理分组传输事件和拥塞指示符。在其它实施方式中，发送速率更新请求可以涉及到将分组传输事件和拥塞指示符写入邮箱队列。这可以使用诸如CMN-600的相干网状网络来实现，以便贯穿系统保持缓存相干性。

在框850，第二阶段的一个或多个处理器可以基于拥塞指示符而确定拥塞控制参数。拥塞控制参数可以包括但并不局限于分组间间隙、重传超时，或者它们的任意组合。

在框860，第二阶段的一个或多个处理器可以将拥塞控制结果输出回到第一阶段的处理器以便实施。该拥塞控制结果可以包括框850处所确定的拥塞控制参数，从而拥塞控制实施依据所确定的拥塞控制参数而被执行。

在框870，第一阶段的一个或多个处理器可以从该速率更新引擎接收拥塞控制结果。在框880，该拥塞控制结果可以被实施，由此利用数据路径与远程节点通信的第一阶段的一个或多个处理器控制数据分组通过数据路径到该远程节点的传输。在分组间间隙增加或重传超时增加的情况下，该控制可以导致传送分组的整体频率有所下降。这进而可以缓解远程节点处的拥塞，诸如聚播拥塞。相反地，在分组间间隙减小或重传超时减小的情况下，该控制可以导致数据路径上的整体连接流量有所减少。这可能是远程节点处诸如聚播拥塞的拥塞已经得到缓解并且该数据路径上的连接流量允许增加的结果。

图9是图示图8的框830的示例子例程900的流程图，其确定是否发送速率更新请求。例程900的操作可以从框820开始，根据确定而以图8的框840或850的操作继续。

在框910，第一阶段的一个或多个处理器可以确定是否已经发生了分组传输事件。在一些示例中，分组传输事件可以包括从远程节点收到ACK分组或NACK分组。而且，在一些示例中，分组传输事件可以包括到远程节点的分组的重传，诸如响应于收到来自远程节点的涉及到被重传分组的NACK分组。如果确定尚未发生分组传输事件，则操作可以在框840结束。可替换地，如果确定已经发生了分组传输事件，则操作可以可选地在框850以向第二阶段处理器传输速率更新请求而继续进行。

在一些示例中，子例程900可以包括用于特别是在请求被提供至与传送节点处的硬件实施方式相比具有相对有限容量的速率更新引擎软件模块以便执行速率更新时限制速率更新请求的频率的附加步骤。

在框920，可以由第一阶段的一个或多个处理器确定第一条件或判断式。该第一条件可以指示自前一个速率更新被执行起的时间是否超过了第一预定阈值，其也被称作延时阈值。

在框930，可以由第一阶段的一个或多个处理器确定第二条件或判断式。该第二条件可以指示自从远程节点接收到前一个ACK分组起的时间是否超过了第二预定阈值，其也被称作吞吐量阈值。

在框940，第一阶段的一个或多个处理器可以确定用于向速率更新引擎发送速率更新请求的事件队列或缓冲器中的剩余空间的数量。剩余空间可以基于存储在传送节点的控制/状态寄存器中的信息来确定。例如，在环形缓冲器的情况下，剩余空间可以根据缓冲器大小与该环形缓冲器的头部指针和尾部指针间的距离之间的差值来确定。

根据框940的确定，操作可以继续进行至若干框中的任一个，每个框与可以通过其来确定是否向速率更新引擎发送速率更新请求的判断式或条件的不同集合相关联。条件集合可以包括但并不局限于：无条件，仅第一条件，仅第二条件，第一或第二条件中的任一个，或者第一条件和第二条件二者。此外，可以向不同的条件集合指定不同的第一和第二阈值。例如，第一延时阈值可以在缓冲器相对空时被用于速率更新事件限制，但是较长的第二延时阈值可以在缓冲器相对满时被用于速率更新事件限制。针对另外的实例，第一吞吐量阈值可以在缓冲器相对空时被用于速率更新事件限制，但是较长的第二吞吐量阈值可以在缓冲器相对满时被用于速率更新事件限制。

在图9的特定示例中，子例程900的操作在四个条件集合间进行划分。

第一条件集合：如果缓冲器的容量C小于第一阈值T

第二条件集合：如果缓冲器的容量C大于第一阈值T

第三条件集合：如果缓冲器的容量C大于第二阈值T

第四条件集合：如果缓冲器的容量C大于第二阈值T

针对其中操作在框840结束的每个实例，结束操作可以导致较少的速率更新请求被发送至离线引擎。这可以允许系统吸收主要数据路径和离线引擎之间的突发和临时反向压力，进而确保主要数据路径并不失速。

图8和9的例程可以被第一阶段的计算设备的一个或多个处理器反复发起。例如，该例程可以在每次通过数据路径从远程节点接收到数据分组时被发起。

以上所描述的例程总体上对于卸载拥塞控制算法会是有利的，并且更具体地是从通信协议的主要数据路径卸载处理速率更新结果的确定，而另外留出通信节点的硬件的其它处理模分块或所连接的软件模块来执行该处理。此外，由于拥塞控制算法与主要数据路径的硬件分离，所以所指定的拥塞控制引擎可以更容易地被调适或设计以执行任何数量的拥塞控制协议，包括但并不局限于GCN、Swift或BBR协议。

虽然本文已经参考特定实施例对该技术进行了描述，但是所要理解的是，这些实施例仅是对本技术的原则和应用的说明。因此，要理解的是，可以对说明性实施例进行多种修改，并且可以设想出其它部署形式而并不背离如所附权利要求限定的本技术的精神和范围。

以上可替换示例中的大多数并不互相排斥，而是可以以各种组合方式来实施以实现唯一的优势。由于上文所讨论的特征的其它变化和组合可以被采用而并不背离权利要求所限定的主题，所以实施例的以上描述应当被认为是对权利要求所限定主题的说明而非限制。作为示例，前述操作并非一定要以以上描述的确切顺序来执行。相反，各个步骤可以以不同顺序来处理，诸如逆序处理或同时处理。除非另外有所指出，否则步骤也可以被省略。此外，提供本文所描述的示例以及措辞为“诸如”、“包括”等的条款并不应当被解释为将权利要求的主题限制为具体的示例；相反，示例意在仅是对许多可能实施例之一进行阐述。另外，不同附图中的相同附图标记可以标识相同或相似的要素。