CN112383622A - 用于数据中心联网的可靠传输协议和硬件架构 - Google Patents

用于数据中心联网的可靠传输协议和硬件架构 Download PDF

Info

Publication number
CN112383622A
CN112383622A CN202011269309.2A CN202011269309A CN112383622A CN 112383622 A CN112383622 A CN 112383622A CN 202011269309 A CN202011269309 A CN 202011269309A CN 112383622 A CN112383622 A CN 112383622A
Authority
CN
China
Prior art keywords
entity
initiator
target
packet
packets
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
CN202011269309.2A
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.)
Google LLC
Original Assignee
Google LLC
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 Google LLC filed Critical Google LLC
Publication of CN112383622A publication Critical patent/CN112383622A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1832—Details of sliding window management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services

Abstract

本公开涉及用于数据中心联网的可靠传输协议和硬件架构。提供了一种用于可靠地传输分组的通信协议系统。就此而言，发起者实体可以确定传出数据将被传送到目标实体。发起者实体可以将请求将传出数据放置在目标实体处的索求的推送请求传送到目标实体。发起者实体可以从目标实体接收响应于该索求的推送请求的推送授权。响应于该推送授权，发起者实体可以将要放置在目标实体处的传出数据传送到目标实体。

Description

用于数据中心联网的可靠传输协议和硬件架构
相关申请的交叉引用
本申请要求2019年12月12日提交的美国临时专利申请 No.62/947,036的提交日期的权益，其公开内容通过引用结合于此。
技术领域
本公开涉及用于数据中心联网的可靠传输协议和硬件架构。
背景技术
互联网协议套件是用于服务在通过互联网或其他计算机网络传达信息的两个设备之间的数据传输的一组通信协议。传输控制协议(“TCP”)是互联网协议套件的一部分，提供了通过局域网或广域网，在例如在客户端设备上运行的Web浏览器应用与在服务器设备上运行的Web服务器应用之间提供数据分组流的面向连接的、可靠的和有序的传递。当前，使用通信协议(诸如TCP)的数据中心遇到某些问题。例如，聚播(incast)是数据中心中常见的多对一通信模式，这当多个同步计算设备并行将数据发送到同一接收者计算设备时可能会导致聚播拥塞。此外，因为当前通信协议要求通过连接有序地传递分组，所以长尾延迟(其是用于要传送的一系列分组中的最后几个分组的时间量)可能会阻止传送下一系列的分组。
发明内容
本公开提供：由发起者实体确定要将传出数据传送到目标实体；由发起者实体将请求将所述传出数据放置在目标实体处的索求的推送请求(solicited push request)传送到目标实体；由发起者实体从目标实体接收响应于所述索求的推送请求的推送授权；以及由发起者实体响应于所述推送授权，将要放置在目标实体处的传出数据传送到目标实体。
该方法可以进一步包括：由发起者实体确定传出数据的大小满足预定阈值，其中，传送所述索求的推送请求是基于传出数据的大小满足预定阈值的确定。该推送请求可以源自发起者实体的上层协议，基于该发起者实体的上层协议，发起者实体的可靠传输协议层通过发起者实体与目标实体之间的连接，将所述索求的推送请求作为分组来传送。
该方法可以进一步包括：由发起者实体确定传出数据的大小不满足预定阈值；以及在不发送所述索求的推送请求或接收推送授权的情况下，由发起者实体传送要放置在目标实体处的传出数据。该推送请求可以源自发起者实体的上层协议，基于该发起者实体的上层协议，发起者实体的可靠传输协议层通过发起者实体与目标实体之间的连接，将传送数据作为分组来发送。
该方法可以进一步包括：由发起者实体从目标实体接收指示传出数据被接收到并且被放置在目标实体处的确认。
该方法可以进一步包括：由发起者实体确定需要来自目标实体的传入数据；由发起者实体将请求将传入数据传送到发起者实体的拉取请求传送到目标实体；由发起者实体从目标实体接收响应于该拉取请求的传入数据。该方法可以进一步包括由发起者实体基于一个或多个拥塞参数来排程针对传入数据的该拉取请求。
本公开进一步提供：由发送者实体通过到接收者实体的连接按第一顺序传送多个分组；由发送者实体维护包括多个位的至少一个滑动窗口，其中，该滑动窗口的每个位表示所述多个分组中的相应分组；由发送者实体接收指示接收者实体已经接收到所述多个分组中的一个或多个分组的一个或多个确认，每个确认均引用所述多个分组中的相应分组，其中，这些确认按与第一顺序不同的第二顺序被接收；以及由发送者实体修改滑动窗口中的所述多个位中的与接收到的所述一个或多个确认相对应的一个或多个位的值。
该方法可以进一步包括：由发送者实体基于一个或多个拥塞参数来调整滑动窗口的大小。
所述多个分组可以包括以下中的一项或多项：对数据分组的请求、数据分组、确认。所述至少一个滑动窗口可以包括请求滑动窗口。所述至少一个滑动窗口可以包括数据滑动窗口。所述多个分组可以包括响应于拉取请求的至少一个数据分组。所述多个分组可以包括响应于索求的推送请求的至少一个推送授权分组。
本公开还进一步提供：由发起者实体通过连接将多个分组传送到目标实体；由发起者实体确定在预定时间段内既未接收到响应于所述多个分组中的特定分组的确认也未接收到否定确认；由发起者实体基于该确定，将该特定分组重传到目标实体；由发起者实体从目标实体响应于该重传接收否定确认；以及由发起者实体基于该否定确认，确定是等待对该特定分组的确认还是重新同步。
该方法可以进一步包括：由发起者实体确定该否定确认指示针对该特定分组该目标实体尚未就绪；响应于该否定确认，在不将该特定分组再次重传到目标实体的情况下，由发起者实体等待来自目标实体的确认。
该方法可以进一步包括：由发起者实体确定该否定确认指示目标实体错误地完成了对该特定分组的操作；以及由发起者实体在不断开连接的情况下将重新同步分组传送到目标实体。该方法可以进一步包括：由发起者实体从目标实体接收响应于该重新同步分组的确认；由发起者实体响应于对该重新同步分组的确认，传送随后的多个分组。
该多个分组可以根据来自发起者实体的上层协议的请求被传送，并且该特定分组的重传通过发起者实体的可靠传输协议层来执行。
附图说明
图1是根据本技术的方面的网络的示意图。
图2是根据本技术的方面的示例性系统的框图。
图3是根据本技术的方面的通信层的框图。
图4示出了根据本技术的方面的示例性滑动窗口。
图5是根据本技术的方面的拉取事务的示例性时序图。
图6是根据本技术的方面的主动请求(unsolicited)的推送事务的示例性时序图。
图7是根据本技术的方面的索求(solicited)的推送事务的示例性时序图。
图8是根据本技术的方面的有序事务的示例性时序图。
图9是根据本技术的方面的无序事务的示例性时序图。
图10是根据本技术的方面的涉及否定确认的示例性时序图。
图11是根据本技术的方面的涉及错误完成确认的示例性时序图。
图12A示出了根据本技术的方面的示例性基本报头。
图12B示出了根据本技术的方面的用于图10的示例性基本报头的示例性定义。
图13A、13B和13C示出了根据本技术的方面的示例性请求和授权报头。
图13D、13E和13F示出了根据本技术的方面的分别用于图13A、 13B和13C的示例性报头的示例性定义。
图14A、14B和14C示出了根据本技术的方面的示例性数据报头。
图15A示出了根据本技术的方面的示例性重新同步报头。
图15B示出了根据本技术的方面的用于图15A的示例性重新同步报头的示例性定义。
图16A示出了根据本技术的方面的示例性否定确认报头。
图16B示出了根据本技术的方面的用于图16A的示例性否定确认报头的示例性定义。
图17A示出了根据本技术的方面的示例性错误完成确认报头。
图17B示出了根据本技术的方面的用于图17A的示例性错误完成确认报头的示例性定义。
图18是根据本技术的方面的示例性流程图。
具体实施方式
本技术通常涉及用于通过连接可靠地传输分组的通信协议。本技术提供了基于请求的推送事务，其提供了对传入数据的接收者实体控制，从而减少了聚播拥塞和尾延迟。本技术进一步使用滑动窗口和位图，支持通过连接的无序事务处理，这可以提高通过连接处理分组的整体效率。该技术进一步提供了对失败传输的处理，这减少重传尝试并且使用重新同步来防止连接断开，从而导致更弹性连接。
图1示出了示例性网络100。网络100包括各种实体，诸如实体A、实体B和实体C。为了彼此通信，在实体之间形成连接，诸如实体A 和B之间的连接110，以及实体A和C之间的连接120。实体可以使用一种或多种协议，通过该连接通信。例如，可靠传输(RT)协议是告知发送者是否成功将数据传递到预期接收者的协议。发送者和接收者被视为通信协议的对等方，因此实体A和B可以是可靠的传输对等方，而实体A和C可以是可靠的传输对等方。使用可靠传输协议的连接是描述两个可靠传输对等方之间的双向通信信道的端到端构造。
连接可以由一对连接ID(“CID”)标识，每个通信方向上一个连接ID。CID可以在连接建立过程期间由接收者实体分配，并且在涉及的各方之外没有全局意义。因此，实体A和B之间的连接110对从 A到B的方向，可以具有值为5的CID，以及对从B到A方向，具有值为10的CID。实体A和C之间的连接120对从A到C的方向，可以具有值为5的CID，以及对从C到A的方向，具有值为11的CID。此外，由实体分配的CID或实体的“源CID”必须具有不同的值。因此，在所示的示例中，由实体A分配的CID或实体A的源CID具有不同的值10和11。相反，实体的“目的地CID”由其他实体分配并且可以具有相同的值。因此，在所示的示例中，实体A的目的地CID分别由实体B和C分配，它们可以具有相同的值5。
可以通过实体之间的连接来传送分组。就此而言，分组是跨连接的通信的基本单元。分组可以具有预定大小，例如长度高达最大传输单元(“MTU”)。分组可以具有报头，该报头包括关于分组及其传输的信息以及数据的有效载荷。为了确保可靠传输，可靠传输分组可以包括诸如在报头中的目的地CID。例如，当实体B通过具有为5的目的地CID的连接110接收分组时，实体B可以将该分组标识为来自实体A，然后可以通过引用该分组及其CID为5的连接110发送确认来告知A已经接收到该分组。确认本身可以被发送为包括目的地CID 为10的分组。
实体A、B和C可以是能够通过网络进行通信的任何类型的设备，诸如个人计算设备、服务器计算设备、移动设备、可穿戴设备、虚拟机等。图2是可以使用可靠的传输协议进行通信的示例性系统200中的一些组件的框图。系统200包括至少两个实体，在它们之间具有一个或多个连接。不应当视为限制本公开的范围或本文所述的特征的有用性。在该示例中，系统200被示为具有两个实体、一个或多个计算设备210和一个或多个计算设备260，它们之间具有连接250。例如，计算设备210可以是图1的实体A，而计算设备260可以是图1的实体B，以及连接250可以是图1的连接110。计算设备210和260可以被配置有所示的相似组件，或者可以包括其他和/或不同的组件。在所示的示例中，计算设备210包含一个或多个处理器220和存储器230。
一个或多个处理器220可以是任何常规处理器，诸如商业上可获得的CPU。替选地，处理器可以是专用组件，诸如专用集成电路(“ASIC”)或其他基于硬件的处理器。尽管不是必须的，但是一个或多个计算设备210可以包括执行特定计算过程的专用硬件组件。
存储器230可以是能够存储可由处理器访问的信息的任何非暂时性类型，诸如硬盘驱动器、存储卡、ROM、RAM、DVD、CD-ROM、可写入和只读存储器。计算设备210的存储器230可以存储可由一个或多个处理器220访问的信息，包括数据232和指令234。
存储器230可以包括可以由处理器220检索、操纵或存储的数据 232。例如，如参考图1和图3-17B所述的诸如通信协议的数据、诸如 CID的连接信息、报头的定义等可以由处理器220检索、操纵或存储。
计算设备210的存储器230还可以存储可以由一个或多个处理器 220执行的指令234。例如，根据存储器230中的指令234和数据232，可以由一个或多个处理器220执行诸如参考图1和3-11所述的通信协议的指令以及图18的流程图。
数据232可以根据指令234，由一个或多个处理器220检索、存储或修改。例如，尽管本文所述的主题不受任何特定数据结构的限制，但是可以将数据存储在计算机寄存器中、作为具有许多不同字段和记录或XML文档的表的关系数据库中。数据也可以以任何计算设备可读格式进行格式化，诸如但不限于二进制值、ASCII或Unicode。此外，数据可以包括足以识别相关信息的任何信息，诸如数字、描述性文本、专有代码、指针、对存储在其他存储器中(诸如在其他网络位置处) 的数据的引用，或可以由计算相关数据的函数使用的信息。
指令234可以是将由一个或多个处理器直接执行的任何指令集，诸如机器代码，或间接执行的任何指令集，诸如脚本。就此而言，术语“指令”、“应用”、“步骤”和“程序”在本文中可以互换使用。指令可以以目标代码格式存储以供处理器直接处理，或者以任何其他计算设备语言存储，包括按需解释或预先编译的脚本或独立源代码模块的集合。
尽管未示出，但是计算设备210可以进一步包括通常存在于通用计算设备中的其他组件。例如，计算设备210可以包括输出设备，诸如显示器(例如，具有屏幕、触摸屏、投影仪、电视的监视器或可操作来显示信息的其他设备)、扬声器、触觉反馈等。计算设备210还可以包括用户输入设备，诸如鼠标、键盘、触摸屏、麦克风、传感器等。
尽管图2在功能上将处理器、存储器和计算设备210的其他元件示为位于同一块内，但是处理器、计算机计算设备或存储器实际上可以包括多个处理器、计算机、计算设备或存储器，它们可能会或可能不会存放在同一物理壳体内。例如，存储器可以是位于不同于计算设备210的壳体中的硬盘驱动器或其他存储介质。因此，对处理器、计算机、计算设备或存储器的引用将被理解为包括对可以并行运行或可以不并行运行的处理器、计算机、计算设备或存储器的集合的引用。例如，计算设备210可以包括操作为负载平衡服务器场、分布式系统等的服务器计算设备。此外，尽管下文所述的一些功能被指示为发生在具有单个处理器的单个计算设备上，但是本文所述的主题的各方面可以由多个计算设备来实现，例如，通过网络传送信息。
计算设备210可以能够与网络的其他实体(诸如计算设备260) 直接和间接通信。计算设备210和260可以使用各种协议和系统互连，使得网络中的计算设备可以是互联网、万维网、特定内联网、广域网或局域网的一部分。网络中的计算设备可以利用标准通信协议，诸如以太网、WiFi和HTTP、一个或多个公司专有的协议以及前述的各种组合。尽管当如上所述传送或接收信息时获得了某些优点，但是本文所述的主题的其他方面不限于信息传输的任何特定方式。
返回图1，可以使用一种或多种通信协议，通过连接在实体A、B 和/或C之间传送分组。图3示出了示例性通信协议系统300。通信协议系统300可以例如通过图2的处理器220和270，在网络中的两个或以上实体，诸如图1的网络100的实体A、B、C中的两个或以上实体上实现。如所示，每个实体可以包括多层通信协议。例如，实体A可以包括上层协议(“ULP”)310和可靠传输(“RT”)协议330，而实体B可以包括上层协议320和可靠传输协议层340。可以在每层的协议之间形成对等方。因此，ULP 310和ULP 320是ULP对等方，并且可靠传输协议层330和可靠传输协议层340是RT对等方。进一步如所示，在每个实体内，上层协议被配置为与可靠传输协议通信。
如参考图4-11所述，上层协议310、320可以负责实现硬件/软件接口、消息的处理、完成通知和/或端到端流量控制。上层协议可以在多个硬件或软件设备中的任何一个上实现。例如，上层协议可以被实现为远程直接存储器访问(“RDMA”)。作为另一示例，上层协议可以被实现为非易失性存储器接口规范(“NVMe”)。
还参考图4-11描述，可靠传输协议330、340可以负责分组的可靠传递、拥塞控制、准入控制和/或分组的有序或无序传递。每个可靠传输协议330、340可以在逻辑上被划分为协议的两个子层。因此，如所示，可靠传输协议层330被划分为负责端点准入控制以及可选地，分组的有序传递的请求子层332，以及负责端到端的可靠传递和拥塞控制的滑动窗口子层334。同样地，可靠传输协议层340还被划分为请求子层342和滑动窗口子层344。
图4示出了示例性滑动窗口410和420。滑动窗口410和420由实体使用来跟踪将通过连接传送和确认的预定数量的分组。例如，实体A可以使用TX滑动窗口410以用于跟踪通过连接110发送给实体B 的分组，并且使用RX滑动窗口420以用于跟踪从实体B接收到的分组。这样，滑动窗口410和420可以分别在作为图3的可靠传输协议层330的一部分的滑动窗口子层334中实现。TX滑动窗口和RX滑动窗口可以具有如所示的不同大小，或者可以替选地具有相同的大小。
参考TX滑动窗口410，为了跟踪分组，发送者实体A为每个分组分配了分组序列号(“PSN”)。如所示，位数从左向右增加。接收者实体B可以通过向发送者实体A传达其在该滑动窗口内在确认分组中接收到的PSN，来确认其在该滑动窗口内已经接收到分组。就此而言，可以在发送者实体A和接收者实体B两者上提供序列号位图。序列号位图的每一位表示该实体处的滑动窗口内的一个分组。例如，对于TX滑动窗口410，如果已确认发送分组，则将位设置为1。否则，该位为0。一旦接收并确认了TX滑动窗口410内的所有分组，则发送者实体A可以将滑动窗口410向前移动至将传送的下一组分组。一旦确认了基本序列号分组，滑动窗口就会向前移动，因此，参考图4中的示例，一旦标记了最左边的0，则滑动窗口将移动一个，一旦标记了最左边第二个0，则滑动窗口将移动另一个，并且一旦标记了第三个0，则移动3个(因为已经设置了后面两位)。
用于发送者实体的PSN可以包括基本序列号(“BSN”)和下一序列号(“NSN”)。如所示，BSN是尚未由接收者实体B确认的最旧分组的PSN值。此外，如所示，NSN是应当分配给通过连接传送给接收者实体B的下一分组的PSN值。例如，当从ULP 310接收到分组以用于传输时，可以将当前PSN更新为NSN。然后，当通过连接传送分组时，例如可以通过NSN＝(NSN+1)mod 232，递增NSN。这样，在滑动窗口410内，位0表示BSN的PSN值，而位n表示(BSN+n) 的PSN值。
尽管未示出，但是接收器实体还可以保持一个或多个滑动窗口。例如，接收机实体B可以为接收到的分组保留RX滑动窗口，其中，每一位代表通过滑动窗口接收到的分组。如果该分组已经被接收者实体B接收到，则该位被设置为1。否则，该位为0。接收者实体B还可以使用PSN来跟踪接收到的分组。例如，BSN可以是接收者实体尚未接收到的最旧分组的PSN值。当接收到具有BSN的PSN值的分组时，例如，可以使用BSN＝(BSN+1)mod 232，将BSN更新为尚未接收到的分组的下一个最低PSN。BSN的更新可以清除序列号位图中、对应于从前一BSN到PSN的分组的位。这样，在用于接收机实体B的RX滑动窗口内，位0表示BSN的PSN值，而位n表示(BSN+n)的PSN值。因为发送者实体A未确认由接收者实体B发送的确认，即，不将PSN 用于确认分组，所以接收者实体B无需为其发送的确认保留TX滑动窗口。
发送者实体和接收者实体可以根据一组规则来处理分组和相应的确认。例如，如果接收到的分组中的接收者BSN小于发送者实体的 BSN，则发送者实体会丢弃ACK信息；否则，发送者实体更新其BSN 以匹配接收者实体的BSN。发送者实体在调整其BSN之后将通过其自己的序列号位图在该ACK分组中对接收者实体的序列号位图应用OR (“或”)运算。在分组被传送之后，其由发送者实体缓冲，直到它被接收者实体确认为止。关于失败分组的重传，发送者实体可以被配置为释放分配给重传缓冲器中的所有ACK分组的资源。此外，在每个分组重传计时器届满时，发送者实体重传具有与原始分组相同的PSN 的分组，并且递增该分组的重传计数器。
接收者实体还可以实施许多规则。例如，如果接收到的分组的PSN 值小于接收到的分组的BSN，则接收者实体将丢弃该分组，并且发送具有当前BSN的ACK分组。如果PSN值落在接收者实体的滑动窗口内，则接收者实体通过将位置(PSN-BSN)的位设置为1来更新序列号位图。如果位置(PSN-BSN)的位已为1，则该分组被丢弃；否则，将该分组传递到接收者实体的ULP，并且递增累积ACK计数器。如果接收到的分组的PSN等于接收到的分组的BSN，则接收器实体将BSN 更新为等于还未接收到的下一个最高PSN。
注意，因为根据位图跟踪分组，所以滑动窗口被配置为允许实体跟踪在相应的滑动窗口内无序接收和/或确认的分组。因此，如所示，尽管由位3和4表示的分组可以在由位0、1、2表示的分组之前被实体A发送，但是由位3和4表示的分组可以在TX滑动窗口410中在由位0、1、2表示的分组之前被接收和/或确认。
可以通过监视分组重传和/或分组往返延迟来检测网络拥塞。为了执行拥塞控制，可以调节一个或多个滑动窗口的尺寸。例如，如果拥塞高，则实体B接收和/或确认TX滑动窗口410内的所有分组可能花费更长的时间。这样，为了减少拥塞，可以通过减小滑动窗口410的尺寸，减少网络中未完成分组的数量。除了改变滑动窗口的大小或作为改变滑动窗口的大小的替代，可以调整响应于网络拥塞状态的重传定时器到期值。例如，重传频率较低可以减少网络拥塞。
图3的通信协议系统300可以支持各种事务，包括拉取和推送事务。图3的通信协议系统300可以被配置为使用发起者-目标方法来执行事务，其中，“发起者”是请求事务的实体，而“目标”是响应该请求的实体。这样的事务可以涉及要在发起者和目标实体之间传送的多个分组，因此，发起者和目标实体可能是事务中的分组的发送者和接收者，并且可以使用TX和/或RX滑动窗口来跟踪分组和/或确认，如参考图4所述。图5示出了根据本技术的方面的拉取事务的示例性时序图，而图6和7示出了根据本技术的方面的推送事务的示例性时序图。图5-7的示例性时序图可以由网络中的两个实体(诸如图1的连接110上的实体A和B，例如由图2的处理器220和270)来实现。
参考图5，示出了用于示例性拉取事务的时序图500。拉取事务可以被用来从其他实体“拉取”传入数据分组，例如用于读取操作。如所示，通过发起者实体和目标实体两者的各种通信协议层执行拉取事务。例如，实体A可以是发起者实体，且发起者ULP 510和发起者RT 530可以是被配置为图3的上层协议310和可靠传输协议层330的通信协议层，而实体B可以是目标实体并且目标ULP 520和目标RT 540 可以是被配置为图3的上层协议320和可靠传输协议层340的通信协议层。
如所示，拉取请求(“pullReq”)源自发起者实体A，例如源自发起者ULP 510，其被发送至发起者RT 530。发起者实体A可以将 pullReq发送至例如通过连接110从其请求传入数据的目标实体B。这可以由相应的RT执行，因此，所示的发起者RT 530将pullReq发送到目标RT 540。一旦pullReq被目标实体B接收到之后，目标RT 540 随后将pullReq发送到目标ULP 520以请求许可。然后，目标ULP 520 可以向目标RT 540发送确认pullReq的确认消息(“ULP-ACK”)，以及指示目标RT 540拉取所请求的数据的拉取响应(“pullResp”)。响应于pullResp，目标RT 540可以拉取所请求的数据(“pullData”)，并且例如通过连接110，将所拉取的数据发送到发起者RT 530。一旦发起者RT 530接收到所请求的数据时，发起者RT530可以将pullResp 发送到发起者ULP 510，使得发起者ULP 510可以放置或存储所接收的数据分组。
如参考图1所述，发起者实体A和目标实体B可以通过传送分组来彼此通信。因此，pullReq和pullData可以分别是通过连接110传送的、由相应的RT传递的分组。进一步参考图4所述，可以通过滑动窗口来跟踪可靠传输分组。这样，pullReq分组可以是实体A保持的请求 TX滑动窗口的一部分(由虚线所示)，而pullData分组可以是实体B 保持的数据TX滑动窗口的一部分(由点划线表示)。这些分组中的每一个可以是需要确认的可靠传输分组。例如，尽管未示出，但是实体B 可以将ACK发送到引用pullReq分组的PSN的实体A，该实体A可以使用请求TX滑动窗口跟踪pullReq分组。类似地，实体A可以将ACK 发送到引用pullData分组的PSN的实体B，该实体B可以使用数据TX 滑动窗口跟踪pullData分组。
如图5所示，拉取事务允许发起者实体执行端到端流量控制。特别地，发起者ULP可以通过速率限制pullReq分组来限制未完成的拉取数据的数量和/或总额以执行端到端流量控制，这可以防止网络中聚播引起的拥塞。这样，可以避免聚播拥塞。例如，发起者ULP可以被配置为基于不请求同时来自多个实体的数据分组的调度来请求传入数据分组。此外，发起者RT可以被配置为执行准入控制以限制未完成的拉取数据的总额。
参考图6，示出了示例性主动请求的推送事务的时序图600。推送事务可以被用来将传出数据分组“推送”到其他实体，例如用于写入操作。如所示，通过发起者实体和目标实体两者的各种通信协议层执行推送事务。例如，实体A可以是发起者实体，并且发起者ULP610 和发起者RT 630可以是被配置为图3的上层协议310和可靠传输协议层330的通信协议层，而实体B可以是目标实体并且目标ULP 620和目标RT 640可以是被配置为图3的上层协议320和可靠传输协议层340 的通信协议层。
如所示，推送请求(“pushReq”)可以源自发起者实体A，例如源自发起者ULP 610，其被发送至发起者RT 630。发起者实体A随后可以例如通过连接110，将主动请求的数据推送至目标实体B。这可以由相应的RT执行，由此示出发起者RT 630将主动请求的数据(“pushUnslctdData”)推送到目标RT 640。该数据是主动请求的，因为目标实体B没有请求该数据。一旦目标实体B接收到该数据，目标RT 640就可以请求将接收到的数据放置或存储在目标实体B处，并且通过将pushReq发送给目标ULP 620来进行。作为响应，目标ULP 620可以放置或存储接收到的数据，然后向目标RT 640发送确认消息 ULP-ACK，该确认消息确认根据pushReq已经放置或存储了接收到的数据。为了可靠传输，目标实体B发送确认消息(“ACK”)以告知发起者实体A例如通过连接110接收和放置了推送数据。这由相应的 RT执行，由此如所示，目标RT 640将ACK消息发送到发起者RT 630。一旦发起者RT 630接收到ACK消息，发起者RT 630就可以向发起者 ULP 610发送推送完成消息(“pushCmpl”)以告知数据分组已经被目标实体接收和放置。
如参考图1所述，发起者实体A和目标实体B可以通过传送分组来彼此通信。因此，pushUnslctdData和ACK可以分别是通过连接110 传送的分组。进一步地，如参考图4所述，可以通过滑动窗口来跟踪可靠传输分组。这样，pushUnslctdData分组可以是由实体A保持的数据TX滑动窗口的一部分(由点划线表示)。为了可靠传输，由实体B 发送的ACK分组可以引用pushUnslctdData的PSN，实体A可以使用数据TX滑动窗口跟踪该PSN。确认消息(诸如ACK分组)(由虚线表示)不是可靠传输分组，因此可能不是发送者实体B处的任何滑动窗口的一部分。但是，由于确认是累积的，也就是说，针对分组接收到的ACK将指示对滑动窗口内的所有在前分组，还必须已经发送了 ACK-不必使ACK消息可靠。
如图6所示，主动请求的推送事务允许告知发起者实体不仅推送数据分组被接收而且其已经被目标实体放置或存储。在某些情况下，发起者实体可以等待直到在推送另一数据分组之前，目标实体接收和放置推送数据分组为止。PushUnslctdData提供了较低事务延迟，但是，如果多个发起者正发送到同一目标，则仍可能在网络中发生聚播。可以通过限制由pushUnslctdData支持的请求大小来减轻这种聚播风险。
与图6相反，图7示出了用于索求的推送事务的时序图700。如所示，推送事务由发起者实体和目标实体两者的各种通信协议层执行。例如，实体A可以是发起者实体，并且发起者ULP 710和发起者RT 730 可以是被配置为图3的上层协议310和可靠传输协议层330的通信协议层，而实体B可以是目标实体，并且目标ULP 720和目标RT 740 可以是被配置为图3的上层320和可靠传输协议层340的通信协议层。
与图6相似，图7示出了pushReq可以源自发起者ULP 710处的发起者实体A，其可以被发送到发起者RT 730。但是，与时序图600 相比，此时发起者RT 730不会发送将要推送到目标实体B的分组。然而，例如，通过连接110，仅将请求发送到目标实体B，请求可以由目标实体B授权或可能未被授权。该请求和授权过程或“请求”过程可以由相应的RT执行，例如，可以由其相应的请求子层执行。因此，发起者RT 730被示为向目标RT 740发送推送请求(“pushSlctdReq”)，并且目标RT 740可以决定是否和/或何时授权pushSlctdReq。从请求的角度来看，目标pushGnt与发起者pullReq类似。例如，实体B可以限制未完成的已授权pushSlctdData的总数，以防止向实体B进行聚播，导致网络拥塞。如果并且当目标RT 740授权该请求时，目标RT 740 可以将推送授权(“pushGrnt”)发送回发起者RT 730。
一旦发起者实体A接收到pushGrnt，发起者实体A可以例如通过连接110，将索求的数据推送到目标实体B。这可以由相应的RT来执行，因此发起者RT 730示为将索求的数据推送到目标RT 740。与图6 中推送的主动请求的数据相比，在此的数据由来自目标RT 740的pushGrnt有效地请求。一旦pushGrnt被发起者RT 730接收，时序图的其余部分类似于图6。因此，目标RT 740可以将对在目标实体B处放置或存储接收到的数据的pushReq发送到目标ULP 720。作为响应，目标ULP 720可以放置或存储接收到的数据，然后向目标RT 740发送ULP-ACK消息，以确认已经根据pushReq放置了接收到的数据。为了可靠传输，目标实体B通过目标RT 740发送ACK消息，以告知发起者实体A例如通过到发起者RT 730的连接110，接收和放置了所推送的数据。一旦发起者RT 730接收到ACK消息之后，发起者RT 730可以将pushCmpl消息发送到发起者ULP 710，以告知数据分组已经被目标实体B接收并放置。
如参考图1所述，发起者实体A和目标实体B可以通过传送分组来彼此通信。因此，pushSlctdReq、pushGrnt、pushSlctdData和ACK 可以分别是通过连接110传送的分组。进一步，如参考图4所述，可以通过滑动窗口来跟踪可靠传输分组。这样，pushSlctdReq可以是由实体A保持的请求TX滑动窗口的一部分(由虚线表示)，pushGrnt分组可以是由实体B保持的数据TX滑动窗口的一部分(由点划线表示)，以及pushSlctdData分组可以是实体A保持的数据TX滑动窗口的一部分(由点划线表示)。为了可靠传输，实体B发送的ACK分组可以引用pushSlctdData的PSN，实体A可以使用数据TX滑动窗口跟踪该 PSN。类似地，尽管未示出，但是实体A可以发送用于pushGrnt分组的ACK，实体B可以使用其数据TX滑动窗口跟踪该ACK，并且实体 B可以发送用于pushSlctdReq的ACK，实体A可以使用其请求TX滑动窗口跟踪该ACK。但是，确认消息(诸如所示的ACK分组(用虚线表示))不是可靠传输分组，因此可能不是发送者实体B处的任何滑动窗口的一部分。
如图7所示，索求的推送事务允许发起者实体在真正发送数据之前请求授权以发送来自目标实体的数据。这样，目标实体可以有权控制传入数据，这在多个发起者实体正试图将数据推送到目标实体上时，以及如果推送的数据很大或如果网络拥塞时尤其有用。由于聚播拥塞可能由不是像传送时一样快地传递到接收者的分组和/或由正尝试同时向同一实体发送分组的多个实体引起，所以这种请求过程可以减少聚播拥塞。
在某些情况下，通信协议系统可以被配置为执行图6和7所示的推送事务之一，而在其他情况下，通信协议系统可以被配置为执行两个推送事务。在通信协议系统被配置为执行两个推送事务的情况下，该系统可以被配置为基于一个或多个因素来确定使用哪个推送事务。例如，发起者RT可以确定推送请求应当被发送为索求的请求(solicited request)还是主动请求的请求(unsolicited request)。发起者RT可以基于来自发起者ULP的推送请求的长度来确定是发送索求的推送请求还是主动请求的推送。作为示例，如果推送请求需要推送大量数据，诸如满足预定大小阈值，则可以使用索求的推送请求来确保该较大请求不会引起拥塞；否则可以使用索求的推送。作为另一个示例，是使用索求的请求还是主动请求的推送可以基于网络条件，诸如拥塞等级，其中，当拥塞满足预定阈值级别时可以使用索求的请求。
在另一方面，图3的通信协议系统300可以通过连接支持有序和无序事务。就此而言，图8示出了根据本技术的方面的用于通过连接的有序事务的示例性时序图，以及图9示出了根据本技术的方面的用于通过连接的无序事务的示例性时序图。图8-9的示例性时序图可以由网络中的两个实体(诸如通过图1的连接110的实体A和B)例如通过图2的处理器220和270实现。
参考图8，可以由发起者实体和目标实体两者的各种通信协议层来执行各种事务，诸如上文参考图5-7所述的拉取事务和推送事务。例如，实体A可以是发起者实体，并且发起者ULP 810和发起者RT 830 可以是被配置为图3的上层协议310和可靠传输协议层330的通信协议层，而实体B可以是目标实体并且目标ULP 820和目标RT 840可以是被配置为图3的上层协议320和可靠传输协议层340的通信协议层。
参考时序图800，许多请求可以源自发起者实体A，包括拉取请求 (诸如pullReq_1)和推送请求(诸如pushReq_0、pushReq_2和 pushReq_3)。如上所述，这些请求可以由发起者ULP 810发送到发起者RT 830。一旦发起者RT 830接收到这些请求，发起者RT 830就可以可选地确定是否应当将推送请求作为被索求的(solicited)或未被索求(unsolicited)的来发送，如上参考图7所述。因此，在该示例中，发起者RT 830可以确定pushReq_0和pushReq_2将被作为被索求的来发送，而pushReq_3将被作为未被索求的来发送。然后，发起者RT 830 可以例如通过连接110，将这些拉取请求和推送请求发送到目标RT 840。
请求可以由发起者ULP 810以如由请求序列号(“RSN”)指示的特定顺序发送，该RSN可以由发起者ULP 810分配。在某些情况下，发起者RT 830也可以将索求的序列号(“SSN”)专门分配给索求的推送请求，SSN可以是如所示的增量编号。当请求被发送为两个实体之间的分组时，可以根据RSN的顺序，以升序为请求分配数字序列。因此，如所示，可以根据RSN，在由发起者实体A维护的一个或多个 TX滑动窗口内为请求分配PSN。例如，在(由指向B的虚线所示的) 实体A的请求TX滑动窗口内，将pushSlctdReq_0分配PSN＝0，将pullReq_1分配PSN＝1，将pushSlctdReq_2分配PSN＝2。注意，由于来自发起者ULP 810的pushReq_3不需要如图5所示的请求，因此，没有在RT之间发送的相应的pushUnslctdReq。尽管ULP可能知道RSN 和SSN，但ULP可能不知道PSN，而只能由分组中的RT使用。
响应于索求的推送请求，目标RT 840可以按接收到的请求的顺序，将推送授权发送到发起者RT 830，诸如pushGnt_0和pushGnt_2。可以根据与推送请求的RSN相同的顺序，在由目标实体B维护的一个或多个TX滑动窗口内，按升序来向推送授权分配PSN。例如，在(由指向A的虚线所示的)实体B的数据TX滑动窗口内，为pushGrnt_0 分配了PSN＝1000，以及为pushGrnt_2分配了PSN＝1001。然而，发起者RT 830可能没有按与推送请求的传输顺序相同的顺序来接收推送授权。因此，如所示，在pushGrnt_0之前，发起者RT 830接收到pushGrnt_2。
尽管如此，发起者RT 830可以基于他们相应的PSN，确定推送授权的正确顺序，并且基于该顺序来推送数据分组。这样，尽管在 pushGrnt_0之前，发起者RT 830接收到pushGrnt_2，但是发起者RT 830 可以首先利用pushSlctdData_0推送由pushGrnt_0所请求的数据，然后利用pushSlctdData_2将由pushGrnt_2所请求的数据推送到目标RT 840。还根据传输顺序，在由发起者实体A维护的一个或多个TX滑动窗口内，按升序为推送数据分组分配了PSN。例如，在(由指向B的点划线表示的)实体A的数据TX滑动窗口内，为pushSlctdData_0分配了PSN＝200，以及为pushSlctdData_2分配了PSN＝201。注意，pushReq_3不需要授权，如参考图6所述，因此，如由弯曲的箭头所示，直接跳到pushUnslctdData_3，后者推送了主动请求的数据。在该示例中，也在实体A的数据TX滑动窗口中，为pushUnslctdData_3分配了 PSN＝202。
目标RT 840接收请求，然后按ULP-Req-0-1-2-3的顺序，将相应的请求发送到目标ULP 820，该顺序与来自在时序图800的顶部处所示的发起者ULP 810的请求的传输顺序相同。如上参考图5-7所述，这些ULP-Req要求目标ULP 820许可拉取数据或将所推送的数据放置在目标实体B处。注意，拉取请求pullReq_1不需要授权，如参考图5 所述，因此，如由弯曲箭头所示，直接跳到ULP-Req。响应于ULP-Req，如上参考图5-7所述，目标ULP 820可以向目标RT 840发送确认 ULP-ACK。在该有序系统中，按ULP-ACK-0-1-2-3的顺序发送 ULP-ACK，该顺序与来自发起者ULP 810的请求的传输顺序相同。
在ULP-ACK之后，关于推送事务，然后将确认数据分组的ACK (或数据确认)由目标RT 840发送到发起者RT 830，以通知可靠传输数据分组的安全接收和放置。作为示例，实体B发送ACK-eBSN＝3,203 以通知实体A已经接收并放置了多达PSN＝3的所有请求分组和多达 PSN＝203的所有数据分组。一旦接收到ACK，发起者RT 830可以将完成消息pushCompl_0发送给发起者ULP 810。此外，在某些情况下，可以在其他可靠传输分组上适当地搭载确认分组。例如，请求 pushSlctdReq_0、pullReq_1和pushSlctdReq_2是需要ACK的可靠传输分组，但是对这些请求的确认(或请求ACK)未在时序图800中明确地示出，因为它们可能会搭载在诸如pushGrnt_0和pushGrnt_2的可靠传输分组上。
同样在ULP-ACK之后，也可以响应拉取请求。因此，如所示，目标ULP 820可以发送pullResp_1，其指示目标RT 840拉取所请求的数据。然后，目标RT 840利用pullData_1，将所拉取的数据发送到发起者RT 830。在该示例中，在与(如由指向A的点划线所示的)pushGrnts 相同的实体B的数据TX滑动窗口内，为pullData_1分配了PSN＝1002。然后，发起者RT 830将pullResp_1发送给发起者ULP 810，使得发起者ULP 810可以将接收到的数据分组放置或存储在实体A处。在将数据分组放置或存储在实体A之后，可以发送确认以通知实体B安全接收。因此，如所示，实体A发送ACK-eBSN＝3,203以通知实体已经安全接收到pullData_1分组。
在该有序系统中，在时序图800底部附近，由发起者ULP 810接收到的完成消息的顺序与在时序图800顶部附近，由发起者ULP 810 发送的请求的顺序相同。在发起者和目标实体两者的ULP上都维护了该顺序，其中，目标RT按与发起者ULP向发起者RT发送请求的相同顺序，向目标ULP提出请求。该有序系统确保了通过连接传递请求一次且仅一次。相反，可能没有通过连接在不同方向上进行的事务之间的有序要求。
图9示出了根据本技术的方面的用于通过连接的无序事务的示例性时序图900。时序图900可以由发起者实体和目标实体两者的各种通信协议层执行。例如，实体A可以是发起者并且发起者ULP 910和发起者RT 930可以是被配置为图3的高层协议310和可靠传输协议层330 的通信协议层，而实体B可以是目标实体并且目标ULP 920和目标RT 940可以是被配置为图3的上层协议320和可靠传输协议层340的通信协议层。
参考时序图900，示出了许多与时序图800相同的事务，并且同样对其进行了标记。例如，一旦各种请求从发起者ULP 910发送到发起者RT 930，则类似于时序图800，然后将请求传送到目标RT 940。对于索求的推送请求(诸如pushSlctdReq_0和pushSlctdReq_2)，推送授权(诸如pushGrnt_0和pushGrnt_2)由目标RT 940发送到发起者 RT 930。响应于推送授权，索求的数据被发起者RT 930推送到目标 RT 940，如通过pushSlctdData_0和pushSlctdData_2所示。对于诸如 pushUnslctdReq_3的主动请求的请求，发起者RT 930可以将主动请求的数据推送到目标RT 940，如通过pushUnslctdData_3所示。对于诸如pullReq_1的拉取请求，发起者RT 930可以将拉取请求发送到目标RT 940，然后发送到目标ULP 920。目标ULP 920然后可以利用pullResp_1 响应，该目标RT 940利用pullData_1响应发起者RT 930。然后，发起者RT 930将pullResp_1发送到发起者ULP 910，该发起者ULP 910处理将所拉取的数据放置和/或存储在实体A处。如上参考图8所述，还可以通过滑动窗口来跟踪这些分组。
时序图900还示出了若干方面，其中，无序系统与时序图800的有序系统不同。一个不同之处在于根据传输顺序而不是根据相应的 RSN，分配用于分组的PSN。例如，根据恰好与相应的RSN相同的顺序的发起者RT 930的传输顺序，为pushSlctdReq_0、pullReq_1和pushSlctdReq_2分配了PSN。由于传输顺序，pushGrnt_0和pushGrnt_2 分组也具有按相应的RSN的顺序的PSN。然而，按与相应的RSN的顺序不同的顺序传送pushUnslctdData_3、pushSlctdData_0和 pushSlctdData_2分组，因此产生不按与相应的RSN相同的顺序的PSN。这样，pushUnslctdData_3的PSN＝200小于PSN＝201的 pushSlctdData_0和PSN＝202的pushSlctdData_2。
另一个区别是目标实体可能会无序处理事务。因此，如所示，时序图900中的ULP-Req和ULP-ACK不是均在围绕相应的RT传递了各种请求和授权之后发送。相反，一旦相对于特定事务完成了RT之间的请求和/或授权，就发送与特定事务相对应的ULP-Req和ULP-ACK。例如，相对于事务pullReq_1，一旦将pullReq_1从发起者RT 930传送到目标RT 940，就传送ULP-Req_1和ULP-ACK-1。作为相对于事务 pushUnslctdReq_3的另一示例，一旦将pushUnslctdData_3从发起者RT 930传送到目标RT 940，就传送ULP-Req_3和ULP-ACK-3。相对于事务pushSlctdReq_0和pushSlctdReq_2，在将推送授权和索求的数据分组从发起者RT930推送到目标RT 940后，稍后发送ULP-Reqs和 ULP-ACK。此外，由于在pushSlctdData_2之后在目标RT 940处接收了pushSlctdData_0，因此这两个的ULP-Req和ULP-ACK按相反的顺序发送。更进一步地，尽管可以在ULP-Req_3、ULP-ACK_3、ULP-Req-0、 ULP-Req-2、ULP-ACK-0和ULP-ACK-UL之前传送ULP-Req-1和 ULP-ACK-1，目标ULP 920仍然可以在推送请求之后处理拉取请求。
作为目标实体对事务的无序处理的结果，因此可以将确认和完成消息无序地发送到发起者实体。这样，发起者也可能会无序处理事务。因此，如所示，目标RT 940发送针对pushUnslctdData_3的ACK，其提示发起者RT 930在针对pushSlctdData_0和pushCompl_0的ACK之前、在pushCompl_2之前以及在pullResp_1之前，向发起者ULP 910 发送pushCompl_3。进一步如所示，因为在拉取请求之前，在该示例中完成了索求的推送，所以可以在来自发起者RT 930的pullResp_1之前，传送用于pushSlctdData_0的ACK、pushComp_0和pushComp_2。
如图9所示，实体对事务的无序处理允许处理较快的某些事务在给定连接上在处理较慢的事务之前进行，这可以提高该连接的整体效率。例如，通过允许无序传送ULP-Req和ULP-ACK，这允许步骤较少的事务(诸如拉取和主动请求的推送)在目标ULP处继续进行，无需等待RT处具有更多步骤的其他事务(诸如索求的推送)，以完成请求过程。作为另一个示例，该示例中的拉取请求可以稍后由目标ULP 920 处理，因为推送事务具有更快的处理时间。附加地或可替代地，网络可以无序地传递分组。事务的无序处理因此可以提供更大的灵活性，以加速整个系统并增加吞吐量。
在另一方面，图3的通信协议系统300可以提供有效的错误处理，从而减少死锁的机会。就此而言，图10示出了根据本技术的方面的用于接收器未就绪(“RNR”)否定确认(“NACK”)的示例性时序图，并且图11示出了根据本技术的方面的用于错误完成(“compl-in-error”) 的示例性时序图。图10-11的示例性时序图可以由网络中的两个实体 (诸如图1的连接110上的实体A和B)例如通过图2的处理器220 和270实现。
参考图10，可以由发起者实体和目标实体两者的各种通信协议层来执行各种事务，诸如上文参考图5-9所述的拉取事务和推送事务。例如，实体A可以是发起者实体，并且发起者ULP 1010和发起者RT 1030 可以是被配置为图3的上层协议310和可靠传输协议层330的通信协议层，而实体B可以是目标实体并且目标ULP 1020和目标RT 1040 可以是被配置为图3的上层协议320和可靠传输协议层340的通信协议层。
参考时序图1000，示出了许多与时序图800相同的事务，并且同样对其进行了标记。例如，时序图1000示出了源自发起者ULP 1010 的pushReq_0、pullReq_1和pushReq_2。一旦将各种请求从发起者ULP 1010传送到发起者RT 1030，则将这些请求传送至目标RT1040，类似于时序图800。对于索求的推送请求pushSlctdReq_0和pushSlctdReq_2，推送授权pushGrnt_0和pushGrnt_2由目标RT 1040发送到发起者RT 1030。响应于推送授权，索求的数据由发起者RT 1030推送到目标 RT 1040，如通过pushSlctdData_0和pushSlctdData_2所示。此外，将拉取请求pullReq_1由发起者RT 1030发送到目标RT 1040。然后，目标RT1040将pushSlctdReq_0、pullReq_1和pushSlctdReq_2发送到目标ULP 1020。目标RT 1040还利用ACK-0-1-2，将对请求的确认发送到发起者RT 1030。
然而，在时序图1000中，目标实体尚未准备好进行推送请求和拉取请求。因此，目标ULP 1020发送否定确认(“NACK”)，其通知目标ULP 1020尚未准备好，并且目标RT 1040应当稍后再试。因此，如所示，目标ULP 1020响应于pushSlctdReq_1发送pushNACK_0-retry，响应于pullReq_1发送pullNACK_1-retry，以及响应于pushSlctdReq_2 发送pushNACK_2-retry。这些NACK可以包括用于NACK的原因，在该示例中原因是目标实体尚未准备好，和/或可以包括用于重传的新定时器到期值。然后，目标RT 1040将相应的NACK发送到发起者RT1030，如引用pushSlctdData_0和pushSlctdData_2分组的PSN的 Nush-200和NACK-201所示。请注意，发起者对于pullReq_1没有 NACK，因为ACK-0-1-2早已对其进行了确认。相反，目标RT 1040 跟踪pullNACK-1-retry，并且将在计时器到期时再次传递到目标ULP 1020。注意，NACK具有相同的eBSN，因为由于无法确认发送者而导致滑动窗口被卡住。但是，尽管NACK-201到达发起者RT 1030时，由于多种原因中的任何一种，NACK-200分组都可能会在网络中被丢弃而不会到达发起者RT 1030，并且如前所述，ACK和NACK消息不能通过可靠传输被传送。
因为发起者RT 1030接收针对pullSlctdReq_2的NACK，所以发起者RT不会尝试重传pushSlctdData_2。相反，由于发起者RT 1030 未接收到针对pushSlctdReq_0的NACK，因此发起者RT 1030尝试通过pushData_0-retry进行重传。例如，发起者RT 1030可以被配置为如果在预定时间段内未接收到针对所推送的数据的ACK，则尝试利用相同的PSN重传。一旦目标RT 1040接收到pushData_0-retry，则目标 RT 1040例如基于pushData_0-retry的PSN与先前接收到的 pushSlctdData_0相同，识别出pushData_0-retry是数据分组的重传。然后，目标RT 1040向目标ULP 1020发送ULP-pushReq_0。这次，目标 ULP 1020准备就绪，并且利用ULP-ACK-0进行响应。
然后，在一段时间之后，目标RT 1040再次尝试利用 ULP-pullReq_1和ULP-pushSlctdReq_2向目标ULP 1020尝试。如所示，这次目标ULP 1020准备就绪并完成了请求。时序图1000的其余部分类似于时序图800，其中，目标ULP 1020向目标RT 1040发送确认ULP-ACK-0、ULP-ACK-1和ULP-ACK-2，然后，目标RT 1040将确认 ACKs-200-201发送到发起者RT 1030，反过来，发起者RT 1030发送完成消息pushComp_0和pushCompl_2。对于拉取请求，目标ULP 1020 将pullResp_1发送到目标RT 1040，然后将pullResp_1发送到发起者 RT1030，然后将完成消息pullCompl_1发送到发起者ULP 1010。
因此，图10示出了通过当在预定时间段内未接收到ACK或NACK 时允许发起者RT重传请求和/或数据，RT在潜在的有损网络上稳健可靠地工作。此外，通过当接收到NACK时不允许发起者RT重传，可以减少网络上的拥塞。更进一步，通过允许目标RT向目标ULP重传请求和/或数据，可以在目标ULP准备好以后的时间处理请求，而不会导致死锁或超时。
参考图11，可以通过发起者实体和目标实体两者的各种通信协议层来执行各种事务，诸如上文参考图5-9所述的拉取事务和推送事务。例如，实体A可以是发起者并且发起者ULP 1110和发起者RT 1130 可以是被配置为图3的上层协议310和可靠传输协议层330的通信协议层，而实体B可以是目标实体并且目标ULP 1120和目标RT 1140 可以是被配置为图3的上层协议320和可靠传输协议层340的通信协议层。
参考时序图1100，示出了许多与时序图800相同的事务，并且同样对其进行了标记。例如，时序图1100示出源自发起者ULP 1110的 pushReq_0、pullReq_1和pushReq_2。一旦将各种请求从发起者ULP 1110发送到发起者RT 1130，则类似于时序图800，将请求传送到目标 RT 1140。对于索求的推送请求pushSlctdReq_0和pushSlctdReq_2，推送授权pushGrnt_0和pushGrnt_2由目标RT 1140发送到发起者RT 1130。响应于推送授权，发起者RT 1130将索求的数据推送到目标RT 1140，如利用pushSlctdData_0和pushSlctdData_2所示。发起者RT 1130 将拉取请求pullReq_1发送到目标RT 1140。然后，目标RT 1140将pushSlctdReq_0、pullReq_1和pushSlctdReq_2发送到目标ULP 1120。
然而，在时序图1100中，由于多种原因中的任何一种，目标ULP 1120错误地完成pushSlctdData_0。因此，目标ULP 1120发送 pushNACK_0-compl-in-err，其将错误告知目标RT 1140。NACK可以包括用于NACK的原因，在该示例中，其是错误地完成了推送数据的放置或存储。NACK可以可选地包括关于错误的信息，诸如原因。然后，目标RT 1140将相应的NACK发送到发起者RT 1130，如引用 pushSlctdData_0的PSN的NACK-200所示。但是，由于多种原因中的任何一个，NACK-200无法到达发起者RT 1130。此外，如所示，目标 ULP 1120成功完成了其他请求，并且将ULP-ACK_1、ULP-ACK_2和 pullResp_1发送到目标RT 1140，提示目标RT 1140将ACK-201和 pullResp_1发送到发起者RT 1130。
因为发起者RT 1130未接收到对pushSlctdReq_0的NACK，所以发起者RT 1130尝试利用pushData_0-retry重传。例如，发起者RT 1130 可以被配置为如果在预定时间段内未接收到对推送数据的ACK，则尝试利用相同的PSN进行重传。一旦目标RT 1140接收到pushData_0-retry，则目标RT 1140例如基于pushData_0-retry的PSN 与先前接收到的pushSlctdData_0相同，识别出pushData_0-retry是数据分组的重传。这样，目标RT 1140重新发送NACK-200，而不必向目标 ULP 1120发送另一个推送请求。
此外，响应于错误完全否定确认，可以执行重新同步。例如，如所示，可以利用“resync-pkt”，通过发起者RT 1130启动重新同步。重新同步提示目标RT 1140发送确认，该确认允许一个或多个当前滑动窗口移动到要传送和/或接收的下一组分组。如所示，这通过目标RT 1140响应于resync-pkt，向发起者RT 1130发送确认ACK-200而不是否定确认来完成。然后，发起者RT 1130将完成消息 pushCompl_0-in-err、pullCompl_1和pushCompl_2发送到发起者ULP 1110，其通知成功完成和错误完成。
图11示出了重新同步过程防止当前滑动窗口被卡住。此外，与完全错误完成可能导致连接超时或断开的许多协议相反，重新同步过程允许在实体之间维持更具弹性的连接。图11还示出了该过程的示例性时标。如所示，可以在由发起者RT 1130发送pushSlctdReq_0的时间与由发起者RT 1130接收pushGrnt_0的时间之间经过一个往返时间(“RTT”)。然后，在由发起者RT 1130接收pushGrnt_0和由发起者RT 1130正在接收NACK-200之间，可能已经过了多个RTT。在由发起者RT 1130发送resync-pkt的时间与由发起者RT1130发送 pushCompl_0-in-err的时间之间可能经过另一个RTT。
尽管为有序系统提供图10和11的示例，但在其他示例中，时序图可以由无序系统执行。在这种情况下，可以执行类似的过程而无需有序要求。
返回图3，通信协议系统300可以附加地提供有一个或多个拥塞控制引擎或与一个或多个拥塞控制引擎相关联。这种拥塞控制引擎可以被配置有多种算法中的任何一种，诸如SWIFT、BBR、GCN等。就此而言，可以以软件、固件或硬件来实现拥塞控制算法。例如，拥塞控制算法可以以主机软件、网络接口(“NIC”)固件或硬件速率更新引擎实现。例如，通信协议系统300可以向速率更新引擎提供速率更新事件和结果队列接口。可以在事件队列中提供拥塞信号，该事件队列可以包括RTT的测量、显式拥塞通知(“ECN”)标记、重传状态等。
速率更新引擎可以将结果报告回通信协议系统300，基于该结果可以实现拥塞控制。例如，该报告可以包括拥塞窗口(“Cwnd”)，其是未完成的TX分组的总数。当该值在0和1之间时，通信协议系统 300，例如发送者RT可以应用附加的分组间间隙以将分组传输的数量限制为每个RTT小于1。作为另一示例，该报告可以包括重传超时(“RTO”)，其是在没有接收到ACK的情况下发送者实体在重传未决的TX分组之前等待的时间。
图12A-17B示出了根据本技术的方面的示例性报头和定义。这些示例报头仅作为示例提供，并且实际上可以采用任何其他格式，并且可以包括替代或附加信息。当实现图4的滑动窗口和/或图5-11的时序图时，实体的各种通信协议层可以使用示例性报头。例如，图12A-B 描述了将由通信协议系统内的所有分组包括的示例性基本报头。图 13A-F描述了用于通信协议系统中的请求和授权分组的示例性报头。图 14A-C描述了用于通信协议系统中的数据分组的示例性报头。图15A-B 描述了通信协议系统中的示例性重新同步分组。图16A-B描述了通信协议系统中的示例性确认分组。图17A-B描述了通信协议系统中的示例性否定确认分组。
参考图12A和12B，所示的示例性基本报头包括各种信息字段。例如，“Proto Type”字段可以指定要用于该分组的各种协议，诸如RT 协议、ULP协议、存储协议等。“ULP协议”可以指定所支持的不同 ULP类型，例如，RDMA、NVMe等。“Packet Type”字段可以指定分组的类型，诸如上述的各种请求、授权、数据、ACK、NACK、重新同步等。基本报头可以包括用于该分组的各种序列号，诸如上述的PSN 和RSN，以及用于数据滑动窗口(“eDBSN”)的RX方向上的预期基本分组序列号，以及用于请求滑动窗口(“eRBSN”)的RX方向上的预期基本分组序列号。进一步，基本报头可以包括目的地CID，该目的地CID标识通过通向旨在接收者实体的连接的通信方向。
转向图13A-13F，其示出了示例性请求和授权报头，每一个均包括图12A的基本报头以及可选的一些附加信息。例如，图13A和13D 描述了示例性拉取请求报头，其可以包括附加信息，诸如指定返回拉取响应分组的大小的“请求长度”字段和/或保留的可定制字段。图13B 和13E描述了示例性推送请求报头，其可以类似地包括指定输出推送数据分组的大小的请求长度字段。对于索求的推送请求，推送请求报头可以进一步包括指定请求顺序的SSN字段。图13C和13F描述了用于索求的推送请求的示例性推送授权报头，其可以包括请求长度字段、 SSN字段、SPH重组上下文ID和SPH重放计数字段。
图14A-14C示出了示例性数据报头，每一个均包括图12A的基本报头以及可选地包括一些附加信息。例如，图14A中的示例性拉取数据报头和图14B中的示例性推送数据报头均包括图12A的基本报头，没有附加信息。相反，图14C的示例性推送主动请求的数据报头包括图12A的基本报头，而且另外包括指定正被推送的主动请求的数据分组的大小的请求长度字段。
图15A和15B描述了示例性重新同步报头，其包括图12A的基本报头以及可选的附加信息。例如，重新同步报头可以包括指定向其发送重新同步分组的目标ULP的“ResyncCode”字段、存储器释放和其他信息。重新同步报头可以进一步包括“resynch type”字段，其指定正重新同步的原始分组的类型。如果重新同步类型为被动推送请求或推送授权，则可以提供SSN。
图16A和16B描述了示例性确认或ACK报头。参考图16A，示例性ACK报头包括一些与图12A的基本报头相同的字段，但是代替 PSN和RSN字段，ACK报头包括“接收者数据窗口序列位图”和“接收者请求窗口序列位图”字段。如参考图4所述，在这样的位图中的值“1”指示分组已经被确认，“0”指示分组尚未被确认。此外，用于字段NACK的示例性ACK报头中的值“N0”指示该分组是ACK而不是NACK。更进一步地，ACK报头可以包括拥塞控制元数据字段，该RT可以在两个实体之间携带该字段以促进拥塞控制算法，并且用于测量网络中的等待时间的一个或多个时间戳。
图17A和17B描述了示例性否定确认或NACK报头。参考图17A，示例性NACK报头包括一些与图12A的基本报头相同的字段，但是代替PSN和RSN字段，NACK报头包括“NACK序列号”字段，其指定被否定确认的分组的PSN。示例性NACK报头还包括一些与图16的 ACK报头相同的字段。例如，用于字段NACK的示例性NACK报头中的值“N1”指示该分组是NACK。示例性NACK报头还包括在基本报头或ACK报头中找不到的字段。NACK报头可以包括“NACK code”字段，例如，该字段可以提供NACK的原因，诸如网络抖动过多、接收器资源下降、接收器未准备好等。NACK报头还可以包括“wnd”字段，指示NACK指向的滑动窗口。在RNR-NACK的情况下，NACK报头可以进一步包括“RNR-NACK超时”字段，其指定用于重传的定时器到期值。
图18示出了根据本公开的方面的示出示例性方法的示例性流程图。可以使用上述系统、其变型或具有不同配置的多种系统中的任何一种来执行该方法。应当理解到，下述方法所涉及的操作不必以所描述的精确顺序执行。而是，可以以不同的顺序或同时地处理各种操作，并且可以添加或省略操作。尽管图18示出了一种示例性方法，但是可以执行方法的变型，例如，如上参考图1-11所述。
参照图18，示出了示例性流程图1800，其示出了索求的推送事务。流程图1800可以由网络中的一个或多个实体执行，诸如由图1的实体 A、B、C中的任何一个执行，例如通过图2的处理器220执行。如上参考图2所提及的，处理器220可以包括一个实体(诸如实体110)上的处理器，或者多个实体(诸如实体A、B、C等中的两个或多个实体) 上的处理器。这样，处理器220可以接收数据并且执行可靠的传输，以上参考图1-11所述，其可以包括使用报头，如图12A-17B所示。
参考图18，在框1810，发起者实体确定要将传出数据传送到目标实体。在框1820，发起者实体向目标实体传送请求将传出数据放置在目标实体处的索求的推送请求。在框1830，发起者实体响应于索求的推送请求，从目标实体接收推送授权。在框1840，发起者实体响应于推送授权将要放置在目标实体处的传出数据传送到目标实体。
该技术通常涉及用于通过连接可靠地传输分组的通信协议。该技术提供了基于请求的推送事务，其提供了对传入数据的接收者实体控制，从而减少了聚播拥塞和尾部延迟。该技术进一步使用滑动窗口和位图，支持通过连接的无序事务，这可以提高通过连接处理分组的整体效率。该技术进一步提供了对失败传输的处理，减少了重传尝试并使用重新同步来防止连接断开，从而导致更具弹性的连接。
除非另有说明，否则前述替代性示例不是互相排斥的，而是可以以各种组合实现来实现独特的优点。由于可以在不脱离权利要求所限定的主题的情况下利用上述讨论的特征的这些和其他变形以及组合，因此，应当通过示例，而不是通过限制由权利要求限定的主题进行实施例的前述描述。另外，提供本文所述的示例以及措辞为“诸如”、“包括”等的用语不应当被解释为将权利要求的主题限制于特定示例；相反，这些示例仅旨在说明许多可能的实施例之一。此外，在不同附图中的相同附图标记可以标识相同或相似的元件。

Claims (20)

1.一种方法，包括：
由发起者实体确定要将传出数据传送到目标实体；
由所述发起者实体将请求将所述传出数据放置在所述目标实体处的索求的推送请求传送到所述目标实体；
由所述发起者实体从所述目标实体接收响应于所述索求的推送请求的推送授权；以及
由所述发起者实体响应于所述推送授权，将要放置在所述目标实体处的所述传出数据传送到所述目标实体。
2.根据权利要求1所述的方法，进一步包括：
由所述发起者实体确定所述传出数据的大小满足预定阈值，其中，传送所述索求的推送请求是基于所述传出数据的大小满足所述预定阈值的确定。
3.根据权利要求2所述的方法，其中，推送请求源自所述发起者实体的上层协议，基于所述发起者实体的上层协议，所述发起者实体的可靠传输协议层通过所述发起者实体与所述目标实体之间的连接，将所述索求的推送请求作为分组传送。
4.根据权利要求1所述的方法，进一步包括：
由所述发起者实体确定所述传出数据的大小不满足预定阈值；
由所述发起者实体在不发送所述索求的推送请求或接收所述推送授权的情况下，传送要放置在所述目标实体处的所述传出数据。
5.根据权利要求4所述的方法，其中，推送请求源自所述发起者实体的上层协议，基于所述发起者实体的上层协议，所述发起者实体的可靠传输协议层通过所述发起者实体与所述目标实体之间的连接，将所述传出数据作为分组发送。
6.根据权利要求1所述的方法，进一步包括：
由所述发起者实体从所述目标实体接收指示所述传出数据被接收到并且被放置在所述目标实体处的确认。
7.根据权利要求1所述的方法，进一步包括：
由所述发起者实体确定需要来自所述目标实体的传入数据；
由所述发起者实体将请求将所述传入数据传送到所述发起者实体的拉取请求传送到所述目标实体；
由所述发起者实体从所述目标实体接收响应于所述拉取请求的所述传入数据。
8.根据权利要求7所述的方法，进一步包括：
由所述发起者实体基于一个或多个拥塞参数来排程针对所述传入数据的所述拉取请求。
9.一种方法，包括：
由发送者实体通过到接收者实体的连接按第一顺序传送多个分组；
由所述发送者实体维护包括多个位的至少一个滑动窗口，其中，所述滑动窗口的每个位表示所述多个分组中的相应分组；
由所述发送者实体接收指示所述接收者实体已经接收到所述多个分组中的一个或多个分组的一个或多个确认，所述一个或多个确认中的每一个均引用所述多个分组中的相应分组，其中，所述一个或多个确认按与所述第一顺序不同的第二顺序被接收；以及
由所述发送者实体修改所述滑动窗口中的所述多个位中的与接收到的所述一个或多个确认相对应的一个或多个位的值。
10.根据权利要求9所述的方法，进一步包括：
由所述发送者实体基于一个或多个拥塞参数来调整所述滑动窗口的大小。
11.根据权利要求9所述的方法，其中，所述多个分组包括以下中的一项或多项：对数据分组的请求、数据分组、以及确认。
12.根据权利要求11所述的方法，其中，所述至少一个滑动窗口包括请求滑动窗口。
13.根据权利要求11所述的方法，其中，所述至少一个滑动窗口包括数据滑动窗口。
14.根据权利要求9所述的方法，其中，所述多个分组包括响应于拉取请求的至少一个数据分组。
15.根据权利要求9所述的方法，其中，所述多个分组包括响应于索求的推送请求的至少一个推送授权分组。
16.一种方法，包括：
由发起者实体通过连接将所述多个分组传送到目标实体；
由所述发起者实体确定在预定时间段内既未接收到响应于所述多个分组中的特定分组的确认也未接收到否定确认；
由所述发起者实体基于所述确定，将所述特定分组重传到所述目标实体；
由所述发起者实体从所述目标实体响应于所述重传接收否定确认；以及
由所述发起者实体基于所述否定确认，确定是等待对所述特定分组的确认还是重新同步。
17.如权利要求16所述的方法，进一步包括：
由所述发起者实体确定所述否定确认指示针对所述特定分组所述目标实体尚未就绪；
响应于所述否定确认，在不将所述特定分组重传到所述目标实体的情况下，由所述发起者实体等待来自所述目标实体的确认。
18.如权利要求16所述的方法，进一步包括：
由所述发起者实体确定所述否定确认指示所述目标实体错误地完成了对所述特定分组的操作；
由所述发起者实体在不断开所述连接的情况下将重新同步分组传送到所述目标实体。
19.根据权利要求18所述的方法，进一步包括：
由所述发起者实体从所述目标实体接收响应于所述重新同步分组的确认；
由所述发起者实体响应于对所述重新同步分组的所述确认，传送第二多个分组。
20.根据权利要求16所述的方法，其中，所述多个分组根据来自所述发起者实体的上层协议的请求被传送，并且所述特定分组的重传通过所述发起者实体的可靠传输协议层来执行。
CN202011269309.2A 2019-12-12 2020-11-13 用于数据中心联网的可靠传输协议和硬件架构 Pending CN112383622A (zh)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201962947036P 2019-12-12 2019-12-12
US62/947,036 2019-12-12
US16/819,327 US11463547B2 (en) 2019-12-12 2020-03-16 Reliable transport protocol and hardware architecture for datacenter networking
US16/819,327 2020-03-16

Publications (1)

Publication Number Publication Date
CN112383622A true CN112383622A (zh) 2021-02-19

Family

ID=73448810

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011269309.2A Pending CN112383622A (zh) 2019-12-12 2020-11-13 用于数据中心联网的可靠传输协议和硬件架构

Country Status (3)

Country Link
US (3) US11463547B2 (zh)
EP (1) EP3836508A3 (zh)
CN (1) CN112383622A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4096193A1 (en) * 2021-05-25 2022-11-30 Google LLC High bandwidth content addressable memory (cam) based hardware architecture for datacenter networking

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20240121320A1 (en) * 2022-10-07 2024-04-11 Google Llc High Performance Connection Scheduler

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050135394A1 (en) * 2003-12-23 2005-06-23 Bhupinder Sethi Use of internal buffer to reduce acknowledgement related delays in acknowledgement-based reliable communication protocols
US20080317051A1 (en) * 2007-06-22 2008-12-25 Dantzig Paul M Methods and System for Highly Ordered Transaction Processing
US20090007141A1 (en) * 2007-06-26 2009-01-01 International Business Machines Corporation Message passing with a limited number of dma byte counters
US20100274848A1 (en) * 2008-12-05 2010-10-28 Social Communications Company Managing network communications between network nodes and stream transport protocol
US20110134930A1 (en) * 2009-12-09 2011-06-09 Mclaren Moray Packet-based networking system
US20120278400A1 (en) * 2011-04-28 2012-11-01 Microsoft Corporation Effective Circuits in Packet-Switched Networks
US8306062B1 (en) * 2008-12-31 2012-11-06 Marvell Israel (M.I.S.L) Ltd. Method and apparatus of adaptive large receive offload
US20130294236A1 (en) * 2012-05-04 2013-11-07 Neda Beheshti-Zavareh Congestion control in packet data networking
US20170149913A1 (en) * 2015-11-19 2017-05-25 Morven Management Limited Enhanced push notification for alerts
US20170201601A1 (en) * 2016-01-12 2017-07-13 International Business Machines Corporation Data transfer policies between source and target servers in a wide area network
US20170244643A1 (en) * 2016-02-23 2017-08-24 Level 3 Communications, Llc Network flow control

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6330226B1 (en) * 1998-01-27 2001-12-11 Nortel Networks Limited TCP admission control
US6330451B1 (en) * 1998-10-13 2001-12-11 Nortel Networks Limited Selectively delaying data communications in a wireless communication system to provide voice communications capacity
US6424625B1 (en) * 1998-10-28 2002-07-23 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for discarding packets in a data network having automatic repeat request
WO2002003597A1 (en) 2000-06-30 2002-01-10 Kanad Ghose System and method for fast, reliable byte stream transport
US7039032B1 (en) * 2000-07-14 2006-05-02 At&T Corp. Multipoll for QoS-Driven wireless LANs
US8503294B2 (en) * 2003-07-11 2013-08-06 Nec Corporation Transport layer relay method, transport layer relay device, and program
US7443791B2 (en) 2003-10-10 2008-10-28 Microsoft Corporation Priority mechanism for distributed sending of media data
US7773509B2 (en) * 2006-03-07 2010-08-10 Samsung Electronics Co., Ltd. Method and system for traffic control for providing quality of service in a network
JP4729000B2 (ja) * 2006-04-27 2011-07-20 イノヴァティヴ ソニック リミテッド 無線通信システムにおいて復号パラメータを同期させる方法及び装置
US8184549B2 (en) * 2006-06-30 2012-05-22 Embarq Holdings Company, LLP System and method for selecting network egress
US8571061B2 (en) * 2006-07-07 2013-10-29 Avaya Communications Israel Ltd. Inter-network translation
US7782771B2 (en) * 2007-01-05 2010-08-24 Microsoft Corporation Adjusting to network latency changes
MX2009010813A (es) * 2007-04-06 2009-10-29 Ntt Docomo Inc Metodo de comunicacion en paquetes y aparato del lado receptor.
US7996548B2 (en) * 2008-12-30 2011-08-09 Intel Corporation Message communication techniques
US20120287814A1 (en) * 2011-05-12 2012-11-15 Fluke Corporation Method and apparatus to determine the amount of data outstanding throughout the life of a tcp flow (socket connection)
US20130163417A1 (en) * 2011-12-27 2013-06-27 Mitel Networks Corporation Application level admission overload control
JP6142920B2 (ja) * 2013-05-10 2017-06-07 富士通株式会社 無線通信システム、移動局、基地局及び無線通信方法
US10432529B2 (en) 2013-09-19 2019-10-01 Connectivity Systems Incorporated Enhanced large data transmissions and catastrophic congestion avoidance over IPv6 TCP/IP networks
US9979591B2 (en) * 2015-08-28 2018-05-22 Samsung Electronics Co., Ltd. Event notifications for applications
US10148543B2 (en) 2015-12-23 2018-12-04 EMC IP Holding Company LLC Connection-oriented communication devices with round trip time estimation
US11172016B2 (en) * 2017-03-30 2021-11-09 Intel Corporation Device, method and system to enforce concurrency limits of a target node within a network fabric
CN108111434B (zh) 2017-12-14 2021-03-16 四川大学 一种基于可靠udp和喷泉码的航空自组网可靠传输方法
US11102129B2 (en) * 2018-09-09 2021-08-24 Mellanox Technologies, Ltd. Adjusting rate of outgoing data requests for avoiding incast congestion
US20200145881A1 (en) * 2018-11-06 2020-05-07 Qualcomm Incorporated System and method for flow control and buffer status report
US11778533B2 (en) * 2019-08-02 2023-10-03 Comcast Cable Communications, Llc Path optimization in a mesh network

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050135394A1 (en) * 2003-12-23 2005-06-23 Bhupinder Sethi Use of internal buffer to reduce acknowledgement related delays in acknowledgement-based reliable communication protocols
US20080317051A1 (en) * 2007-06-22 2008-12-25 Dantzig Paul M Methods and System for Highly Ordered Transaction Processing
US20180218294A1 (en) * 2007-06-22 2018-08-02 International Business Machines Corporation Highly ordered transaction processing
US20090007141A1 (en) * 2007-06-26 2009-01-01 International Business Machines Corporation Message passing with a limited number of dma byte counters
US20100274848A1 (en) * 2008-12-05 2010-10-28 Social Communications Company Managing network communications between network nodes and stream transport protocol
US8306062B1 (en) * 2008-12-31 2012-11-06 Marvell Israel (M.I.S.L) Ltd. Method and apparatus of adaptive large receive offload
US20110134930A1 (en) * 2009-12-09 2011-06-09 Mclaren Moray Packet-based networking system
US20120278400A1 (en) * 2011-04-28 2012-11-01 Microsoft Corporation Effective Circuits in Packet-Switched Networks
US20130294236A1 (en) * 2012-05-04 2013-11-07 Neda Beheshti-Zavareh Congestion control in packet data networking
US20170149913A1 (en) * 2015-11-19 2017-05-25 Morven Management Limited Enhanced push notification for alerts
US20170201601A1 (en) * 2016-01-12 2017-07-13 International Business Machines Corporation Data transfer policies between source and target servers in a wide area network
US20170244643A1 (en) * 2016-02-23 2017-08-24 Level 3 Communications, Llc Network flow control

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4096193A1 (en) * 2021-05-25 2022-11-30 Google LLC High bandwidth content addressable memory (cam) based hardware architecture for datacenter networking

Also Published As

Publication number Publication date
US20230421657A1 (en) 2023-12-28
EP3836508A3 (en) 2021-08-04
EP3836508A2 (en) 2021-06-16
US11463547B2 (en) 2022-10-04
US20220337675A1 (en) 2022-10-20
US11824954B2 (en) 2023-11-21
US20210185139A1 (en) 2021-06-17

Similar Documents

Publication Publication Date Title
US10430374B2 (en) Selective acknowledgement of RDMA packets
EP2681880B1 (en) Controlling network device behavior
US8233483B2 (en) Communication apparatus, communication system, absent packet detecting method and absent packet detecting program
EP1691526A1 (en) Transmission control protocol (TCP) congestion control using multiple TCP acknowledgements (ACKs)
EP2001180B1 (en) One-way message notification with out-of-order packet delivery
EP2978171B1 (en) Communication method, communication device, and communication program
US20230421657A1 (en) Reliable Transport Protocol and Hardware Architecture for Datacenter Networking
US9007905B2 (en) System to improve an Ethernet network
US20100217889A1 (en) Accelerated block option for trivial file transfer protocol (tftp)
EP3591875A1 (en) Reliable message transport network
CN111193577A (zh) 使用传输超时的网络系统通信方法及通信装置
US20120106344A1 (en) Data communication acknowledgement in a network
EP3941007A1 (en) Content addressable memory (cam) based hardware architecture for datacenter networking
US11463339B2 (en) Device and method for delivering acknowledgment in network transport protocols
CN108234089B (zh) 用于低时延通信的方法和系统
US8769137B2 (en) Systems and methods for negotiated accelerated block option for trivial file transfer protocol (TFTP)
JP2007243447A (ja) パケット送信制御装置
WO2021249651A1 (en) Device and method for delivering acknowledgment in network transport protocols
US20230327812A1 (en) Device and method for selective retransmission of lost packets
US20220382783A1 (en) High Bandwidth Content Addressable Memory (CAM) Based Hardware Architecture For Datacenter Networking
WO2023011712A1 (en) A device and method for remote direct memory access
WO2021223853A1 (en) Device and method for delivering acknowledgment in network transport protocols

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