CN114143827A - RoCE网络拥塞控制的方法及相关装置 - Google Patents

RoCE网络拥塞控制的方法及相关装置 Download PDF

Info

Publication number
CN114143827A
CN114143827A CN202010915720.6A CN202010915720A CN114143827A CN 114143827 A CN114143827 A CN 114143827A CN 202010915720 A CN202010915720 A CN 202010915720A CN 114143827 A CN114143827 A CN 114143827A
Authority
CN
China
Prior art keywords
congestion
network
information
message
network device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010915720.6A
Other languages
English (en)
Inventor
韩兆皎
白志君
钱远盼
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202010915720.6A priority Critical patent/CN114143827A/zh
Priority to EP21863709.8A priority patent/EP4195760A4/en
Priority to PCT/CN2021/116494 priority patent/WO2022048647A1/zh
Publication of CN114143827A publication Critical patent/CN114143827A/zh
Priority to US18/178,117 priority patent/US20230208771A1/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/127—Avoiding congestion; Recovering from congestion by using congestion prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/27—Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0289—Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H04L47/115—Identifying congestion using a dedicated packet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/122—Avoiding congestion; Recovering from congestion by diverting traffic away from congested entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/25—Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263—Rate modification at the source after receiving feedback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H04W28/22—Negotiating communication rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请实施例提供了RoCE网络拥塞控制的方法及相关装置，方法包括：第一网络设备向第二网络设备发送RoCE协议报文；第一网络设备接收来自第二网络设备的确认报文，确认报文包括对RoCE协议报文的确认信息和指示信息，指示信息用于指示第一网络设备与第二网络设备之间的网络通路是否发生拥塞；第一网络设备基于确认报文进行拥塞控制。实施本申请实施例，能够及时向第一网络设备通告网络拥塞的发生和消除，提高第一网络设备的拥塞控制反应速度，提升网络带宽利用率。

Description

RoCE网络拥塞控制的方法及相关装置
技术领域
本申请涉及通信技术领域，尤其涉及RoCE网络拥塞控制的方法及相关装置。
背景技术
在数据通信系统，为了提高计算设备之间报文传输的速度，通常采用远程直接内存访问(Remote Direct Memory Access，RDMA)技术进行连接。RDMA技术是通过网络把数据直接传入计算机的存储区，将数据从一个系统快速移动到远程系统存储器中，而无需两台计算设备的操作系统或内核介入。RDMA消除了外部存储器复制和上下文切换的开销，因此能解放内存带宽和CPU周期用于改进应用系统性能。
基于融合以太网的远程直接内存访问(RDMA over Converged Ethernet，RoCE)是RDMA技术的一种，允许服务器通过以太网进行远程直接内存访问。虽然RoCE协议的优点主要是基于融合以太网的特性，但是RoCE协议也可以应用在传统以太网网络或者非融合以太网络中。
当网络中的流量因为过大而产生拥塞时(从某个源端端口发出的报文流量有可能在某个时间段可能比较大)，DCQCN规定拥塞节点(Congestion Point，CP)设备对报文进行随机早期检测(Random Early Detection，RED)显式拥塞通知(Explicit CongestionNotification，ECN)标记。对于支持RoCE协议的接收端，该接收端在收到携带ECN标记的报文时，向源端发送独立的拥塞通告(Congestion Notification Packet，CNP)报文以通告网络拥塞，源端根据该CNP报文，降低后续报文的发送速率到某个值以消除拥塞。
RoCE协议的网络拥塞通告采用了单独的CNP报文通告的方式，所以发生网络拥塞后，接收端的网卡需要连续发送ACK确认报文和CNP报文。但由于接收端的网卡的报文发送速率是存在上限的，可能会造成拥塞通告的发送延迟，从而会造成源端拥塞控制反应速度慢。
另外，CNP报文只能向源端通告网络发生了拥塞，不能通告网络的拥塞已消除，只能由源端定时检测网络的拥塞是否消除，这也导致了源端不能及时恢复报文发送速率，影响网络带宽有效利用率。
发明内容
本申请实施例提供一种RoCE网络拥塞控制的方法及相关装置，能够及时通告网络拥塞的发生和消除，提高源端的拥塞控制反应速度，提升网络带宽利用率。
第一方面，本申请提供一种RoCE网络拥塞控制的方法，该方法包括：第一网络设备向第二网络设备发送RoCE协议报文；所述第一网络设备接收来自第二网络设备的确认报文，所述确认报文包括对所述RoCE协议报文的确认信息和指示信息，所述指示信息用于指示所述第一网络设备与所述第二网络设备之间的网络通路是否发生拥塞；所述第一网络设备基于所述确认报文进行拥塞控制。
其中，第一网络设备和第二网络设备均为被设计用来允许计算设备在网络上进行通讯的硬件，且均支持RoCE协议的网络通信，RoCE(RDMA over Converged Ethernet)是一种允许通过以太网使用远程直接内存访问(RDMA)的网络协议。第一网络设备和第二网络设备例如均可以是网络接口控制器(RDMA network interface controller，RNIC)、网络接口控制器、网络适配器(network adapter)、网卡(network interface card)、或局域网接收器(LAN adapter)。在可能的实现中，第一网络设备和第二网络设备中的至少一者还可以是交换机设备。
第一网络设备可设置于源端设备，第二网络设备可设置于目的端设备，故源端设备和目的端设备可基于第一网络设备和第二网络设备之间的通信交互而实现远程数据读写与传输。
可以看到，实施本申请实施例，源端设备可通过第一网络设备发送报文，目的端设备可通过第二网络设备回复聚合有指示信息的ACK确认信息，指示信息用于向第一网络设备通告当前网络通路上有没有网络拥塞。这样，第一网络设备就可以获得当前网络的状态，也就是当前网络是拥塞的还是无拥塞的，第一网络设备就能够基于当前网络的状态执行相应的拥塞控制操作。例如当网络无拥塞时，第一网络设备可以及时维持或恢复高速发送速率。所以，一方面，通过指示信息和ACK的聚合承载，避免了传统方案中需要发送独立CNP的弊端，降低了通告的开销，有利降低大流量场景下拥塞通告的时延，提高了目的端设备的反应速度。另一方面，通过指示信息，源端设备可以在第一时间可以获得网络拥塞的情况，更早的触发拥塞控制实现发送速率的调控，提高了源端设备的响应速度。在网路拥塞解除时，也能够通过指示信息让源端设备获知，以及时恢复发送速率，提高了网路带宽利用率。
基于第一方面，在具体的实施例中，在所述指示信息指示所述网络通路发生拥塞的情况下，所述确认报文还包括拥塞信息，所述拥塞信息具体包括所述网络通路的拥塞程度、拥塞位置、报文队列长度、网络时延中的至少一种信息；所述第一网络设备基于所述确认报文进行拥塞控制，具体包括：所述第一网络设备根据所述拥塞信息进行拥塞控制。
可以看到，实施本申请实施例，当前网络通路上有网络拥塞时，确认报文还可以携带拥塞信息，拥塞信息表征了详细的网络状态内容。这样，源端设备的第一网络设备可提取拥塞信息进行定量、多样化的拥塞控制动作。所以，一方面，通过指示信息、拥塞信息和ACK的聚合承载，避免了独立CNP的发送，降低了通告的开销，有利降低大流量场景下拥塞通告的时延，提高了目的端设备的反应速度。另一方面，现有的RDMA网络拥塞控制的通告信息少，网络拥塞收敛速度慢，而本申请利用聚合报文承载了详细的拥塞信息，例如拥塞程度、拥塞点、队列深度、网络时延等不同维度的信息，有利于第一网络设备根据详细拥塞信息进行多样化、差异化、具体化的拥塞控制，例如调整不同级别的发送速率，又例如实现报文数量、发送时间等多样化的调整，从而极大提升了拥塞控制的效果。
基于第一方面，在可能的实施例中，所述第一网络设备根据所述拥塞信息进行拥塞控制包括以下至少一种方式：
(1)第一网络设备可根据所述拥塞程度，定量调整所述第一网络设备的下一时间窗内的报文的发送速率，其中在可能的实施例中，所述拥塞程度属于多种不同级别拥塞程度中的一种，即不同级别拥塞程度分别对应不同的发送速率。所述拥塞程度和所述发送速率之间具有对应关系。例如对于“无拥塞、轻度拥塞、中度拥塞、重度拥塞”等多个级别，第一网络设备可以根据拥塞程度的差异来决定如何实施降速处理。不同级别可以对应不同的报文发送速率，实现不同档次的报文发送速率的调节，因而可以实现更快的速率收敛。
(2)第一网络设备可根据拥塞位置和报文队列深度中的至少一者，确定下一时间窗内的待发送的报文数量。源端设备的RNIC可以根据该拥塞位置和/或报文队列深度判断该网络路径上还可以承载多少数据报文而不导致发生丢包等行为，从而决定可以继续发送的报文数量，这对高带宽需求的网络应用比较友好。
(3)所述第一网络设备可根据网络时延调整所述第一网络设备的发送速率或下一时间窗内的待发送的报文数量。
可以看到，实施本申请实施例，本申请利用聚合报文承载了详细的拥塞信息，例如拥塞程度、拥塞点、队列深度、网络时延等不同维度的信息，有利于第一网络设备根据详细拥塞信息进行多样化、差异化、具体化的拥塞控制，极大提升了拥塞控制的效果。
基于第一方面，在可能的实施例中，所述确认报文具体包括基础传输头(BTH)字段和扩展字段，所述确认信息和所述指示信息承载于所述BTH字段，所述拥塞信息承载于所述扩展字段。
其中，所述扩展字段例如为本文描述的拥塞控制扩展传输头(CongestionExtended Transport Header，CETH)，即可通过扩展的CETH头来承载拥塞信息。
例如，该CETH包括标准定义和厂家自定义信息这两部分，其中标准定义部分可用于混合组网场景的兼容性对接。标准定义部分可包括如下字段：版本号(Ver)、CETH头长度(Length)。其中：
厂家自定义信息字段用于支持各厂家自定义拥塞控制通告信息，总长度为例如为(Length*4–1)字节。例如厂家可以设计承载网络通路的拥塞程度、拥塞位置、报文队列长度、网络时延中的至少一种信息。举例来说，网络通路的拥塞程度可用2bit的ratio字段表征，该ratio字段用于标识拥塞程度。在应用场景中，ratio字段可以分量级来指示拥塞程度，例如：无拥塞、轻度拥塞、中度拥塞、重度拥塞，等等。此外，还可以对厂家自定义信息设计更多的其他内容，例如设计的1bit的字段来指示当前的拥塞通告为普通CNP类型还是增强CNP类型。又例如可以设计4bit的字段来用于标识业务场景，例如RC/XRC write/send场景、RC/XRC read response场景或UD send场景。
Ver字段用于指示CETH版本号，例如可占用4bit，用于支持拥塞控制算法的升级及兼容性对接。
Length字段用于指示CETH头长度，例如占用4bit，支持CETH头可变长度，以减少固定开销。
可以看到，通过设计扩展字段CETH，既能够保证拥塞信息的承载，且不占用现有字段的空间，还可用于混合组网场景的兼容性对接，且支持各厂家自定义拥塞控制通告信息，有利于满足不同厂家的需求。
基于第一方面，在可能的实施例中，所述确认报文具体包括BTH字段，所述确认信息、所述指示信息和所述拥塞信息均承载于所述BTH字段。
例如，在一种实现中，可利用传统ACK的BTH中的保留字段“reserved 6”去承载本申请实施例的拥塞信息，也就是该“reserved 6”作为第一CETH进行相关数据承载，从而达到拥塞控制和传输确认的聚合的目的。
又例如，在一种实现中，可利用传统ACK的BTH中的保留字段“reserved 7”去承载本申请实施例的拥塞信息，也就是该“reserved 7”作为第二CETH进行相关数据承载，从而达到拥塞控制和传输确认的聚合的目的。
本实施例可将该指示信息和拥塞信息整合设置到确认信息的字段中，这种情况下，该确认报文可视为传统ACK报文的改进，充分利用现有字段空间实现拥塞信息的承载，从而实现对确认信息中字段空间的充分利用，避免对现有报文格式作更改。
基于第一方面，在可能的实施例中，在所述指示信息指示所述网络通路未发生拥塞的情况下，所述第一网络设备基于所述确认报文进行拥塞控制包括：所述第一网络设备将所述第一网络设备的发送速率维持不变，例如维持较高的发送速率，从而提高报文传输效率。
基于第一方面，在可能的实施例中，在所述指示信息指示所述网络通路未发生拥塞的情况下，所述第一网络设备基于所述确认报文进行拥塞控制包括：所述第一网络设备将所述第一网络设备的发送速率设置为预设速率。例如从低发送速率(该低发送速率例如是网络拥塞时设计的)调整为较高的发送速率(该高发送速率例如是网络无拥塞时设计的)，从而提升了发送速率的恢复效率，降低报文发送的延迟。
基于第一方面，在可能的实施例中，指示信息可以是指示位、指示字段、指示标识等。
例如，当指示信息是指示位时，当指示位的值为0，意味着向源端设备的RNIC指示当前网络通路中没有网络拥塞的情况，确认报文中不携带拥塞信息；当指示位的值为1，意味着目的端设备向源端设备的RNIC指示当前网络通路中存在网络拥塞的情况，且确认报文中携带了拥塞信息。
又例如，指示信息可以利用现有字段进行功能重定义，比如指示信息可以是确认报文的BTH.BECN字段，当BTH.BECN字段为0，意味着向源端设备的RNIC指示当前网络通路中没有网络拥塞的情况，确认报文中不携带拥塞信息；当BTH.BECN字段为1，意味着向源端设备的RNIC指示当前网络通路中存在网络拥塞的情况，且确认报文中携带了拥塞信息。
第二方面，本申请提供一种RoCE网络拥塞控制的方法，所述方法包括：
第二网络设备接收第一网络设备的RoCE协议报文；所述第二网络设备检查所述RoCE协议报文是否携带显式拥塞通知；所述第二网络设备根据检查结果生成确认报文，所述确认报文包括对所述RoCE协议报文的确认信息和指示信息，所述指示信息用于指示所述第一网络设备与所述第二网络设备之间的网络通路是否发生拥塞；所述第二网络设备向所述第一网络设备发送所述确认报文，所述确认报文用于所述第一网络设备进行拥塞控制。
可以看到，实施本申请实施例，目的端设备可通过第二网络设备分析RoCE协议报文是否携带显式拥塞通知，进而回复聚合有指示信息的ACK确认信息，指示信息用于向第一网络设备通告当前网络通路上有没有网络拥塞。这样，第一网络设备就可以获得当前网络的状态，也就是当前网络是拥塞的还是无拥塞的，第一网络设备就能够基于当前网络的状态执行相应的拥塞控制操作。例如当网络无拥塞时，第一网络设备可以及时维持或恢复高速发送速率。所以，一方面，通过指示信息和ACK的聚合承载，避免了传统方案中需要发送独立CNP的弊端，降低了通告的开销，有利降低大流量场景下拥塞通告的时延，提高了目的端设备的反应速度。另一方面，通过指示信息，源端设备可以在第一时间可以获得网络拥塞的情况，更早的触发拥塞控制实现发送速率的调控，提高了源端设备的响应速度。在网路拥塞解除时，也能够通过指示信息让源端设备获知，以及时恢复发送速率，提高了网路带宽利用率。
基于第二方面，在可能的实施例中，在所述指示信息指示所述网络通路发生拥塞的情况下，所述确认报文还包括拥塞信息，所述拥塞信息具体包括所述网络通路的拥塞程度、拥塞位置、报文队列长度、网络时延中的至少一种信息；所述拥塞信息用于所述第一网络设备进行拥塞控制，有利于第一网络设备根据详细拥塞信息进行多样化、差异化、具体化的拥塞控制，例如调整不同级别的发送速率，又例如实现报文数量、发送时间等多样化的调整，从而极大提升了拥塞控制的效果。
基于第二方面，在可能的实施例中，所述拥塞程度属于多种不同级别拥塞程度中的一种，不同级别拥塞程度分别对应所述第一网络设备不同的发送速率。
基于第二方面，在可能的实施例中，所述第二网络设备根据检查结果生成确认报文之前，还包括：所述第二网络设备生成所述拥塞信息。
例如，第二网络设备当前网络有拥塞时，可通过报文检测或者硬件检测的方式获得网络状态信息，例如拥塞程度、拥塞点、队列深度、网络时延等不同维度的信息。
基于第二方面，在可能的实施例中，当所述拥塞信息包括所述拥塞程度时，所述第二网络设备可通过以下获得所述拥塞程度：
(1)第二网络设备根据历史报文接收记录中携带显式拥塞通知的RoCE协议报文的比例，来确定所述网络通路的拥塞程度。例如，第二网络设备对接收报文携带ECN标记的比例做周期性滑窗统计，从而计算出当前该网络路径的具体拥塞程度。
(2)通过借助带内网络遥测(Inband Network Telemetry，INT)方式或者通过现场运行管理和维护(In-situ Operation Administration and Maintenance，IOAM)方式获得所述拥塞程度。以INT方式为例，可将INT支持的范围扩展到服务器网卡，网卡就可以接收到交换机插入到数据报文内的测量信息，通过该信息可以计算获得当前网络状态，例如通过时间戳计算出网络时延，通过队列长度和队列占用率计算出拥塞程度，等等。
基于第二方面，在可能的实施例中，所述确认报文具体包括基础传输头(BTH)字段和扩展字段，所述确认信息和所述指示信息承载于所述BTH字段，所述拥塞信息承载于所述扩展字段。其中，所述扩展字段例如为本文描述的拥塞控制扩展传输头(CongestionExtended Transport Header，CETH)，即可通过扩展的CETH头来承载拥塞信息。
通过设计扩展字段CETH，既能够保证拥塞信息的承载，且不占用现有字段的空间，还可用于混合组网场景的兼容性对接，且支持各厂家自定义拥塞控制通告信息，有利于满足不同厂家的需求。
基于第二方面，在可能的实施例中，所述确认报文具体包括BTH字段，所述确认信息、所述指示信息和所述拥塞信息均承载于所述BTH字段。
通过将指示信息和拥塞信息整合设置到确认信息的字段中，充分利用现有字段空间实现拥塞信息的承载，从而实现对确认信息中字段空间的充分利用，避免对现有报文格式作更改。
第三方面，本申请实施例提供一种装置，所述装置应用于第一网络设备，包括：报文发送模块，用于向第二网络设备发送RoCE协议报文；报文接收模块，用于接收来自第二网络设备的确认报文，所述确认报文包括对所述RoCE协议报文的确认信息和指示信息，所述指示信息用于指示所述第一网络设备与所述第二网络设备之间的网络通路是否发生拥塞；拥塞控制模块，用于基于所述确认报文进行拥塞控制。
其中，该装置的各功能模块具体用于实现第一方面描述的方法步骤，这里不再赘述。
基于第三方面，在可能的实施例中，在所述指示信息指示所述网络通路发生拥塞的情况下，所述确认报文还包括拥塞信息，所述拥塞信息具体包括所述网络通路的拥塞程度、拥塞位置、报文队列长度、网络时延中的至少一种信息；所述拥塞控制模块具体用于，根据所述拥塞信息进行拥塞控制。
基于第三方面，在可能的实施例中，所述拥塞控制模块具体用于：根据所述拥塞程度，调整所述第一网络设备的发送速率，其中所述拥塞程度和所述发送速率之间具有对应关系；或者，根据所述拥塞位置和所述报文队列深度中的至少一者，确定下一时间窗内待发送的报文数量；或者，根据所述网络时延调整所述第一网络设备的发送速率或确定下一时间窗内待发送的报文数量。
基于第三方面，在可能的实施例中，所述拥塞程度属于多种不同级别拥塞程度中的一种，不同级别拥塞程度分别对应不同的发送速率。
基于第三方面，在可能的实施例中，所述确认报文具体包括基础传输头(BTH)字段和扩展字段，所述确认信息和所述指示信息承载于所述BTH字段，所述拥塞信息承载于所述扩展字段。
基于第三方面，在可能的实施例中，所述确认报文具体包括BTH字段，所述确认信息、所述指示信息和所述拥塞信息均承载于所述BTH字段。
基于第三方面，在可能的实施例中，所述拥塞控制模块具体用于，在所述指示信息指示所述网络通路未发生拥塞的情况下，将所述第一网络设备的发送速率维持不变。
基于第三方面，在可能的实施例中，所述拥塞控制模块具体用于，在所述指示信息指示所述网络通路未发生拥塞的情况下，将所述第一网络设备的发送速率设置为预设速率。
第四方面，本申请提供一种装置，所述装置应用于第二网络设备，包括：报文接收模块，用于接收第一网络设备的RoCE协议报文；拥塞信息确定模块，用于检查所述RoCE协议报文是否携带显式拥塞通知；通告聚合发送模块，用于根据检查结果生成确认报文，所述确认报文包括对所述RoCE协议报文的确认信息和指示信息，所述指示信息用于指示所述第一网络设备与所述第二网络设备之间的网络通路是否发生拥塞；还用于向所述第一网络设备发送所述确认报文，所述确认报文用于所述第一网络设备进行拥塞控制。
其中，该装置的各功能模块具体用于实现第二方面描述的方法步骤，这里不再赘述。
基于第四方面，在可能的实施例中，在所述指示信息指示所述网络通路发生拥塞的情况下，所述确认报文还包括拥塞信息，所述拥塞信息具体包括所述网络通路的拥塞程度、拥塞位置、报文队列长度、网络时延中的至少一种信息；所述拥塞信息用于所述第一网络设备进行拥塞控制。
基于第四方面，在可能的实施例中，所述拥塞程度属于多种不同级别拥塞程度中的一种，不同级别拥塞程度分别对应所述第一网络设备不同的发送速率。
基于第四方面，在可能的实施例中，所述拥塞信息确定模块还用于生成所述拥塞信息。
基于第四方面，在可能的实施例中，当所述拥塞信息包括所述拥塞程度时，所述拥塞信息确定模块具体用于：根据历史报文接收记录中携带显式拥塞通知的RoCE协议报文的比例，来确定所述拥塞程度；或者，通过带内网络遥测(INT)方式获得所述拥塞程度；或者，通过现场运行管理和维护(IOAM)方式获得所述拥塞程度。
基于第四方面，在可能的实施例中，所述确认报文具体包括基础传输头(BTH)字段和扩展字段，所述确认信息和所述指示信息承载于所述BTH字段，所述拥塞信息承载于所述扩展字段。
基于第四方面，在可能的实施例中，所述确认报文具体包括BTH字段，所述确认信息、所述指示信息和所述拥塞信息均承载于所述BTH字段。
第五方面，本申请提供一种设备，所述设备包括主机系统和第一网络设备；所述主机系统用于与所述第一网络设备交互实现数据传输，所述第一网络设备用于执行如第一方面任意实施例描述的方法。
第六方面，本申请提供一种设备，所述设备包括主机系统和第二网络设备；所述主机系统用于与所述第二网络设备交互实现数据传输，所述第二网络设备用于执行如第二方面任意实施例描述的方法。
第七方面，本申请提供一种第一网络设备，该第一网络设备可包括控制器、寄存器、通信接口和逻辑运算部件，这些组件可以通过一个或多个内部总线进行电性连接。第一网络设备通过各组件的配合来实现如第一方面任意实施例描述的方法。
第八方面，本申请提供一种第二网络设备，该第二网络设备可包括控制器、寄存器、通信接口和逻辑运算部件，这些组件可以通过一个或多个内部总线进行电性连接。第一网络设备通过各组件的配合来实现如第二方面任意实施例描述的方法。
第九方面，本申请实施例提供一种芯片，所述芯片包括处理器与数据接口，所述处理器通过所述数据接口读取存储器上存储的指令，以执行如第一方面或第二方面的任意实施例描述的方法。
第十方面，本发明实施例提供了一种非易失性计算机可读存储介质；所述计算机可读存储介质用于存储第一方面或第二方面任意实施例描述的方法的实现代码。所述程序代码被设备执行时能够实现第一方面或第二方面的任意实施例描述的方法。
第十方面，本发明实施例提供了一种计算机程序产品；该计算机程序产品包括程序指令，当该计算机程序产品被设备执行时，执行前述第一方面或第二方面的任意实施例描述的方法。该计算机程序产品可以为一个软件安装包，可以下载该计算机程序产品并在控制器上执行该计算机程序产品，以实现第一方面或第二方面的任意实施例描述的方法。
可以看到，实施本申请实施例，目的端设备的第二网络设备可以在RoCE协议报文携带ECN标记时，回复聚合有CETH和指示信息的ACK确认信息，指示信息用于向源端设备通告当前网络通路上有网络拥塞，CETH用于向源端设备提供详细的拥塞信息。源端设备的第一网络设备从CETH提取拥塞信息进行定量、多样化的拥塞控制动作。目的端设备可以在RoCE协议报文未携带ECN标记时，则回复携带有指示信息的ACK确认信息，向源端设备通告当前网络通路上无网络拥塞，以便于源端设备及时维持或恢复高速发送速率。
这样，一方面，通过指示信息、拥塞信息和ACK的聚合承载，避免了独立CNP的发送，降低了通告的开销，有利降低大流量场景下拥塞通告的时延，提高了目的端设备的反应速度。
另一方面，通过指示信息，源端设备可以在第一时间可以获得网络拥塞的情况，更早的触发拥塞控制实现发送速率的调控，提高了源端设备的响应速度。在网路拥塞解除时，也能够通过指示信息让源端设备获知，以及时恢复发送速率，提高了网路带宽利用率。
最后，现有的RDMA网络拥塞控制的通告信息少，网络拥塞收敛速度慢，而本申请利用CETH承载网络详细的拥塞信息，例如拥塞程度、拥塞点、队列深度、网络时延等不同维度的信息，有利于源端设备根据详细拥塞信息将发送速率一步到位的调整到目标速率，实现快速收敛，并实现报文数量、发送时间等多样化的调整，极大提升了拥塞控制的效果。
附图说明
图1是本申请实施例涉及的系统架构的示意图；
图2是一种现有RoCE协议的设备通信流程场景图；
图3是一种网络大流量场景下的设备通信流程场景图；
图4是本申请实施例提供的一种包含功能模块的系统架构示意图；
图5是本申请实施例提供的一种网络设备的硬件结构示意图；
图6是本申请实施例提供的一些可能的确认报文的内容的示意图；
图7是本申请实施例提供的又一些可能的确认报文的内容的示意图；
图8是本申请实施例提供的一种拥塞信息的数据结构示例图；
图9是本申请实施例提供的一种确认报文的数据结构示意图；
图10是本申请实施例提供的另一种确认报文的数据结构示意图；
图11是本申请实施例提供的一些RoCE协议报文完整形式的示意图；
图12是本申请实施例提供的一些确认报文的完整形式的示意图；
图13是本申请实施例提供的一种RoCE网络拥塞控制的方法的流程示意图；
图14是本申请实施例提供的又一种RoCE网络拥塞控制的方法的流程示意图；
图15是本申请实施例提供的一种设备通信流程场景图；
图16是本申请实施例提供的一种网络大流量场景下的设备通信流程场景图。
具体实施方式
下面结合本申请实施例中的附图对本申请实施例进行描述。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。需要说明的是，当在本说明书和所附权利要求书中使用时，术语“包括”以及它们的任何变形，意图在于覆盖不排他的包含。例如包含了一系列单元/器件的系统、产品或者装置没有限定于已列出的单元/器件，而是可选地还包括没有列出的单元/器件，或者还可选地包括这些产品或者装置固有的其他单元/器件。
还需要说明的是，本说明书和权利要求书中的术语“第一”“第二”“第三”等用于区别不同的对象，而并非用于描述特定的顺序或者特定的含义。
本申请的实施方式部分使用的术语仅用于对本申请的具体实施例进行解释，而非旨在限定本申请。
首先介绍本申请实施例所应用的系统架构。
参见图1，图1是本申请实施例涉及的系统架构的示意图。如图1所示，该系统架构包括源端设备10和目的端设备20，源端设备10和目的端设备20之间通过网络30进行通信连接，源端设备10和目的端设备20均支持RoCE协议的网络通信。源端设备10和目的端设备20可以是计算机、台式电脑、笔记本电脑、服务器、终端等等计算设备。
网络30可包括多个交换设备31，所述多个交换设备31可用于在源端设备10和目的端设备20之间进行报文中转、传输、网络流量检测等，以实现源端设备10和目的端设备20之间的通信交互。交换设备31例如可以是交换机、路由器、中继设备、或网关设备等等。
源端设备10和目的端设备20均可包括包含网络设备和主机系统，主机系统包括主机CPU(central processing unit，中央处理器)以及内存。例如图1中源端设备10包括CPU12、内存13和网络设备11，这些组件之间可以通过总线建立连接。目的端设备20CPU22、内存23和网络设备21，这些组件之间可以也通过总线建立连接。
本申请实施例中，网络设备是一块被设计用来允许计算设备在网络上进行通讯的硬件，网络设备具体可以为用于实现设备与网络之间的通信的网络接口控制器(networkinterface controller，NIC)，又可称网络接口控制器、网络适配器(network adapter)，网卡(network interface card)，或局域网接收器(LAN adapter)。本申请实施例中，该网络设备支持RDMA协议，所以该NIC也可以称为RNIC(RDMA NIC)。本文将主要以RNIC为例进行方案的描述。
如图1所示，网络设备11和网络设备21通过网络30连接，以实现源端设备10和目的端设备20之间的通信。网络设备11和网络设备21均支持RoCE协议。当源端设备10通过网络向目的端设备20发起RDMA的读写请求时，是通过网络设备11和网络设备21将需要写的数据从内存13直接写入内存23中，或将需要读的数据从内存23直接写入内存13中。
对于源端设备10和目的端设备20的主机系统，主机系统中的CPU的数量可以是一个或多个，各个CPU的类型可以不同或者相同。CPU可以包括一个或多个处理器核，或者多个CPU也可以集成为多核处理器。主机系统可通过CPU运行各种软件组件，例如操作系统，以及在操作系统上运行的应用程序，等等。用户可通过该操作系统或应用程序发起业务通信，进而通过网络设备实现源端设备10和目的端设备20之间的通信交互。
主机系统中的内存可用于存储计算机指令和数据，内存也可以存储通过RDMA读写的数据，报文等。内存可以是以下存储介质的任一种或任一种组合：储存级记忆体(StorageClass Memory,SCM)、只读存储器(Read-Only Memory，ROM)、随机存取存储器(RandomAccess Memory，RAM)或高速缓存(Cache)。
上述系统架构中，两台计算设备之间的远程访问由计算设备的RNIC实现。支持RoCE协议的RNIC和交换设备组成的网络共同构成了RoCE网络。本申请方案应用于该RoCE网络，本申请实施例描述的方法可部署在RNIC网卡上，用于实现RoCE网络拥塞控制。
虽然将对上述两台计算设备划分角色分为源端设备和目的端设备，但需要理解的是，其中，“源端设备”和“目的端设备”是两个相对的概念：
源端设备指的是发起RDMA请求的计算设备，即请求访问另一台计算设备的计算设备。
目的端设备指的是接收RDMA请求的计算设备，即被另一台计算设备访问的计算设备。
例如，源端设备对目的端设备的访问可以为源端设备向目的端设备中写入数据，具体地，源端设备通过源端设备的RNIC将源端设备中的数据传输给目的端设备的RNIC，目的端设备通过目的端设备的RNIC接收该数据，从而将源端设备中的数据传输到目的端设备中。源端设备对目的端设备的访问也可以为源端设备从目的端设备中读取数据，具体地，源端设备可通过源端设备的RNIC读取目的端设备内存中的数据，目的端设备通过目的端设备的RNIC将源端设备要读取的数据发送给源端设备的RNIC，源端设备的RNIC接收该数据从而完成对目的端设备中的数据的读取。
本申请实施例中，之间通信的数据主要以报文的形式承载，本文中可以将支持RoCE协议的报文简称为RoCE协议报文或RoCE数据报文。通常来讲，当源端设备10向目的端设备20发送的报文被目的端设备成功接收时，目的端设备需回复ACK确认报文，以向源端设备告知报文成功接收，本申请实施例的技术方案主要就是针对这一过程进行优化。
需要说明的是，图1只是为描述本申请实例提供的技术方案，示出了上述组件及其连接关系。在具体实现时，图1所示的源端设备10和目的端设备20还可以包括上述组件之外的其它组件，例如还可以包括硬盘等硬件资源，这里不再展开描述。
图2示出了一种现有RoCE协议的设备通信流程。RoCE协议属于RDMA协议的一种。RDMA协议是传输层协议，RoCE协议是额外包含了网络层和链路层的协议。RoCE协议也支持可靠连接服务，源端设备对协议报文的发送携带报文序列号(Packet Sequence Numbers，PSN)，目的端设备在接收到协议报文后向源端设备回复ACK确认报文，通告源端设备的RNIC其发送的报文已被成功传输。当网络中的流量因为过大而产生拥塞时，网络中的CP设备对报文进行RED ECN标记，目的端设备在收到携带ECN标记的报文时，按协议规定，除了向源端设备回复ACK确认报文外，还向源端设备发送独立的CNP报文以通告网络拥塞，该CNP报文只定义为信号，并未携带任何状态信息。此外，目的端设备分别回复ACK确认报文和CNP报文后，源端设备的RNIC也需要分别处理这2个报文。
图3示例性示出了一种网络大流量场景下的设备通信流程。如图3所示，数据报文1发生了网络拥塞，但是受限于目的端设备的发送能力，其第一个CNP报文A的发送存在延迟，这导致源端设备直到协议报文5才开始降速，在此之前由于未及时降低发送速率会导致网络拥塞程度一直在加剧。从协议报文6开始网络拥塞开始消除，但是由于CNP报文的通告延迟，直到协议报文7源端设备都一直在降速，过大的降速会影响网络带宽利用率。从CNP报文B开始目的端设备就没有再次通告网络拥塞，但是源端设备无法及时获得拥塞消除的信息，只能靠时间超时缓慢升速，直到协议报文10才恢复到目标发送速率，在此期间的网络带宽利用率低。
综上可以看到，现有方案中，由于网卡的报文发送速率是存在上限的，发生网络拥塞后，目的端设备的网卡需要连续发送ACK确认报文和CNP报文，当网络流量压力增大时，会导致确认报文和CNP报文的回复延迟，从而造成控速的响应延迟。另外，CNP只能通告发生了拥塞，不能通告拥塞消除了，只能由发送端定时检测，ACK延迟增大会导致飞包统计偏多，CNP报文延迟会导致源端设备拥塞控制反应速度慢，速率控制不及时。
另外，RoCE协议采用CNP报文来通告网络拥塞，都只能通告网络上发生了拥塞，而无法通告网络拥塞的具体状态。这导致发送端无法实现高效的拥塞控制，而是只能一步步的缓慢逼近目标速率，网络收敛慢、带宽利用率低。
本申请实施例对源端设备和目的端设备的RNIC进行改进，从而能够解决上述现有方案中所提及的部分或全部的缺陷。参见图4，图4示出了本申请实施例的一种具体的系统架构。在该系统架构中，源端设备10和目的端设备20的RNIC分别配置了相关功能模块以支持本申请方案的实现。如图4所示，该源端设备10的网络设备为RNIC11，该目的端设备20的网络设备为RNIC21，RNIC11配置了拥塞控制模块111、报文发送模块112和报文接收模块113。RNIC21配置了拥塞信息确定模块211、通告聚合发送模块212和报文接收模块213，具体描述如下：
报文发送模块112用于向目的端设备20发送RoCE协议报文。
报文接收模块113用于接收来自目的端设备20的确认报文，该确认报文是本申请实施例设计的聚合报文。该确认报文可聚合了对所述RoCE协议报文的确认信息(ACK)和指示信息，所述指示信息用于指示源端设备10和目的端设备20之间的网络通路是否发生拥塞。在网络通路发生拥塞的情况下，该确认报文还聚合了拥塞信息，所述拥塞信息具体包括所述网络通路的拥塞程度、拥塞位置、报文队列长度、网络时延中的至少一种信息。也就是说，该确认报文既携带了网络拥塞的指示信息，也携带了网络拥塞的具体状态信息。关于确认报文的具体实现将在后文展开详细描述。
拥塞控制模块111用于基于所述确认报文进行可定量的拥塞控制，本申请实施例中，拥塞控制是一种用来调整传输控制协议(RoCE协议)连接单次发送的分组数量(单次发送量)的功能，它能够定量的增减单次报文发送量和发送频率，使之逼近当前网络最合适的承载能力。
报文接收模块213用于接收来自源端设备10的RoCE协议报文。
拥塞信息确定模块211用于检查所述RoCE协议报文是否携带显式拥塞通知，如果RoCE协议报文携带显式拥塞通知，则拥塞信息确定模块211可用于生成所述拥塞信息，所述拥塞信息具体包括所述网络通路的拥塞程度、拥塞位置、报文队列长度、网络时延中的至少一种信息，所述拥塞信息用于支持源端设备进行定量的拥塞控制。
通告聚合发送模块212可用于根据报文的检查结果生成确认报文，该确认报文即本申请实施例设计的所述聚合报文。还用于向源端设备10发送所述确认报文，以便于所述源端设备10实现定量的拥塞控制。
源端设备和目的端设备中的RNIC的上述功能模块可分别通过各自的RNIC的软件和硬件结构的相互配合实现。参见图5，图5示出了一种示例性的RNIC硬件结构30，该RNIC硬件结构30可以是源端设备中的RNIC的结构，也可以是目的端设备中的RNIC的结构。在具体实现中，RNIC硬件结构30可以是独立的标准网卡(例如PCIe接口的网卡)，也可以是集成到SoC芯片的集成网卡，通过升级现有RNIC网卡(例如ASIC芯片、FW固件等)硬件来获得，以支持本申请实施例提及的方案。
如图5所示，该RNIC硬件结构30可包括控制器31、寄存器32、通信接口33和逻辑运算部件34，这些组件可以通过一个或多个内部总线35进行电性连接。其中：
寄存器32为一种存储空间较小的存储器，寄存器32可以用于保存各种指令；寄存器32还可以用于存储在指令执行过程中临时存放的寄存器操作数和中间或最终的操作结果；寄存器还可以用于存储逻辑运算部件34完成控制器31请求的任务所使用的数据。
控制器31用于对寄存器中保存的指令进行译码，并发出为完成每条指令所要执行的各个操作的控制信号。控制器31是可运行程序的处理器核，例如可通过系统级芯片(System-on-a-Chip，SOC)，现场可编程门阵列(field programmable gate array，FPGA)、专用集成电路(application-specific integrated circuit，ASIC)或FPGA+ASIC等电路装置实现。控制器31又例如可以由各种与或门阵列组成。控制器31的控制方式例如可以是以微存储为核心的微程序控制方式，微程序可以保存在寄存器32中，又例如可以是为以逻辑硬布线结构为主的硬件控制方式，本申请不做限定。
逻辑运算部件34可以用于执行运算命令，如加命令、减命令、乘命令、除命令，等等；逻辑运算部件34还可以用于获取逻辑命令，如或逻辑命令、与逻辑命令、非逻辑命令，等等。逻辑运算部件34还可以用于从控制器31获取控制信号，根据获取到的控制信号从寄存器32中获取该控制信号对应的数据并执行相应的操作。
通信接口33用于发送或接收数据，通信接口33可以有多个，其可以分别用于接收处理器发送数据或发送数据给主机系统的CPU，或者，用于接收外部计算设备发送的数据或发送数据给外部的计算设备(例如发送或接收RoCE协议报文或聚合的确认报文)。
可选地，RNIC还可以包括晶体振荡器、媒体接入控制器、物理接口收发器，等等，本申请实施例不作限制。
具体实施例中，控制器31读取对寄存器中保存的指令发出为完成每条指令所要执行的各个操作的控制信号，以实现本文中任意实施例描述的RoCE网络拥塞控制的方法。
为了更好理解本申请的实现方案，下面对本申请实施例提供的能够实现拥塞通告聚合的确认报文进行具体描述。
本申请实施例通过对现有RoCE ACK确认报文进行扩展，改进RoCE协议的拥塞通告机制，获得本申请的确认报文，使其可以携带网络拥塞的指示信息和拥塞信息，以实现拥塞通告聚合和精准的网络拥塞通告。
综合参见图6和图7，图6和图7示出了本申请实施例中一些可能的确认报文的内容。该确认报文可由目的端设备产生，用于向源端设备回复。
图6示出了无网络拥塞场景(例如RoCE协议报文不携带显式拥塞通知ECN)下的两种确认报文的示意图，确认报文包括对所述RoCE协议报文的确认信息和指示信息，该确认信息可实现现有的ACK确认的功能，即通告源端设备的RNIC其发送的报文是否已被目的端设备成功传输，该指示信息用于指示源端设备和目的端设备之间的网络通路没有发生拥塞。
如图6所示，一种实施例中，确认报文实现为确认报文A，确认报文A中的确认信息和指示信息可设置在报文中的不同位置，例如可以分布在不同的报文头中，从而避免对确认信息中字段做修改。又一种实施例中，确认报文实现为确认报文B，可将该指示信息整合设置到确认信息的字段中，从而实现对确认信息中字段空间的充分利用。
图7示出了有网络拥塞场景(例如RoCE协议报文携带显式拥塞通知ECN)下的两种确认报文的示意图，确认报文包括对所述RoCE协议报文的确认信息、指示信息和拥塞信息，该确认信息可实现现有的ACK确认的功能，即通告源端设备的RNIC其发送的报文是否已被目的端设备成功传输，该指示信息用于指示源端设备和目的端设备之间的网络通路发生拥塞，拥塞信息用于指示网络的具体状态，具体可包括网络通路的拥塞程度、拥塞位置、报文队列长度、网络时延等等中的至少一种信息。
如图7所示，一种实施例中，确认报文实现为确认报文C，确认报文C中的确认信息、指示信息和拥塞信息可设置在报文中的不同位置，例如可以分布在不同的报文头中，从而避免对确认信息中字段做修改。又一种实施例中，确认报文实现为确认报文D，可将该指示信息和/或拥塞信息整合设置到确认信息的字段中，从而实现对确认信息中字段空间的充分利用。
本申请实施例中，指示信息可以是指示位、指示字段、指示标识等。
例如，当指示信息是指示位时，当指示位的值为0，意味着向源端设备的RNIC指示当前网络通路中没有网络拥塞的情况，确认报文中不携带拥塞信息；当指示位的值为1，意味着目的端设备向源端设备的RNIC指示当前网络通路中存在网络拥塞的情况，且确认报文中携带了拥塞信息。
又例如，指示信息可以利用现有字段进行功能重定义，比如指示信息可以是确认报文的BTH.BECN字段，当BTH.BECN字段为0，意味着向源端设备的RNIC指示当前网络通路中没有网络拥塞的情况，确认报文中不携带拥塞信息；当BTH.BECN字段为1，意味着向源端设备的RNIC指示当前网络通路中存在网络拥塞的情况，且确认报文中携带了拥塞信息。
本申请实施例中，拥塞信息可以是定义的一个新的报文头(如下面描述的CETH)进行内容承载，支持携带详细的网络拥塞状态内容，以便于目的端设备向源端设备进行准确的网络拥塞通告。拥塞信息也可以是利用现有的字段空间进行内容承载，例如利用现有的保留(reserve)字段。
下面描述本申请实施例提供的一种拥塞信息的设计方式。参见图8，图8是本申请实施例提供的一种拥塞信息的数据结构示例图，本文中可将拥塞信息的数据结构称为拥塞控制扩展传输头(Congestion Extended Transport Header，CETH)。如图8所示，该CETH(也可以称为CETH头)包括标准定义和厂家自定义信息(Vender defined information)这两部分，其中标准定义部分可用于混合组网场景的兼容性对接。标准定义部分可包括如下字段：版本号(Ver)、CETH头长度(Length)。其中：
厂家自定义信息字段用于支持各厂家自定义拥塞控制通告信息，总长度为例如为(Length*4–1)字节。例如厂家可以设计承载网络通路的拥塞程度、拥塞位置、报文队列长度、网络时延中的至少一种信息。举例来说，网络通路的拥塞程度可用2bit的ratio字段表征，该ratio字段用于标识拥塞程度。在应用场景中，ratio字段可以分量级来指示拥塞程度，例如：无拥塞、轻度拥塞、中度拥塞、重度拥塞，等等。
此外，在具体实现中，还可以对厂家自定义信息设计更多的其他内容，例如设计的1bit的字段来指示当前的拥塞通告为普通CNP类型还是增强CNP类型。又例如可以设计4bit的字段来用于标识业务场景，例如RC/XRC write/send场景、RC/XRC read response场景或UD send场景。
Ver字段用于指示CETH版本号，例如可占用4bit，用于支持拥塞控制算法的升级及兼容性对接。其中，版本号0表示标准CNP通告，未携带其它信息，版本号1～15由厂家自定义使用。
Length字段用于指示CETH头长度，例如占用4bit，支持CETH头可变长度，以减少固定开销。Length例如可取值1～4，用于指示CETH头长度为多少个4字节。
基于上述的指示信息和拥塞信息，下面描述一些可能的确认报文的数据结构。
参见图9，图9是本申请提供的一种确认报文的数据结构示意图。如图9所示，确认报文具体包括ACK确认信息和CETH，其中：
ACK确认信息具体包括了基础传输头(BaseTransport Header，简称BTH，或称BTH头，或称BTH字段)和确认扩展传输头(Acknowledge Extended Transport Header，AETH)，即ACK确认信息可通过BTH和AETH承载，该ACK确认信息用于实现ACK的功能，即通告源端设备的RNIC其发送的报文是否已被目的端设备成功传输。该实施例中，用于指示源端设备和目的端设备之间的网络通路是否发生拥塞的指示信息也可承载于BTH字段。
关于BTH和AETH的相关子字段(例如OpCode、SE、目标QP、Pad、TVer等等字段)可参考现有技术方案的相关描述，这里不再展开描述。
CETH是本申请设计的扩展字段，本实施例中可以将CETH作为一个可选项聚合到ACK的AETH后面，从而实现ACK确认信息、指示信息和CETH的聚合。CETH用于指示当前网络通路的具体网络状态。当网络拥塞发生时，ACK携带指示信息并且聚合CETH，以便于目的端设备及时向源端设备通告网络拥塞的发生，当网络无拥塞时，ACK携带指示信息而不携带CETH，以便于目的端设备及时向源端设备通告拥塞的消除。
由于CETH携带了网络通路的拥塞程度、拥塞位置、报文队列长度、网络时延等网络状态信息，有利于解决现有RoCE网络由于拥塞控制通告的信息少而对实现高效的拥塞控制不友好的问题。由于报文的聚合以及指示信息的携带，也有利于解决RoCE网络拥塞控制反应速度慢的问题。
具体应用场景中，当目的端设备的RNIC接收到的RoCE协议报文不携带ECN标记时，目的端设备的RNIC向源端设备回复一个不携带CETH头的ACK，该ACK即只包括了确认信息和指示信息，以通告源端设备的RNIC其协议报文已被接收且网络上未发生拥塞。
当目的端设备的RNIC接收到的RoCE协议报文携带ECN标记时，目的端设备的RNIC向源端设备回复一个携带CETH头的ACK，该ACK即包括了确认信息、指示信息和拥塞信息，以通告源端设备的RNIC其协议报文已被接收且网络上发生了拥塞，并使得源端设备的RNIC获得详细的网络状态信息，例如拥塞程度、拥塞点、队列深度、网络时延等不同维度的信息，从而能根据这些信息实现定量化的拥塞控制。
例如，对于拥塞信息中指示的网络拥塞程度，可以分为“无拥塞、轻度拥塞、中度拥塞、重度拥塞”等多个级别，源端设备的RNIC可以根据拥塞程度的差异来决定如何实施降速处理，实现不同档次的报文发送速率的调节，因而可以实现更快的速率收敛。
又例如，对于拥塞点和队列深度信息，源端设备的RNIC可以根据该类信息判断该网络路径上还可以承载多少数据报文而不导致发生丢包等行为，从而决定可以继续发送的报文数量，这对高带宽需求的网络应用比较友好。
参见图10，图10是本申请提供的另一种确认报文的数据结构示意图。在该实施例中，CETH(拥塞信息)可利用现有的字段空间进行承载。如图10所示，CETH被整合到ACK确认信息的BTH字段中，该实施例中，用于指示源端设备和目的端设备之间的网络通路是否发生拥塞的指示信息也可承载于BTH字段。这种情况下，该确认报文可视为传统ACK报文的改进，充分利用现有字段空间实现拥塞信息的承载。该确认报文既能实现ACK的功能，即通告源端设备的RNIC其发送的报文是否已被目的端设备成功传输；又能实现拥塞指示功能，即指示源端设备和目的端设备之间的网络通路是否发生拥塞。还能使得源端设备的RNIC获得详细的网络状态信息，例如拥塞程度、拥塞点、队列深度、网络时延等不同维度的信息，从而能根据这些信息实现定量化的拥塞控制。
例如，在一种实现中，可利用传统ACK的BTH中的保留字段“reserved 6”去承载本申请实施例的拥塞信息，也就是该“reserved 6”作为第一CETH进行相关数据承载，从而达到拥塞控制和传输确认的聚合的目的。
又例如，在一种实现中，可利用传统ACK的BTH中的保留字段“reserved 7”去承载本申请实施例的拥塞信息，也就是该“reserved 7”作为第二CETH进行相关数据承载，从而达到拥塞控制和传输确认的聚合的目的。
其中，第一CETH和第二CETH的具体实现形式可以是仅包括拥塞程度、拥塞点、队列深度、网络时延等信息，还可以包括如图8实施例描述的其他信息，例如版本号等。
参考图11和图12，图11和图12分别示例性描述了本申请实施例中的一些RoCE协议报文完整形式和对应的确认报文的完整形式。
如图11所示，一种来自源端设备的RoCE协议报文可包括MAC报文头、IP报文头、UDP报文头、BTH头、数据载荷、不变循环冗余校验值(Invariant CyclicRedundancy Check，ICRC)和可变循环冗余校验值(Variant CyclicRedundancy Check，VCRC)。其中MAC报文头、IP报文头、UDP报文头分别是MAC层、IP层、UDP层对应的报文头，数据载荷为设备通信交互需要传输的数据，ICRC和VCRC可用于校验数据完整性。又一种RoCE协议报文可包括MAC报文头、IP报文头、UDP报文头、BTH头、ImmDt字段、数据载荷、ICRC和VCRC。
需要说明的是，实际应用中，RoCE协议报文还可以包括更多或更少的内容，本申请对此不做限制。
如图12所示，一种来自目的端设备的确认报文可包括MAC报文头、IP报文头、UDP报文头、BTH头、AETH头、CETH头、ICRC和VCRC。其中MAC报文头、IP报文头、UDP报文头分别是MAC层、IP层、UDP层对应的报文头，ICRC和VCRC可用于校验数据完整性，关于这里的BTH头、AETH头、CETH头的具体内容和实现形式可类似参考图9实施例的相关描述，这里不再赘述。又一种确认报文可包括MAC报文头、IP报文头、UDP报文头、BTH头、AETH头、ICRC和VCRC。关于这里的BTH头、AETH头的具体内容和实现形式可类似参考图10实施例的相关描述，这里不再赘述。
需要说明的是，实际应用中，确认报文还可以包括更多或更少的内容，本申请对此不做限制。例如可能实现中，在CETH后面还可以有SACK(code b010)头，等等。
基于上文描述的系统架构和报文数据结构，下面描述本申请实施例提供的拥塞控制方法。对于下文描述的各方法实施例，为了方便起见，将其都表述为一系列的动作步骤的组合，但是本邻域技术人员应该知悉，本申请技术方案的具体实现并不受所描述的一系列的动作步骤的顺序的限制。
参见图13，图13是本申请实施例提供的一种RoCE网络拥塞控制的方法的流程示意图，该方法从第一网络设备和第二网络设备交互的角度进行方案描述，其中第一网络设备和第二网络设备可以是RNIC、网络接口控制器、网络适配器、网卡、局域网接收器等等。例如，第一网络设备可以是源端设备的RNIC，第二网络设备可以是目的端设备的RNIC，第一网络设备和第二网络设备可通过网络连接。该方法包括但不限于以下步骤：
S301.第一网络设备向第二网络设备发送RoCE协议报文。所述RoCE协议报文可以是基于用户的业务需求而产生的，RoCE协议报文可以是周期性的报文。RoCE协议报文的具体内容已在前文做了描述，这里不再赘述。
S302.第二网络设备检查所述RoCE协议报文是否携带显式拥塞通知。
当网络中的流量因为过大而产生拥塞时，网络中的CP设备可对报文进行RED ECN标记，第二网络设备在收到携带ECN标记的报文时，确认网络当前有拥塞。反之，第二网络设备在收到携带ECN标记的报文时，确认网络当前无拥塞。
S303.第二网络设备根据检查结果生成ACK确认报文，所述ACK确认报文至少包括聚合的确认信息和指示信息。所述指示信息用于指示所述第一网络设备与所述第二网络设备之间的网络通路是否发生拥塞。
本申请实施例中，指示信息可以是指示位、指示字段、指示标识等。例如，当指示信息是指示位时，当指示位的值为0，意味着向源端设备的RNIC指示当前网络通路中没有网络拥塞的情况，确认报文中不携带拥塞信息；当指示位的值为1，意味着目的端设备向源端设备的RNIC指示当前网络通路中存在网络拥塞的情况，且确认报文中携带了拥塞信息。
一种实施例中，确认信息和指示信息可设置在报文中的不同位置，例如可以分布在不同的报文头中，从而避免对确认信息中字段做修改。又一种实施例中，可将该指示信息整合设置到确认信息的字段中，从而实现对确认信息中字段空间的充分利用。
S304.第二网络设备向所述第一网络设备回复所述确认报文，相应的，所述第一网络设备接收来自第二网络设备的确认报文。
S305.第一网络设备基于所述确认报文进行拥塞控制。
本申请实施例中，拥塞控制是一种用来调整传输控制协议(RoCE协议)连接单次发送的分组数量(单次发送量)的功能，它能够定量的增减单次报文发送量和发送频率，使之逼近当前网络最合适的承载能力。例如，当指示信息指示当前网络有拥塞时，第一网络设备可降低下一时间窗内的RoCE协议报文的发送速率。当指示信息指示当前网络无拥塞时，第一网络设备可将下一时间窗内的RoCE协议报文的发送速率维持不变，或者将下一时间窗内的RoCE协议报文的发送速率设置为预设速率。
可以看到，实施本申请实施例，目的端设备可以在RoCE协议报文携带ECN标记时，通过第二网络设备回复聚合有指示信息的ACK确认信息，指示信息用于向源端设备通告当前网络通路上有网络拥塞。源端设备的第一网络设备可降低下一时间窗内的RoCE协议报文的发送速率。目的端设备可以在RoCE协议报文未携带ECN标记时，回复携带有指示信息的ACK确认信息，向源端设备通告当前网络通路上无网络拥塞，以便于源端设备及时维持或恢复高速发送速率。
这样，一方面，通过指示信息和ACK的聚合承载，避免了独立CNP的发送，降低了通告的开销，有利降低大流量场景下拥塞通告的时延，提高了目的端设备的反应速度。
另一方面，通过指示信息，源端设备可以在第一时间可以获得网络拥塞的情况，更早的触发拥塞控制实现发送速率的调控，提高了源端设备的响应速度。在网路拥塞解除时，也能够通过指示信息让源端设备获知，以及时恢复发送速率，提高了网路带宽利用率。
参见图14，图14是本申请实施例提供的又一种RoCE网络拥塞控制的方法的流程示意图，该方法从第一网络设备和第二网络设备交互的角度进行方案描述，其中第一网络设备和第二网络设备可以是RNIC、网络接口控制器、网络适配器、网卡、局域网接收器等等。例如，第一网络设备可以是源端设备的RNIC，第二网络设备可以是目的端设备的RNIC，第一网络设备和第二网络设备可通过网络连接。该方法包括但不限于以下步骤：
S401.第一网络设备向第二网络设备发送RoCE协议报文。RoCE协议报文的具体内容已在前文做了描述，这里不再赘述。
S402.第二网络设备检查所述RoCE协议报文是否携带显式拥塞通知(ECN)。当确定RoCE协议报文携带显式拥塞通知时，第二网络设备后续执行步骤S403-S405；当确定RoCE协议报文不携带显式拥塞通知时，第二网络设备后续执行步骤S406-S407。
S403.第二网络设备获取拥塞信息，拥塞信息用于指示网络的具体状态。
具体的，第二网络设备当前网络有拥塞时，可通过报文检测或者硬件检测的方式获得网络状态信息，例如拥塞程度、拥塞点、队列深度、网络时延等不同维度的信息。
举例来说，当所述拥塞信息包括所述拥塞程度时，所述第二网络设备可通过以下获得所述拥塞程度：
(1)第二网络设备根据历史报文接收记录中携带显式拥塞通知的RoCE协议报文的比例，来确定所述网络通路的拥塞程度。例如，第二网络设备对接收报文携带ECN标记的比例做周期性滑窗统计，从而计算出当前该网络路径的具体拥塞程度。
(2)通过借助带内网络遥测(Inband Network Telemetry，INT)方式或者通过现场运行管理和维护(In-situ Operation Administration and Maintenance，IOAM)方式获得所述拥塞程度。以INT方式为例，可将INT支持的范围扩展到服务器网卡，网卡就可以接收到交换机插入到数据报文内的测量信息，通过该信息可以计算获得当前网络状态，例如通过时间戳计算出网络时延，通过队列长度和队列占用率计算出拥塞程度，等等。
S404.第二网络设备生成确认报文，所述确认报文包括聚合的确认信息、指示信息和拥塞信息。拥塞信息例如可通过本文描述的CETH实现，该CETH可以是扩展字段，也可以利用现有的保留字段来实现。
其中，确认信息用于实现ACK的功能，指示信息用于指示源端设备和目的端设备之间的网络通路发生拥塞。
一种实施例中，确认报文中的确认信息、指示信息和拥塞信息可设置在报文中的不同位置，例如可以分布在不同的报文头中，从而避免对确认信息中字段做修改。
又一种实施例中，可将该指示信息和/或拥塞信息整合设置到确认信息的字段中，从而实现对确认信息中字段空间的充分利用。
关于确认信息、指示信息和拥塞信息的聚合可参考图9或图10实施例的描述，这里不再赘述。
S405.第二网络设备向所述第一网络设备发送S404的确认报文。
S406.第二网络设备生成确认报文，所述确认报文包括聚合的确认信息和指示信息。
其中，确认信息用于实现ACK的功能，指示信息用于指示源端设备和目的端设备之间的网络通路没有发生拥塞。
S407.第二网络设备向所述第一网络设备发送S406的确认报文。
S408.第一网络设备基于所述确认报文进行定量的拥塞控制。
具体的，当第一网络设备收到S405的确认报文后，根据指示信息确定当前网络有拥塞，第一网络设备可根据确认报文中的拥塞信息进行拥塞控制包括以下至少一种方式：
(1)第一网络设备可根据所述拥塞程度，定量调整所述第一网络设备的下一时间窗内的报文的发送速率，其中所述拥塞程度和所述发送速率之间具有对应关系。例如对于“无拥塞、轻度拥塞、中度拥塞、重度拥塞”等多个级别，第一网络设备可以根据拥塞程度的差异来决定如何实施降速处理。不同级别可以对应不同的报文发送速率，实现不同档次的报文发送速率的调节，因而可以实现更快的速率收敛。
(2)第一网络设备可根据拥塞位置和报文队列深度中的至少一者，确定下一时间窗内的待发送的报文数量。源端设备的RNIC可以根据该拥塞位置和/或报文队列深度判断该网络路径上还可以承载多少数据报文而不导致发生丢包等行为，从而决定可以继续发送的报文数量，这对高带宽需求的网络应用比较友好。
(3)所述第一网络设备可根据网络时延调整所述第一网络设备的发送速率或下一时间窗内的待发送的报文数量。
当第一网络设备收到S407的确认报文后，根据指示信息确定当前网络无拥塞，第一网络设备可将下一时间窗内的RoCE协议报文的发送速率维持不变，或者将下一时间窗内的RoCE协议报文的发送速率恢复/设置为预设速率。
综合上文实施例可知，本申请的方案能够实现将RoCE的拥塞控制通告与ACK确认信息聚合承载，通过指示信息来通告网络拥塞的产生和消除。在有网络拥塞时，定义的CETH承载详细的网络拥塞状态信息。具体的，如图15所示：
当网络存在拥塞时，目的端设备接收到的报文携带ECN标记(记为data w/ECN)，本申请实施例重定义用于回复的ACK消息为ACK聚合CETH(记为ACK w/CETH)，在AETH头后扩展携带CETH头，携带量化的拥塞信息。原有的RC、XRC、RD等应用场景连接的RDMA write、RDMAsend的CNP都可聚合到ACK上，所以本申请实施例中，目的端设备将无需再单独回复CNP给源端设备。
当网络的拥塞消除时，目的端设备接收到的报文不携带ECN标记(记为data w/oECN)，本申请实施例重定义用于回复的ACK消息为ACK不聚合CETH(记为ACK w/o CETH)，以使远端设备获知当前网络状态，从而快速恢复发送速率。
下面以图16为例进一步理解本申请方案的技术效果。图16示例性示出了一种网络大流量场景下的设备通信流程。如图16所示，数据报文1发生了网络拥塞，目的端设备将RoCE的拥塞通告CETH聚合到ACK确认报文后，在发生拥塞时源端设备获得的拥塞通告更快，从而能更快速地进行拥塞控制动作，例如图16中从协议报文4开始就进入降速状态了，相比于前述图3的独立CNP通告方法而言，报文发送速率可以更快降速；该聚合方法还可以支持目的端设备使用ACK中的指示信息来通告源端设备该网络拥塞状态的消除，源端设备收到拥塞消除通告后，即可快速提高报文发送速率，如图16中从数据报文8开始就可以恢复发送速率，相比现有的依赖源端设备的周期性检测方法而言，报文发送速率可以更快升速。
另外，由于扩展了准确详细的拥塞通告信息，在降速的第一个周期即可准确的控制降低发送速率到目标速率，实现更快的收敛，如图16中，在收到拥塞通告信息A后，第一个发送的数据报文4即可快速收敛到目标速率。
可以看到，实施本申请实施例，目的端设备的第二网络设备可以在RoCE协议报文携带ECN标记时，回复聚合有CETH和指示信息的ACK确认信息，指示信息用于向源端设备通告当前网络通路上有网络拥塞，CETH用于向源端设备提供详细的拥塞信息。源端设备的第一网络设备从CETH提取拥塞信息进行定量、多样化的拥塞控制动作。目的端设备可以在RoCE协议报文未携带ECN标记时，则回复携带有指示信息的ACK确认信息，向源端设备通告当前网络通路上无网络拥塞，以便于源端设备及时维持或恢复高速发送速率。
这样，一方面，通过指示信息、拥塞信息和ACK的聚合承载，避免了独立CNP的发送，降低了通告的开销，有利降低大流量场景下拥塞通告的时延，提高了目的端设备的反应速度。
另一方面，通过指示信息，源端设备可以在第一时间可以获得网络拥塞的情况，更早的触发拥塞控制实现发送速率的调控，提高了源端设备的响应速度。在网路拥塞解除时，也能够通过指示信息让源端设备获知，以及时恢复发送速率，提高了网路带宽利用率。
最后，现有的RDMA网络拥塞控制的通告信息少，网络拥塞收敛速度慢，而本申请利用CETH承载网络详细的拥塞信息，例如拥塞程度、拥塞点、队列深度、网络时延等不同维度的信息，有利于源端设备根据详细拥塞信息将发送速率一步到位的调整到目标速率，实现快速收敛，并实现报文数量、发送时间等多样化的调整，极大提升了拥塞控制的效果。
应理解，在本申请的各种方法实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
在上述实施例中，对各个实施例的描述各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
另外，在本申请各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random accessmemory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
上述实施例仅用以说明本申请的技术方案，而非对其限制。尽管参照上述实施例对本申请进行了详细的说明，本领域的普通技术人员还应当理解的是：任何基于对上述各实施例所记载的技术方案进行的改动、变形、或者对其中部分技术特征进行的等同替换均应属于本申请各实施例技术方案的精神和范围。

Claims (32)

1.一种RoCE网络拥塞控制的方法，其特征在于，所述方法包括：
第一网络设备向第二网络设备发送RoCE协议报文；
所述第一网络设备接收来自第二网络设备的确认报文，所述确认报文包括对所述RoCE协议报文的确认信息和指示信息，所述指示信息用于指示所述第一网络设备与所述第二网络设备之间的网络通路是否发生拥塞；
所述第一网络设备基于所述确认报文进行拥塞控制。
2.根据权利要求1所述的方法，其特征在于，在所述指示信息指示所述网络通路发生拥塞的情况下，所述确认报文还包括拥塞信息，所述拥塞信息具体包括所述网络通路的拥塞程度、拥塞位置、报文队列长度、网络时延中的至少一种信息；
所述第一网络设备基于所述确认报文进行拥塞控制，具体包括：
所述第一网络设备根据所述拥塞信息进行拥塞控制。
3.根据权利要求2所述的方法，其特征在于，所述第一网络设备根据所述拥塞信息进行拥塞控制包括以下至少一种方式：
所述第一网络设备根据所述拥塞程度，调整所述第一网络设备的发送速率，其中所述拥塞程度和所述发送速率之间具有对应关系；或者，
所述第一网络设备根据所述拥塞位置和所述报文队列深度中的至少一者，确定下一时间窗内待发送的报文数量；或者，
所述第一网络设备根据所述网络时延调整所述第一网络设备的发送速率或确定下一时间窗内待发送的报文数量。
4.根据权利要求3所述的方法，其特征在于，所述拥塞程度属于多种不同级别拥塞程度中的一种，不同级别拥塞程度分别对应不同的发送速率。
5.根据权利要求2-4任一项所述的方法，其特征在于，所述确认报文具体包括基础传输头(BTH)字段和扩展字段，所述确认信息和所述指示信息承载于所述BTH字段，所述拥塞信息承载于所述扩展字段。
6.根据权利要求2-4任一项所述的方法，其特征在于，所述确认报文具体包括BTH字段，所述确认信息、所述指示信息和所述拥塞信息均承载于所述BTH字段。
7.根据权利要求1-6任一项所述的方法，其特征在于，在所述指示信息指示所述网络通路未发生拥塞的情况下，所述第一网络设备基于所述确认报文进行拥塞控制包括：
所述第一网络设备将所述第一网络设备的发送速率维持不变。
8.根据权利要求1-6任一项所述的方法，其特征在于，在所述指示信息指示所述网络通路未发生拥塞的情况下，所述第一网络设备基于所述确认报文进行拥塞控制包括：
所述第一网络设备将所述第一网络设备的发送速率设置为预设速率。
9.一种RoCE网络拥塞控制的方法，其特征在于，所述方法包括：
第二网络设备接收第一网络设备的RoCE协议报文；
所述第二网络设备检查所述RoCE协议报文是否携带显式拥塞通知；
所述第二网络设备根据检查结果生成确认报文，所述确认报文包括对所述RoCE协议报文的确认信息和指示信息，所述指示信息用于指示所述第一网络设备与所述第二网络设备之间的网络通路是否发生拥塞；
所述第二网络设备向所述第一网络设备发送所述确认报文，所述确认报文用于所述第一网络设备进行拥塞控制。
10.根据权利要求9所述的方法，其特征在于，在所述指示信息指示所述网络通路发生拥塞的情况下，所述确认报文还包括拥塞信息，所述拥塞信息具体包括所述网络通路的拥塞程度、拥塞位置、报文队列长度、网络时延中的至少一种信息；所述拥塞信息用于所述第一网络设备进行拥塞控制。
11.根据权利要求10所述的方法，其特征在于，所述拥塞程度属于多种不同级别拥塞程度中的一种，不同级别拥塞程度分别对应所述第一网络设备不同的发送速率。
12.根据权利要求10或11所述的方法，其特征在于，所述第二网络设备根据检查结果生成确认报文之前，还包括：
所述第二网络设备生成所述拥塞信息。
13.根据权利要求10-12任一项所述的方法，其特征在于，当所述拥塞信息包括所述拥塞程度时，所述第二网络设备通过以下至少一种方式获得所述拥塞程度：
所述第二网络设备根据历史报文接收记录中携带显式拥塞通知的RoCE协议报文的比例，来确定所述拥塞程度；或者，
通过带内网络遥测(INT)方式获得所述拥塞程度；或者，
通过现场运行管理和维护(IOAM)方式获得所述拥塞程度。
14.根据权利要求10-13任一项所述的方法，其特征在于，所述确认报文具体包括基础传输头(BTH)字段和扩展字段，所述确认信息和所述指示信息承载于所述BTH字段，所述拥塞信息承载于所述扩展字段。
15.根据权利要求10-14任一项所述的方法，其特征在于，所述确认报文具体包括BTH字段，所述确认信息、所述指示信息和所述拥塞信息均承载于所述BTH字段。
16.一种装置，其特征在于，所述装置应用于第一网络设备，包括：
报文发送模块，用于向第二网络设备发送RoCE协议报文；
报文接收模块，用于接收来自第二网络设备的确认报文，所述确认报文包括对所述RoCE协议报文的确认信息和指示信息，所述指示信息用于指示所述第一网络设备与所述第二网络设备之间的网络通路是否发生拥塞；
拥塞控制模块，用于基于所述确认报文进行拥塞控制。
17.根据权利要求16所述的装置，其特征在于，在所述指示信息指示所述网络通路发生拥塞的情况下，所述确认报文还包括拥塞信息，所述拥塞信息具体包括所述网络通路的拥塞程度、拥塞位置、报文队列长度、网络时延中的至少一种信息；
所述拥塞控制模块具体用于，根据所述拥塞信息进行拥塞控制。
18.根据权利要求17所述的装置，其特征在于，所述拥塞控制模块具体用于：
根据所述拥塞程度，调整所述第一网络设备的发送速率，其中所述拥塞程度和所述发送速率之间具有对应关系；或者，
根据所述拥塞位置和所述报文队列深度中的至少一者，确定下一时间窗内待发送的报文数量；或者，
根据所述网络时延调整所述第一网络设备的发送速率或确定下一时间窗内待发送的报文数量。
19.根据权利要求18所述的装置，其特征在于，所述拥塞程度属于多种不同级别拥塞程度中的一种，不同级别拥塞程度分别对应不同的发送速率。
20.根据权利要求17-19任一项所述的装置，其特征在于，所述确认报文具体包括基础传输头(BTH)字段和扩展字段，所述确认信息和所述指示信息承载于所述BTH字段，所述拥塞信息承载于所述扩展字段。
21.根据权利要求17-19任一项所述的装置，其特征在于，所述确认报文具体包括BTH字段，所述确认信息、所述指示信息和所述拥塞信息均承载于所述BTH字段。
22.根据权利要求16-21任一项所述的装置，其特征在于，所述拥塞控制模块具体用于，在所述指示信息指示所述网络通路未发生拥塞的情况下，将所述第一网络设备的发送速率维持不变。
23.根据权利要求16-21任一项所述的装置，其特征在于，所述拥塞控制模块具体用于，在所述指示信息指示所述网络通路未发生拥塞的情况下，将所述第一网络设备的发送速率设置为预设速率。
24.一种装置，其特征在于，所述装置应用于第二网络设备，包括：
报文接收模块，用于接收第一网络设备的RoCE协议报文；
拥塞信息确定模块，用于检查所述RoCE协议报文是否携带显式拥塞通知；
通告聚合发送模块，用于根据检查结果生成确认报文，所述确认报文包括对所述RoCE协议报文的确认信息和指示信息，所述指示信息用于指示所述第一网络设备与所述第二网络设备之间的网络通路是否发生拥塞；还用于向所述第一网络设备发送所述确认报文，所述确认报文用于所述第一网络设备进行拥塞控制。
25.根据权利要求24所述的装置，其特征在于，在所述指示信息指示所述网络通路发生拥塞的情况下，所述确认报文还包括拥塞信息，所述拥塞信息具体包括所述网络通路的拥塞程度、拥塞位置、报文队列长度、网络时延中的至少一种信息；所述拥塞信息用于所述第一网络设备进行拥塞控制。
26.根据权利要求25所述的装置，其特征在于，所述拥塞程度属于多种不同级别拥塞程度中的一种，不同级别拥塞程度分别对应所述第一网络设备不同的发送速率。
27.根据权利要求25或26所述的装置，其特征在于，所述拥塞信息确定模块还用于生成所述拥塞信息。
28.根据权利要求25-27任一项所述的装置，其特征在于，当所述拥塞信息包括所述拥塞程度时，所述拥塞信息确定模块具体用于：
根据历史报文接收记录中携带显式拥塞通知的RoCE协议报文的比例，来确定所述拥塞程度；或者，
通过带内网络遥测(INT)方式获得所述拥塞程度；或者，
通过现场运行管理和维护(IOAM)方式获得所述拥塞程度。
29.根据权利要求25-28任一项所述的装置，其特征在于，所述确认报文具体包括基础传输头(BTH)字段和扩展字段，所述确认信息和所述指示信息承载于所述BTH字段，所述拥塞信息承载于所述扩展字段。
30.根据权利要求25-29任一项所述的装置，其特征在于，所述确认报文具体包括BTH字段，所述确认信息、所述指示信息和所述拥塞信息均承载于所述BTH字段。
31.一种设备，其特征在于，所述设备包括主机系统和第一网络设备；所述主机系统用于与所述第一网络设备交互实现数据传输，所述第一网络设备用于执行如权利要求1-8任一项所述的方法。
32.一种设备，其特征在于，所述设备包括主机系统和第二网络设备；所述主机系统用于与所述第二网络设备交互实现数据传输，所述第二网络设备用于执行如权利要求9-15任一项所述的方法。
CN202010915720.6A 2020-09-03 2020-09-03 RoCE网络拥塞控制的方法及相关装置 Pending CN114143827A (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202010915720.6A CN114143827A (zh) 2020-09-03 2020-09-03 RoCE网络拥塞控制的方法及相关装置
EP21863709.8A EP4195760A4 (en) 2020-09-03 2021-09-03 ROCE NETWORK CONGESTION MANAGEMENT METHOD AND RELATED APPARATUS
PCT/CN2021/116494 WO2022048647A1 (zh) 2020-09-03 2021-09-03 RoCE网络拥塞控制的方法及相关装置
US18/178,117 US20230208771A1 (en) 2020-09-03 2023-03-03 RoCE Network Congestion Control Method and Related Apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010915720.6A CN114143827A (zh) 2020-09-03 2020-09-03 RoCE网络拥塞控制的方法及相关装置

Publications (1)

Publication Number Publication Date
CN114143827A true CN114143827A (zh) 2022-03-04

Family

ID=80438127

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010915720.6A Pending CN114143827A (zh) 2020-09-03 2020-09-03 RoCE网络拥塞控制的方法及相关装置

Country Status (4)

Country Link
US (1) US20230208771A1 (zh)
EP (1) EP4195760A4 (zh)
CN (1) CN114143827A (zh)
WO (1) WO2022048647A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115002240A (zh) * 2022-08-04 2022-09-02 深圳市星卡软件技术开发有限公司 一种数据传输系统、方法、装置、设备及介质
CN116760779A (zh) * 2023-08-21 2023-09-15 珠海星云智联科技有限公司 网络拥塞控制方法、系统、存储介质和电子设备
CN116915721A (zh) * 2023-09-12 2023-10-20 珠海星云智联科技有限公司 一种拥塞控制方法、装置、计算设备及可读存储介质

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114745331B (zh) * 2022-03-23 2023-11-07 新华三技术有限公司合肥分公司 一种拥塞通知方法及设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107135164A (zh) * 2017-06-27 2017-09-05 中国联合网络通信集团有限公司 拥塞控制方法及装置
US20190044861A1 (en) * 2018-09-26 2019-02-07 Intel Corporation Technologies for congestion control for ip-routable rdma over converged ethernet
US20190116126A1 (en) * 2016-06-13 2019-04-18 Huawei Technologies Co., Ltd. Network Congestion Control Method, Device, and System
CN110445722A (zh) * 2018-05-04 2019-11-12 华为技术有限公司 拥塞控制方法、装置、设备及存储介质
US20200145349A1 (en) * 2018-11-06 2020-05-07 Mellanox Technologies, Ltd. Managing congestion in a network adapter based on host bus performance
CN111431811A (zh) * 2019-01-10 2020-07-17 华为技术有限公司 一种报文传输控制方法、装置和网络设备

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110505112B (zh) * 2019-07-09 2021-06-22 星融元数据技术(苏州)有限公司 一种网络性能监测方法、装置和存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190116126A1 (en) * 2016-06-13 2019-04-18 Huawei Technologies Co., Ltd. Network Congestion Control Method, Device, and System
CN107135164A (zh) * 2017-06-27 2017-09-05 中国联合网络通信集团有限公司 拥塞控制方法及装置
CN110445722A (zh) * 2018-05-04 2019-11-12 华为技术有限公司 拥塞控制方法、装置、设备及存储介质
US20190044861A1 (en) * 2018-09-26 2019-02-07 Intel Corporation Technologies for congestion control for ip-routable rdma over converged ethernet
US20200145349A1 (en) * 2018-11-06 2020-05-07 Mellanox Technologies, Ltd. Managing congestion in a network adapter based on host bus performance
CN111431811A (zh) * 2019-01-10 2020-07-17 华为技术有限公司 一种报文传输控制方法、装置和网络设备

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115002240A (zh) * 2022-08-04 2022-09-02 深圳市星卡软件技术开发有限公司 一种数据传输系统、方法、装置、设备及介质
CN115002240B (zh) * 2022-08-04 2022-12-16 深圳市星卡软件技术开发有限公司 一种数据传输系统、方法、装置、设备及介质
CN116760779A (zh) * 2023-08-21 2023-09-15 珠海星云智联科技有限公司 网络拥塞控制方法、系统、存储介质和电子设备
CN116915721A (zh) * 2023-09-12 2023-10-20 珠海星云智联科技有限公司 一种拥塞控制方法、装置、计算设备及可读存储介质
CN116915721B (zh) * 2023-09-12 2023-12-19 珠海星云智联科技有限公司 一种拥塞控制方法、装置、计算设备及可读存储介质

Also Published As

Publication number Publication date
EP4195760A4 (en) 2024-02-07
WO2022048647A1 (zh) 2022-03-10
EP4195760A1 (en) 2023-06-14
US20230208771A1 (en) 2023-06-29

Similar Documents

Publication Publication Date Title
CN114143827A (zh) RoCE网络拥塞控制的方法及相关装置
EP3694165A1 (en) Managing congestion in a network
US7412488B2 (en) Setting up a delegated TCP connection for hardware-optimized processing
EP3716546A1 (en) Data transmission method and first device
US7492710B2 (en) Packet flow control
US7430220B2 (en) System load based dynamic segmentation for network interface cards
CN103902486A (zh) 一种远端直接内存访问实现方法、装置及系统
US20130227184A1 (en) Low latency interconnect bus protocol
CN106487896A (zh) 用于处理远程直接内存访问请求的方法和装置
EP2699030B1 (en) Route switching device, network switching system and route switching method
KR101865261B1 (ko) 입력 출력 데이터 정렬
CN114826495A (zh) 一种降低nr、rlc、am分片丢失报告开销的方法
CN113973091A (zh) 一种报文处理方法、网络设备以及相关设备
CN113794713B (zh) Fc-ae-1553协议桥接mil-std-1553和uart的通讯处理方法
EP4214858A2 (en) Data frame interface network device
WO2021136278A1 (zh) 报文传输方法及电子设备
CN111200594B (zh) 接收数据的方法、装置、数据接收设备和存储介质
WO2024041572A1 (zh) 业务处理方法、装置、设备、介质及程序产品
US20230367728A1 (en) Link width adjustment method and apparatus
JP2019220791A (ja) 通信装置、通信装置の制御方法、及びプログラム
WO2023048925A1 (en) Network resource monitoring

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination