Abstract: Methods, systems, and apparatus, including computer-readable storage media for resource isolation between connections with shared hardware resources. A network device, such as a network interface card, is configured to determine dynamic resource limits for each connection, and backpressure each connection individually to avoid a global pause when the shared hardware resources are oversubscribed by the current connections. As a result, slower connections may be paused for exceeding resource limits, protecting faster connections from slowing down because resources are shared between both types of connections. Dynamic resource limits can be generated and updated not only per connection, but also based on subsets of the shared hardware resources assigned to different sources of data, as well assigned to different types of transactions communicated over a connection. A hardware-assisted transport layer can be configured to apply dynamic resource limits individually to different connections.

Abstract: Aspects of the disclosure are directed to establishing and utilizing multiple flows, e.g., data paths, within a single connection between two end points in a network. Packets being transmitted between the endpoints can be load-balanced among multiple flows using a set of flow labels. The flow label is determined using scheduling logic. The flow labels include a flow weight that encodes how the packet is mapped to a given flow. The flow weight may be used to determine a congestion window for each flow in the connection. As packets are communicated between the endpoints, congestion control data and acknowledgement coalescing entries are updated before an acknowledgement is sent. Each flow maintains a counter of the number of acknowledgments received. The number of acknowledgments received is used to implement congestion control.

Abstract: Congestion control by adding a congestion signal tag header to each of one or more transmission packets prior to transmission of the transmission packets by the first node to a second node, the congestion signal tag header specifying one or more congestion signal types and, for each of the congestion signal types, specifying a congestion signal value by providing an initial congestion signal value for the congestion signal value; receiving one or more return packets generated by the second node in response to receipt of the transmission packets, the return packets including a congestion signal reflection header having one or more return congestion signal values, and the return congestion signal values corresponding respectively to the congestion signal types; and determining whether transmission rate control is necessary based on the return congestion signal values.

Abstract: The disclosure provides an approach for enabling network functions to be executed in serverless computing environments. One embodiment employs a per-packet architecture, in which the trigger for launching a serverless computing instance is receipt of a packet. In such a case, each received packet is packaged into a request to invoke network function(s) required to process the packet, and a serverless computing environment in turn executes the requested network function(s) as serverless computing instance(s) that process the packet and return a response. Another embodiment employs a per-flow architecture in which the trigger for launching a serverless computing instance is receipt of a packet belonging to a new traffic flow. In such a case, a coordinator identifies (or receives notification of) a received packet that belongs to a new sub-flow and launches a serverless computing instance to process packets of the sub-flow that are redirected to the serverless computing instance.

Abstract: The disclosure provides an approach for enabling network functions to be executed in serverless computing environments. One embodiment employs a per-packet architecture, in which the trigger for launching a serverless computing instance is receipt of a packet. In such a case, each received packet is packaged into a request to invoke network function(s) required to process the packet, and a serverless computing environment in turn executes the requested network function(s) as serverless computing instance(s) that process the packet and return a response. Another embodiment employs a per-flow architecture in which the trigger for launching a serverless computing instance is receipt of a packet belonging to a new traffic flow. In such a case, a coordinator identifies (or receives notification of) a received packet that belongs to a new sub-flow and launches a serverless computing instance to process packets of the sub-flow that are redirected to the serverless computing instance.