Abstract: Discovery of intermediate network devices is performed using a technique that piggybacks upon the existing standard TCP (Transport Control Protocol) “SACK” (Selective Acknowledgment) option in a SYN/ACK packet so that discovery information may be shared between pair-wise-deployed peer intermediate devices when a TCP/IP connection (Transport Control Protocol/Internet Protocol) is first established between network endpoints using a conventional three-way handshake. Use of the SACK option is combined with another technique which comprises modifying the original 16-bit value of the TCP receive window size to a special arbitrary value to mark a SYN packet as being generated by a first peer device. The marked SYN when received by the second peer device triggers that device's discovery information to be piggybacked in the SACK option of the SYN/ACK packet. The first device then piggybacks its discovery information in the SACK option of the ACK packet which completes the three-way handshake.

Abstract: Discovery of intermediate network devices is performed using a technique that piggybacks upon the existing standard TCP (Transport Control Protocol) “SACK” (Selective Acknowledgment) option in a SYN/ACK packet so that discovery information may be shared between pair-wise-deployed peer intermediate devices when a TCP/IP connection (Transport Control Protocol/Internet Protocol) is first established between network endpoints using a conventional three-way handshake. Use of the SACK option is combined with another technique which comprises modifying the original 16-bit value of the TCP receive window size to a special arbitrary value to mark a SYN packet as being generated by a first peer device. The marked SYN when received by the second peer device triggers that device's discovery information to be piggybacked in the SACK option of the SYN/ACK packet. The first device then piggybacks its discovery information in the SACK option of the ACK packet which completes the three-way handshake.

Abstract: Methods of tuning a receive window. A receiving device and a sending device may be in communication over a network. The receiving device may advertise a receive window to the sending device. The size of the receive window may be adjusted over time based on one or more connection parameters, application parameters and/or operating system parameters.

Abstract: A computer may be capable of communicating with devices via network through multiple interfaces. When a new connection is to be established, the computer may select an interface to use for the connection. In some embodiments, the interface may be selected based on historical connection information representing the performance of previous network connections that the computer has established through the interfaces.

Abstract: A networked computer with a network interface device to which the network stack can offload a subset of the functions needed to process received data packets. The network interface device can receive a map between connections and application buffers. Upon receipt of a data packet through a connection, the network interface device may use the map to identify an application buffer and transfer the data packet to that application buffer. The network interface device may be programmed to recognize qualifications on data packets appropriate for transfer to an application buffer, such as by receiving the sequence number of the next expected packet. Because the network interface device can recognize packets for transfer to an application buffer by simple comparison of a packet header to the map, additional hardware required in the network interface device to perform the offloaded functions is lightweight.

Abstract: Various technologies related to multi-path communications in a data center environment are described herein. Network infrastructure devices communicate traffic flows amongst one another, wherein a traffic flow includes a plurality of data packets intended for a particular recipient computing device that are desirably transmitted and received in a certain sequence. Indications that data packets in the traffic flow have been received outside of the certain sequence are processed in a manner to prevent a network infrastructure device from retransmitting a particular data packet.

Abstract: Methods of tuning a receive window. A receiving device and a sending device may be in communication over a network. The receiving device may advertise a receive window to the sending device. The size of the receive window may be adjusted over time based on one or more connection parameters, application parameters and/or operating system parameters.

Abstract: Efficiently polling a DMA module to determine if the DMA copying of a packet payload to an application buffer is complete. For communication packets received from a network, a processing module may be configured to poll the DMA module at times when it is likely that the DMA copying of packet payloads is complete. Packets may be received and processed in batches. The polling of the DMA module for a packet belonging to a first batch may be deferred until the processing of a next batch. An exception may occur if a predefined amount of time elapses following the completion of the processing of the first batch before the next batch is received. In response to the predefined amount of time elapsing before the receipt of the next batch, the DMA module may be polled, i.e., prior to the next batch being processed.

Abstract: Methods of tuning a receive window. A receiving device and a sending device may be in communication over a network. The receiving device may advertise a receive window to the sending device. The size of the receive window may be adjusted over time based on one or more connection parameters, application parameters and/or operating system parameters.

Abstract: Discovery of intermediate network devices is performed using a technique that piggybacks upon the existing standard TCP (Transport Control Protocol) “SACK” (Selective Acknowledgment) option in a SYN/ACK packet so that discovery information may be shared between pair-wise-deployed peer intermediate devices when a TCP/IP connection (Transport Control Protocol/Internet Protocol) is first established between network endpoints using a conventional three-way handshake. Use of the SACK option is combined with another technique which comprises modifying the original 16-bit value of the TCP receive window size to a special arbitrary value to mark a SYN packet as being generated by a first peer device. The marked SYN when received by the second peer device triggers that device's discovery information to be piggybacked in the SACK option of the SYN/ACK packet. The first device then piggybacks its discovery information in the SACK option of the ACK packet which completes the three-way handshake.

Abstract: Methods and apparatus for congestion control in computer networks achieve high burst tolerance, low latency and high throughput with shallow-buffered switches. A method for controlling congestion includes transmitting a set of data packets on a network connection from a first computing device to a second computing device, identifying each data packet in the set of data packets that experienced congestion on the network connection, sending, by the second computing device to the first computing device, a sequence of bits that represents the number of data packets in the set of data packets that were identified as having experienced congestion, and adjusting a rate of transmitting data packets on the network connection based on the sequence of bits sent to the first computing device.

Abstract: Discovery of intermediate network devices is performed using a technique that piggybacks upon the existing standard TCP (Transport Control Protocol) “SACK” (Selective Acknowledgment) option in a SYN/ACK packet so that discovery information may be shared between pair-wise-deployed peer intermediate devices when a TCP/IP connection (Transport Control Protocol/Internet Protocol) is first established between network endpoints using a conventional three-way handshake. Use of the SACK option is combined with another technique which comprises modifying the original 16-bit value of the TCP receive window size to a special arbitrary value to mark a SYN packet as being generated by a first peer device. The marked SYN when received by the second peer device triggers that device's discovery information to be piggybacked in the SACK option of the SYN/ACK packet. The first device then piggybacks its discovery information in the SACK option of the ACK packet which completes the three-way handshake.

Abstract: Policy-based routing system and method for a multi-homed computer. Policy-based routing permits or blocks usage of system level route(s) based on user credentials and/or network application(s) associated with a data transfer. The credentials can include information associated with an application, a user, and the like. Optionally, one or more filter(s) can be configured over classifiable field(s), such as credential(s), information associated with a determined proposed route, to statically permit/block route usage and/or to invoke an inspection module (e.g., custom inspection routine) when the filter condition(s) are met.

Abstract: An embodiment of the invention is directed to reducing search-response latency. The closest intermediate server can be located between a client computing device and a search engine. A search query is sent to the intermediate server in a first packet of a transport protocol handshake. A plurality of packets are received from the intermediate server. The plurality of packets are used to open a window associated with a transport protocol. A response related to the search query is received by the client.

Abstract: Creating different congestion control modules (CCMs) that can be plugged into a network communications stack (e.g., a TCP/IP stack). Software abstractions defining transport control events, congestion control algorithms and other information may be exposed by an application programming interface, e.g., of an operating system, and these abstractions may be used to define a CCM. The network communications stack may be configured to select one of multiple available CCMs to control congestion for a given connection. This selection may be based on any of a variety of factors including, but not limited to: network environment; connection path characteristics; connection link characteristics; a value of a socket parameter of an application; other factors; and any suitable combination of the foregoing. Thus, CCMs may be selected and implemented on a per-connection basis.

Abstract: Techniques are provided for adjusting to changes to the latency for a connection between two nodes on a network. In accordance with some embodiments, when a transmitting node encounters a retransmission timeout for a packet sent to a receiving node, the latency for the connection is newly measured and used to calculate a new retransmission timeout period for subsequent transmissions by the transmitting node. In some embodiments, the latency is not newly measured if a selective acknowledgement is received indicating that congestion on the network is only temporary.

Abstract: Disclosed herein is a novel technique that greatly improves the TCP-friendliness of CTCP over such under-buffered network links without degrading the protocol efficiency to utilize the link capacity. Instead of using a pre-defined threshold, the disclosed approach, which may be referred to herein as “CTCP-TUBE,” dynamically adjusts the threshold based on the network setting in which the flow is operating. The backlogged packets of a regular TCP may be estimated along the same path by emulating the behavior of a regular TCP flow in runtime. Based on this, a threshold is set so as to ensure good TCP-friendliness. CTCP-TUBE can automatically adapt to different network configurations and also concurrent competing flows.

Abstract: A computing device participates in network protocol operations when the computing device is in an inactive state. A main processor of the computing device transfers protocol mode instructions and data corresponding to a selected network protocol to a network interface of the computing device, and the network interface executes the protocol mode instructions on behalf of the main processor when the main processor is in the inactive state. The main processor may select a network protocol from two or more network protocols and may download protocol mode instructions and data corresponding the selected network protocol to the network interface. The network interface may compare a received packet to at least one received packet pattern and may respond to the received packet in accordance with a result of the comparison.

Abstract: Policy-based routing system and method for a multi-homed computer. Policy-based routing permits or blocks usage of system level route(s) based on user credentials and/or network application(s) associated with a data transfer. The credentials can include information associated with an application, a user, and the like. Optionally, one or more filter(s) can be configured over classifiable field(s), such as credential(s), information associated with a determined proposed route, to statically permit/block route usage and/or to invoke an inspection module (e.g., custom inspection routine) when the filter condition(s) are met.

Abstract: Aspects of the subject matter described herein relate to selecting a source interface with which to establish a connection. In aspects, a profile for each network location a host has seen is maintained in a data store. The profile includes information about the network interfaces available to a source host at the network location. This information indicates, among other things, the reliability of each interface of the source host. Based on the profile, an interface is selected with which to establish a connection. If the interface is unsuccessful in establishing the connection, the interface is de-prioritized and another interface may be selected.