FLOW-TRIMMING BASED CONGESTION MANAGEMENT

A piece of networking equipment facilitating efficient congestion management is provided. During operation, the equipment can receive, via a network, a plurality of packets that include portions of a data segment sent from a sender device to a receiver device. The equipment can identify, among the plurality of packets, one or more payload packets comprising payload of the data segment, and at least a header packet comprising header information of the data segment and a header-packet indicator. The equipment can determine whether congestion is detected at the receiver device based on a number of sender devices sending packets to the receiver device via the equipment. Upon determining congestion at the receiver device, the equipment can perform flow trimming by forwarding the header packet to the receiver device and dropping a subset of the one or more payload packets.

BACKGROUND

High-performance computing (HPC) can often facilitate efficient computation on the nodes running an application. HPC can facilitate high-speed data transfer between sender and receiver devices.

DETAILED DESCRIPTION

As applications become progressively more distributed, HPC can facilitate efficient computation on the nodes running an application. An HPC environment can include compute nodes, storage nodes, and high-capacity switches coupling the nodes. Hence, the HPC environment can include a high-bandwidth and low-latency network formed by the switches. Typically, the compute nodes can be formed into a cluster. The cluster can be coupled to the storage nodes via a network. The compute nodes may run one or more applications run in parallel in the cluster. The storage nodes can record the output of computations performed on the compute nodes. Therefore, the compute and storage nodes can operate in conjunction with each other to facilitate high-performance computing.

To ensure the expected performance level, a respective node needs to operate at the operating rate of other nodes. For example, a storage node needs to receive a piece of data from a compute node as soon as the compute node generates the data. Here, the storage and compute nodes can operate as receiver and sender devices, respectively. On the other hand, if the compute node obtains a piece of data from a storage node, the storage and compute nodes can operate as sender and receiver devices, respectively. In some examples, an HPC environment can deploy Edge-Queued Datagram Service (EQDS), which can provide a datagram service to higher layers via dynamic tunnels in the network. EQDS can encapsulate Transmission Control Protocol (TCP) and remote direct memory access (RDMA) packets.

EQDS can use a credit-based mechanism where the receiver device can issue credits to the sender devices to control the packet retrieval. As a result, the switches in the network can avoid overutilization of buffers, ensuring that a standing queue never builds in the network. Transport protocols typically generate and exchange data flows. To allow a transport protocol instance to send its data flow, the sender device can maintain a queue or buffer for a data flow. Because the receiver device can issue credits to control the flow of data, the receiver device can control the queue. When many sender devices attempt to send data to a receiver device, an incast occurs in the network, leading to a high level of congestion at the receiver device. Therefore, a high-performance network, such a datacenter network, can require efficient congestion management, especially during incast, in the network to ensure high-speed data transfer.

The aspects described herein address the problem of efficient congestion management in a network by (i) generating separate packets for headers and payloads of transport layer data flows; and (ii) upon detecting congestion at a switch, dropping payload packets while forwarding header packets. The header packets can be significantly smaller than the payload packets and can include control information that can be indicative of the payload data to be followed. Therefore, the switch can deliver the header packets with low bandwidth utilization while ensuring that the receiver device is aware of the subsequent data. In this way, the switch can selectively drop packets to trim the flow to mitigate the congestion.

With existing technologies, data transfers from multiple sender devices to a receiver device can cause congestion and reduce the throughput of the data flows at the switches. Such a many-to-one communication pattern can be referred to as “incast.” Typically, to mitigate the impact of congestion, a switch detecting the congestion can throttle traffic from the sender devices. For example, if EQDS is deployed in the network (e.g., a datacenter network), the sender device can become responsible for queueing. When a receiver device issues a transmit credit, the sender device sends a corresponding packet, thereby allowing the receiver device to partition its bandwidth among senders. To avoid congestion in the network, the switch can trim packets by removing the payload of the packets while preserving the headers.

Packet trimming includes forwarding the semantic information of a packet (e.g., the header) while dropping the payload. The semantic information can include information that can quantify the data in the payload and identify the distribution of the data (e.g., the number of bytes in the payload and the number of packets carrying the payload). However, the packets can be encrypted to ensure end-to-end security. Such a packet can include an Integrity Check Value (ICV) in a location of the packet (e.g., before or after the payload). Any modification to the packet can cause the ICV to be invalid. In particular, if a switch performs packet trimming, the receiver device may only receive the header of the packet. Since the ICV value is calculated based on the entire packet, the header information is insufficient to reproduce the ICV. Consequently, the receiver device would not be able to validate the packet.

To address this problem, when the NIC of the sender device receives a data segment from the upper layer (e.g., a TCP data segment), the NIC can synthesize a packet comprising semantic information of the segment. Since the header information of the data segment can include the semantic information, the synthesized packet can include the header information of the data segment. In particular, the semantic information can include all fields of the header of the data segment that can be used to quantify the data in the payload and identify the distribution of the data. The NIC can include a header-packet indicator in the packet. The indicator can mark the packet as a forwarding packet that should be forwarded to the receiver device. In other words, the indicator can mark this packet as “less favorable” for dropping (i.e., less likely to be dropped) if selective packet dropping is to occur due to network congestion. The NIC can also generate one or more payload packets comprising the payload of the segment. The NIC may not include the indicator in these packets, thereby indicating that these packets are “more favorable” for selective dropping.

The NIC can then generate the corresponding ICVs for each of these packets and individually encrypt the packets. Subsequently, the NIC can send the header packet to the receiver device. When a switch detects congestion in the network, instead of performing packet trimming, the switch can inspect the packets for the indicator and selectively drop the payload packets. The switch can detect the congestion based on the degree of incast at the receiver device. The degree of incast can indicate the number of sender devices sending packets to the receiver device. The switch can compare the current degree of incast at the receiver device, which can be determined by the number of flows to the receiver device through the switch, with a threshold value. The threshold value can indicate a predetermined number of sender devices sending packets to a receiver device. If the current degree of incast at the receiver device reaches the threshold value, the switch can determine congestion at the receiver device. However, the switch can continue to forward the header packets to the receiver device. The receiver device can validate the header packets with corresponding ICVs. Subsequently, the receiver device can schedule packets from different receiver devices based on the semantic information in the header packets. In this way, the semantic information for different flows can be forwarded to the receiver device while providing validation based on corresponding ICVs.

The receiver device can then obtain the data from the corresponding sender device at the scheduled time. Because the number of bytes in the semantic information is significantly smaller than the payload, the volume of traffic generated by the header packets can be relatively small. Hence, forwarding the header packets may not exacerbate the congestion and may not overwhelm the receiver device. Furthermore, the data awaiting transmission can be buffered at the corresponding sender devices. As a result, buffering can be avoided at the switches in the network. The receiver device can obtain the data from the sender devices at the scheduled time and mitigate congestion in the network.

In this disclosure, the term “switch” is used in a generic sense, and it can refer to any standalone networking equipment or fabric switch operating in any network layer. “Switch” should not be interpreted as limiting examples of the present invention to layer-2 networks. Any device or networking equipment that can forward traffic to an external device or another switch can be referred to as a “switch.” Any physical or virtual device (e.g., a virtual machine or switch operating on a computing device) that can forward traffic to an end device can be referred to as a “switch.” Examples of a “switch” include, but are not limited to, a layer-2 switch, a layer-3 router, a routing switch, a component of a Gen-Z network, or a fabric switch comprising a plurality of similar or heterogeneous smaller physical and/or virtual switches.

The term “packet” refers to a group of bits that can be transported together across a network. “Packet” should not be interpreted as limiting examples of the present invention to a particular layer of a network protocol stack. “Packet” can be replaced by other terminologies referring to a group of bits, such as “message,” “frame,” “cell,” “datagram,” or “transaction.” Furthermore, the term “port” can refer to the port that can receive or transmit data. “Port” can also refer to the hardware, software, and/or firmware logic that can facilitate the operations of that port.

FIG.1Aillustrates an example of receiver-driven incast management using data retrieval, in accordance with an aspect of the present application. An HPC environment100can include a number of nodes111,112,113,114,115,116,117,118, and119. A subset of these nodes can be compute nodes, while the others can be storage nodes. The nodes can be coupled to each other via a network110. A respective node can operate as a receiver or sender device. The node can then be referred to as a receiver or sender device, respectively. Network110can include a set of high-capacity networking equipment, such as switches101,102,103,104, and105. Here, network110can be an HPC fabric. The compute and storage nodes can operate in conjunction with each other through network110to facilitate high-performance computing in HPC environment100.

A subset of the switches in network110can be coupled to each other via respective tunnels. Examples of a tunnel can include, but are not limited to, VXLAN, Generic Routing Encapsulation (GRE), Network Virtualization using GRE (NVGRE), Generic Networking Virtualization Encapsulation (Geneve), Internet Protocol Security (IPsec), and Multiprotocol Label Switching (MPLS). The tunnels in network110can be formed over an underlying network (or an underlay network). The underlying network can be a physical network, and a respective link of the underlying network can be a physical link. A respective switch pair in the underlying network can be a Border Gateway Protocol (BGP) peer. A VPN, such as an Ethernet VPN (EVPN), can be deployed over network110.

To ensure the expected performance level, a respective node in HPC environment100can operate at the operating rate of other nodes. Suppose that node111operates as a receiver device. At least a subset of the rest of the nodes in environment100can then operate as sender devices. Switches101,102,103,104, and105can facilitate low-latency data transfer from a respective sender device to receiver device111at high speed. When a large number of sender devices attempt to send data to receiver device111, an incast occurs in network110, which can lead to a high level of congestion at receiver device111and associated switches. Therefore, to ensure high-speed data transfer, HPC environment100can require mechanisms to mitigate congestion during incast.

With existing technologies, switch101can detect the congestion caused by incast at receiver device111. Switch101can detect the congestion based on the degree of incast at receiver device111. The degree of incast can indicate the number of sender devices sending packets to receiver device111. Switch101can compare the current degree of incast at receiver device111, which can be determined by the number of flows to receiver device111through switch101, with a threshold value. The threshold value can indicate a predetermined number of sender devices sending packets to a receiver device. If the current degree of incast at receiver device111reaches the threshold value, switch101can determine congestion at receiver device111. To mitigate the impact of congestion, switch101can throttle traffic from sender devices112and114. For example, if EQDS is deployed in network119, sender devices112and114can become responsible for queueing or buffering. For example, a transport layer daemon (TPD)160running on sender device114can send a data flow to receiver device111. Examples of TPD160can include, but are not limited to, a TCP daemon, a User Datagram Protocol (UDP) daemon, Stream Control Transmission Protocol (SCTP) daemon, Datagram Congestion Control Protocol (DCCP) daemon, AppleTalk Transaction Protocol (ATP) daemon, Fibre Channel Protocol (FCP) daemon, Reliable Data Protocol (RDP) daemon, and Reliable User Data Protocol (RUDP) demon.

Sender device114can then become responsible for buffering the data from the flow. Similarly, sender device112can then become responsible for buffering the local data from the flow. When receiver device111issues respective transmit credits, sender devices112and114can send corresponding packets, thereby allowing receiver device111to partition its bandwidth among senders. To avoid congestion in network110, forwarding hardware150of switch101can trim packets by removing the payload of the packets while preserving the headers.

Forwarding hardware150can perform packet trimming by forwarding the header of a packet to receiver device111while dropping the payload. In this way, switch101can “trim” a packet. However, if the packet is encrypted to ensure end-to-end security, the packet can include an ICV in a location of the packet (e.g., before and after the payload). If forwarding hardware150modifies the packet by trimming the payload, the ICV in the packet can become invalid. In particular, because receiver device111may receive the header of the packet, and the ICV value is calculated based on the entire packet, receiver device111may not be able to reproduce the ICV. Consequently, receiver device111would not be able to validate the packet.

To address this problem, when NIC140of sender device114receives a data segment142from TPD182, NIC140can synthesize a header packet144comprising the semantic information of segment142. The semantic information can include the number of bytes in the payload of segment142and the number of packets carrying the payload. Since the header of segment142can include the semantic information of segment142, NIC140can include the header information of segment142in packet144. NIC140can include a header-packet indicator in packet144. The indicator can mark packet144as a forwarding packet that should be forwarded to receiver device111. In other words, the indicator can mark packet144as less favorable for dropping if selective packet dropping is to occur due to network congestion. NIC140can also generate a payload packet146comprising the payload of segment142. NIC140may not include the indicator in packet146, thereby indicating that packet146can be more favorable for selective dropping. NIC140can generate the corresponding ICVs for each of packets144and146and individually encrypt them.

Similarly, upon receiving a data segment132, NIC130of sender device112can generate a header packet134with the indicator and a payload packet136. If forwarding hardware150detects congestion in network110, instead of performing packet trimming, forwarding hardware150can inspect packets134and144for the indicator. Based on the presence of the indicator, forwarding hardware150can forward header packets134and144to receiver device111. Receiver device111can then validate header packets134and144with corresponding ICVs. A NIC170of receiver device111may store header packets134and144in ingress buffers172and174, respectively. In this way, switch101can forward the semantic information for different flows to receiver device111, which in turn, can validate header packets134and144based on corresponding ICVs.

NIC170can determine, based on the semantic information in header packets134and144, that the data of payload packets136and146, respectively, should be retrieved. For example, the semantic information can quantify the data in payload packets136and146. NIC170can also determine that the data awaiting retrieval is buffered in NICs130and140. Accordingly, NIC170can deploy a scheduling mechanism to schedule the retrieval of the data from NICs130and140, respectively. Because the number of bytes in the semantic information of segments132and142is significantly smaller than the corresponding payloads, the volume of traffic generated by header packets134and144can be relatively small. Hence, forwarding header packets134and144may not exacerbate the congestion and may not overwhelm NIC170. NIC170can issue credits to NICs130and140to initiate transmission of payload packets136and146.

However, if the congestion persists, switch101may deploy selective dropping. When forwarding hardware150receives packets136and146, instead of performing packet trimming, forwarding hardware150can inspect packets136and146for the indicator. Since the indicator is not present in packets136and146, forwarding hardware150can drop packets136and146, thereby trimming the corresponding flows. This allows switches in network110to drop any data packet of a flow while forwarding the headers without trimming individual packets. As a result, the corresponding ICV of a respective packet received at NIC170is not impacted by the flow trimming. Hence, NIC170can successfully validate packets while forwarding hardware150performs flow trimming.

FIG.1Billustrates examples of packets that facilitate flow-trimming-based congestion management, in accordance with an aspect of the present application. During operation, TPD160can determine a data flow120(e.g., a transport layer flow, such as a TCP flow). TPD160can generate a data segment142from flow120. Segment142can include a header122and a payload124. Header122can include a set of header fields, which can include one or more of: source port, destination port, sequence number, acknowledgment number, header length, flags, urgent bits, acknowledgment bits, push indicator, connection reset, synch bits, finish bits, sliding window field, checksum, urgent pointer, and optional bits.

TPD160can provide segment142to NIC140to send it to receiver device111. NIC140can generate a payload packet146comprising payload data194(i.e., the data to be transmitted) in payload124. Payload packet146can include a header192, which can be a copy of header122. NIC140can then generate ICV196for payload packet146and encrypt payload packet146. NIC140can then store payload packet146in a local buffer190associated with flow120. In addition, NIC140can determine the semantic information182from header122and generate a header packet144comprising semantic information182. Semantic information182can include parameter values from one or more fields of header122. In particular, semantic information182can include all fields of header122that can be used to quantify the data in payload124and determine which portion of segment142corresponds to payload124(i.e., the distribution of the payload of segment142). Semantic information182can allow NIC170to schedule and obtain the data in payload124(e.g., using RDMA).

NIC140can also include a header-packet indicator184in header packet144. Indicator184can be a separate field in header packet144or included in an optional field of header122that is included in semantic information182. Indicator184can be represented by a predefined value. NIC140can then generate ICV186for header packet144while encrypting packet144. Header packet144can include a header180, which can include a layer-3 header (e.g., an Internet Protocol (IP) header) and a layer-2 header (e.g., an Ethernet header). The source and destination addresses of the layer-3 header can correspond to the IP addresses of sender and receiver devices114and111, respectively. The source and destination addresses of the layer-2 header can correspond to the media access control (MAC) addresses of sender device114and locally coupled switch102, respectively.

Based on the information in header180, NIC140can send header packet144to switch102. Subsequently, based on the information in header180, switch102can forward header packet144to switch101. If switch101detects congestion, switch101can determine whether header packet144includes indicator184. When switch101determines the presence of indicator184in header packet144, switch101determines that dropping of header packet144should be avoided, if possible. Accordingly, switch101can forward header packet144to receiver device111based on the information in header180. Because NIC170can receive header packet144in its entirety (i.e., without trimming), NIC170can validate header packet144based on ICV186.

NIC170can obtain semantic information182from header packet144. Because header packet144can be validated, NIC170can consider semantic information182as trusted information. NIC170can then use semantic information182to determine the presence of a subsequent packet. Accordingly, NIC170can schedule the data retrieval and allocate transmit credits to NIC140. Upon receiving the credits, NIC140can obtain payload packet146in accordance with the credits from buffer190and send payload packet146to receiver device111. Because184is not included in payload packet146, switch101(and switch102) may drop payload packet146if flow trimming is initiated due to congestion. On the other hand, if switch101forwards payload packet146, receiver device111can validate payload packet146using ICV196because payload packet146is delivered without trimming.

FIG.2Apresents a flowchart illustrating an example of a process of the forwarding hardware of a switch facilitating flow trimming, in accordance with an aspect of the present application. During operation, the forwarding hardware can receive a plurality of packets that include portions of a data segment sent from a sender device to a receiver device (operation202). To allow the switch to perform flow trimming, the sender device can generate the header and payload packets. The forwarding hardware can identify, among the plurality of packets, one or more payload packets comprising the payload of the data segment, and can at least a header packet comprising header information of the data segment and a header-packet indicator (operation204). The forwarding hardware can distinguish the header packet from the one or more payload packets based on an indicator in the header packet.

The forwarding hardware can determine whether congestion is detected at the receiver device based on the number of sender devices sending packets to the receiver device via the switch (operation206). If the number of sender devices sending packets to the receiver device via the switch reaches a predetermined threshold value, the forwarding hardware may determine congestion at the receiver device. Upon determining congestion at the receiver device (operation208), the forwarding hardware can perform flow trimming by sending the header packet to the receiver device and dropping a subset of the one or more payload packets (operation210). If congestion is not detected, flow trimming may not be necessary. Accordingly, the forwarding hardware can forward the one or more payload packets to the receiver device (operation212).

FIG.2Bpresents a flowchart illustrating an example of a process of a NIC of a computing device generating packets from a data segment, in accordance with an aspect of the present application. During operation, the NIC can generate a header packet comprising header information of a data segment sent from the computing device to a receiver device (operation252). The data segment can be a transport layer data segment generated by a TPD running on the computing system. The NIC can include one or more fields of the header of the data segment in the header packet. The NIC may select the fields that are associated with the semantic information of the data segment for inclusion in the header packet. The NIC can also generate one or more payload packets comprising the payload of the data segment (operation254). The NIC can distribute the payload of the data segment among the one or more payload packets. For example, the NIC can determine the total number of bytes in the data segment and determine the maximum number of bytes a packet can accommodate. The NIC can then distribute the payload of the data segment among the one or more payload packets accordingly.

The NIC can include, in the header packet, a header-packet indicator that distinguishes the header packet from the one or more payload packets (operation256). Here, the header-packet indicator indicates that the header packet may not be dropped. On the other hand, the absence of the header-packet indicator in the one or more payload packets indicates that the one or more payload packets are allowed to be dropped. The NIC can then forward the header packet to the receiver device (operation258). The NIC can store the one or more payload packets in a buffer, transmission from which is controlled by the receiver device (operation260). The NIC can transmit from the buffer if the receiver device issues corresponding transmit credits.

FIG.3illustrates an example of communication facilitating flow-trimming-based congestion management, in accordance with an aspect of the present application. An HPC environment300can include a network330comprising switches351and352. Nodes331and334can operate as receiver and sender devices, respectively. During operation, switch351can detect congestion in network330and initiate flow trimming (operation302). If the number of sender devices sending packets to receiver device331via switch351reaches a predetermined threshold value, switch351may determine congestion at receiver device331. When NIC340of sender device334receives segment342of transport layer data flow380from TPD360, NIC340can generate header packet344comprising header information of segment342and payload packet346comprising payload of segment342(operation304). NIC340can include a payload-packet indicator in header packet344, thereby indicating that packet344is less likely to be dropped when flow trimming is initiated. NIC340can buffer payload packet346(operation306) and send header packet344(operation308). Switch352can forward header packet344toward receiver device331via switch351.

Upon receiving header packet344, forwarding hardware350of switch351can parse header packet344and detect the indicator in header packet344(operation310). Here, forwarding hardware350can check a predetermined location in payload packet344(e.g., in a header field) and determine that the location includes a predetermined value representing the indicator. Since the indicator indicates that header packet344is less likely to be dropped, upon identifying the indicator, forwarding hardware350can refrain from dropping header packet344and forward header packet344to receiver device331(operation312). NIC370of receiver device331can then determine the semantic information from header packet344(operation314). Because the semantic information quantifies the payload of segment342and indicates how the payload is distributed (e.g., in one payload packet), the semantic information allows NIC370to schedule the data retrieval (operation316). For example, NIC370can issue transmit credit based on the number of bytes in payload packet346. Accordingly, NIC370can allocate credits to sender device334and provide the credits to switch351for forwarding to sender device334(operation318). The credits allow sender device334to forward packets to receiver device331. Switches351and352can forward the credits to sender device334. Upon receiving the credits, NIC340can send payload packet346to receiver device331(operation320). When forwarding hardware350receives payload packet346, forwarding hardware350can detect the absence of the indicator in payload packet346(operation322). For example, forwarding hardware350can check the predetermined location for the indicator in payload packet346and determine that the location does not include a predetermined value representing the indicator. Therefore, forwarding hardware350can drop payload packet346, thereby performing flow trimming on data flow380.

FIG.4Apresents a flowchart illustrating an example of a process of a sender device generating packets from a data flow, in accordance with an aspect of the present application. During operation, the sender device can determine a data segment of a data flow (operation402). The data segment can be issued from a TPD of the sender device through a network protocol stack. The NIC of the sender device may then obtain the data segment via the stack. The sender device can then generate a header packet from the header of the segment (operation404) and include a header-packet indicator in the header packet (operation406). The sender device can include one or more fields of the header of the data segment in the header packet. The sender device may select the fields that are associated with the semantic information of the data segment for inclusion in the header packet. The indicator can indicate that the header packet is less likely to be dropped. The sender device can also generate a payload packet from the payload of the segment (operation408) and store the payload packet in a local buffer (e.g., in the NIC) (operation410). The sender device can determine the total number of bytes in the data segment and determine the maximum number of bytes a packet can accommodate. The sender device can then include the payload of the data segment at least in the payload packet. The transmission from the buffer can be dependent upon transmit credits issued by the receiver device. The sender device can send the header packet to the receiver device (operation412).

FIG.4Bpresents a flowchart illustrating an example of a process of a switch processing applying flow trimming to packets, in accordance with an aspect of the present application. During operation, the switch can receive a packet (operation452) and determine whether flow trimming is initiated (operation454). The flow trimming can be initiated if congestion is detected at the receiver device. If the number of sender devices sending packets to the receiver device via the switch reaches a predetermined threshold value, the switch may detect congestion at the receiver device. If flow trimming is initiated, the switch can start looking for packets that can be dropped. Accordingly, the switch can determine whether a header-packet indicator is present in the packet (operation456). If flow trimming is not initiated (operation454) or the indicator is present (operation456), the switch can forward the packet (operation460). On the other hand, if the indicator is not present in the packet, the switch can determine that dropping is allowed for the packet. Hence, the switch can drop the packet (operation458).

FIG.5presents a flowchart illustrating an example of a process of a receiver device processing packets, in accordance with an aspect of the present application. During operation, the receiver device can receive a header packet (operation502) and determine semantic information from the header packet (operation504). The semantic information can include information from one or more fields of a header of a data segment. The semantic information can indicate the number of bytes of the data segment to be retrieved from the sender device and how the bytes are distributed (e.g., across how many packets). The receiver device can then identify the payload packet(s) awaiting retrieval based on the semantic information (operation506) and schedule the retrieval of the payload packet (operation508). The semantic information can indicate the number of payload packets and the payload bytes in the payload packets. The receiver device can schedule the retrievals in such a way that the retrievals do not cause congestion at the receiver device. Based on the schedule, the receiver device can send transmit credits to the sender device at the scheduled time and allocate a buffer for the payload packet(s) (operation510). Since the sender device can only transmit packets upon receiving transmit credits, the receiver device can manage when to receive traffic from the sender device by scheduling the retrievals and sending transmit credits accordingly.

FIG.6illustrates an example of a computing system facilitating flow-trimming-based congestion management, in accordance with an aspect of the present application. A computing system600can include a set of processors602, a memory unit604, a NIC606, and a storage device608. Memory unit604can include a set of volatile memory devices (e.g., dual in-line memory module (DIMM)). Furthermore, computing system600may be coupled to a display device612, a keyboard614, and a pointing device616, if needed. Storage device608can store an operating system618. A flow management system620and data636associated with flow management system620can be maintained and executed from storage device608and/or NIC606.

Flow management system620can include instructions, which when executed by computing system600, can cause computing system600to perform methods and/or processes described in this disclosure. Specifically, if computing system600is a sender device, flow management system620can include instructions for generating header and payload packets from a data segment (packet logic block622). Flow management system620can also include instructions for including an indicator in the header packet (indicator logic block624). Flow management system620can include instructions for generating respective ICVs for the header and payload packets (encryption logic block626). Flow management system620can include instructions for encrypting the header and payload packets (encryption logic block626).

If computing system600is a receiver device, flow management system620can include instructions for sending transmit credits to a sender device (packet logic block622). Flow management system620can then include instructions for determining the presence of an indicator in a packet (indicator logic block624). Flow management system620can also include instructions for validating a respective packet based on a corresponding ICV (encryption logic block626).

Flow management system620may further include instructions for sending and receiving packets (communication logic block628). Data636can include any data that can facilitate the operations of flow management system620. Data636can include, but is not limited to, semantic information of a data segment, payload data to be transmitted, header and payload packets, and an indicator.

FIG.7illustrates an example of a computer-readable memory device that facilitates flow-trimming-based congestion management, in accordance with an aspect of the present application. Computer-readable memory device700can comprise a plurality of units or apparatuses which may communicate with one another via a wired, wireless, quantum, light, or electrical communication channel. Memory device700may be realized using one or more integrated circuits, and may include fewer or more units or apparatuses than those shown inFIG.7.

Further, memory device700may be integrated with a computer system, or integrated in a device that is capable of communicating with other computer systems and/or devices. For example, memory device700can be NIC in a computer system. Memory device700can comprise units702-708, which perform functions or operations similar to logic blocks622-628of flow management system620ofFIG.6, including: a packet unit702; an indicator unit704, an encrypt unit706; and a communication unit708.

FIG.8illustrates an example of a switch supporting flow-trimming-based congestion management, in accordance with an embodiment of the present application. A switch800, which can also be referred to as networking equipment800, can include a number of communication ports802, a packet processor810, and a storage device850. Switch800can also include forwarding hardware860(e.g., processing hardware of switch800, such as its application-specific integrated circuit (ASIC) chips), which includes information based on which switch800processes packets (e.g., determines output ports for packets). Packet processor810extracts and processes header information from the received packets. Packet processor810can identify a switch identifier (e.g., a MAC address and/or an IP address) associated with switch800in the header of a packet.

Communication ports802can include inter-switch communication channels for communication with other switches and/or user devices. The communication channels can be implemented via a regular communication port and based on any open or proprietary format. Communication ports802can include one or more Ethernet ports capable of receiving frames encapsulated in an Ethernet header. Communication ports802can also include one or more IP ports capable of receiving IP packets. An IP port is capable of receiving an IP packet and can be configured with an IP address. Packet processor810can process Ethernet frames and/or IP packets. A respective port of communication ports802may operate as an ingress port and/or an egress port.

Switch800can maintain a database852(e.g., in storage device850). Database852can be a relational database and may run on one or more database management system (DBMS) instances. Database852can store information associated with routing and configuration associated with switch800. Forwarding hardware860can include a congestion management logic block830that facilitates flow trimming in a network. Congestion management logic block830can include a detection logic block832and a trimming logic block834. Congestion management logic block830can determine whether there is congestion at a receiver device. If the number of sender devices sending packets to the receiver device via switch800reaches a predetermined threshold value, congestion management logic block830may determine congestion at the receiver device. Upon detecting congestion, congestion management logic block830can initiate flow trimming at switch800. Detection logic block832can detect whether a packet received via one of ports802includes a header-packet indicator. Trimming logic block834can, during congestion, drop a payload packet if the payload packet does not include the indicator while forwarding the header packet.

The description herein is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed examples will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other examples and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not limited to the examples shown, but is to be accorded the widest scope consistent with the claims.

One aspect of the present technology can provide a piece of networking equipment facilitating efficient congestion management. During operation, the forwarding hardware of the networking equipment can receive, via a network, a plurality of packets that include portions of a data segment sent from a sender device to a receiver device. The forwarding hardware can identify, among the plurality of packets, one or more payload packets comprising the payload of the data segment, and at least a header packet comprising header information of the data segment and a header-packet indicator. The forwarding hardware can determine whether congestion is detected at the receiver device based on a number of sender devices sending packets to the receiver device via the networking equipment. Upon determining congestion at the receiver device, the forwarding hardware can perform flow trimming by sending the header packet to the receiver device and dropping a subset of the one or more payload packets.

In a variation on this aspect, the forwarding hardware can distinguish the header packet from the one or more payload packets based on the header-packet indicator.

In a further variation, if the congestion is not detected, the forwarding hardware can forward the one or more payload packets to the receiver device.

In a variation on this aspect, the header information can include semantic information that quantifies the payload of the data segment and indicates distribution of the payload.

In a further variation, the forwarding hardware can receive transmit credits from the receiver device. Here, the transmit credits can correspond to the one or more payload packets and can be generated based on the semantic information. Subsequently, the forwarding hardware can send the transmit credits to the sender device.

In a variation on this aspect, the data segment can be a transport layer data segment generated at the sender device.

In a variation on this aspect, the networking equipment can be in the network coupling the sender device and the receiver device.

Another aspect of the present technology can provide a computing system facilitating efficient congestion management. During operation, a NIC of the computing system can generate a header packet comprising header information of a data segment sent from the computing system to a receiver device. The NIC can also generate one or more payload packets comprising payload of the data segment. The NIC can then include, in the header packet, a header-packet indicator that distinguishes the header packet from the one or more payload packets. Subsequently, the NIC can forward the header packet to the receiver device and store the one or more payload packets in a buffer, transmission from which can be controlled by the receiver device.

In a further variation, the header information can include semantic information that quantifies the payload of the data segment and indicates distribution of the payload.

In a further variation, the NIC can receive transmit credits from the receiver device. The transmit credits can correspond to the one or more payload packets and are generated based on the semantic information.

In a further variation, the NIC can determine a subset of the one or more payload packets corresponding to the transmit credits. The apparatus can then send the subset of the one or more payload packets to the receiver device.

In a variation on this aspect, the absence of the header-packet indicator in the one or more payload packets indicates that the one or more payload packets are allowed to be dropped.

In a variation on this aspect, the data segment can be a transport layer data segment generated at the computing system.

In a variation on this aspect, the NIC can individually encrypt the header packet and the one or more payload packets.

The methods and processes described herein can be executed by and/or included in hardware logic blocks or apparatus. These logic blocks or apparatus may include, but are not limited to, an application-specific integrated circuit (ASIC) chip, a field-programmable gate array (FPGA), a dedicated or shared processor that executes a particular software logic block or a piece of code at a particular time, and/or other programmable-logic devices now known or later developed. When the hardware logic blocks or apparatus are activated, they perform the methods and processes included within them.

The foregoing descriptions of examples of the present invention have been presented only for purposes of illustration and description. They are not intended to be exhaustive or to limit this disclosure. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. The scope of the present invention is defined by the appended claims.