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: 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 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 network interface that provides improved processing of received packets in a networked computer by classifying packets as they are received. Further, both the characteristics used by the network interface to classify packets and the processing performed on those packets once classified may be programmed. The network interface contains multiple receive queues and one type of processing that may be performed is assigning packets to queues based on classification. A network stack within an operating system of the networked computer can route packets classified by the network interface to application level destinations with reduced processing. Additionally, the priority with which packets of certain classifications are processed may be used to allocate processing power to certain types of packets. As a specific example, a computer subjected to a particular type of denial of service attack sometimes called a “SYN attack” may lower the priority of processing SYN packets to reduce the effect of such an attack.

Abstract: Sleeping device(s) may be changed from a sleeping state to an awake state using a multicast packet that sent to a multicast address of a multicast wake-up group. The packet may include an identifier for one or more particular device(s) in the multicast group, which, when received by the device(s), causes the device(s) to wake up.

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 the transmitting node receives a selective acknowledgement from the receiving node, since a selective acknowledgement may indicate that congestion on the network is only temporary.

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: 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: 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: 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.