Windows Vista Networking Technologies - Network Performance

Network Performance

Windows Vista's networking stack also uses several performance optimizations, which allow higher throughput by allowing faster recovery from packet losses, when using a high packet loss environment such as wireless networks. Windows Vista uses the NewReno (RFC 2582) algorithm which allows a sender to send more data while retrying in case it receives a partial acknowledgement, which is acknowledgement from the receiver for only a part of data that has been received. It also uses Selective Acknowledgements (SACK) to reduce the amount of data to be retransmitted in case a portion of the data sent was not received correctly, and Forward RTO-Recovery (F-RTO) to prevent unnecessary retransmission of TCP segments when round trip time increases. It also includes Neighbour Unreachability Detection capability in both IPv4 and IPv6, which tracks the accessibility of neighboring nodes. This allows faster error recovery, in case a neighboring node fails. NDIS 6.0 introduced in Windows Vista supports offloading IPv6 traffic and checksum calculations for IPv6, improved manageability, scalability and performance with reduced complexity for NDIS miniports, and simpler models for writing Lightweight Filter Drivers (LWF). LWF drivers are a combination of NDIS intermediate drivers and a miniport driver that eliminate the need to write a separate protocol and miniport and have a bypass mode to examine only selected control and data paths. The TCP/IP stack also provides fail-back support for default gateway changes by periodically attempting to send TCP traffic through a previously detected unavailable gateway. This can provide faster throughput by sending traffic through the primary default gateway on the subnet.

Another significant change that aims to improve network throughput is the automatic resizing of TCP Receive window. The receive window (RWIN) specifies how much data a host is prepared to receive, and is limited by, among other things, the available buffer space. In other words, it is a measure of how much data the remote transmitter can send before requiring an acknowledgement for the outstanding data. When the receive window is too small, the remote transmitter will frequently find that it has hit the limit of how much outstanding data it can transmit, even though there is enough bandwidth available to transmit more data. This leads to incomplete link utilization. So using a larger RWIN size boosts throughput in such situations; an auto-adjusting RWIN tries to keep the throughput rate as high as is permissible by the bandwidth of the link. Receive window auto tuning functionality continually monitors the bandwidth and the latency of TCP connections individually and optimize the receive window for each connection. The window size is increased in high-bandwidth (~5 Mbit/s+) or high-latency (>10ms) situations.

Traditional TCP implementations uses the TCP Slow Start algorithm to detect how fast it can transmit without choking the receiver (or intermediate nodes). In a nutshell, it specifies that transmission should start at a slow rate, by transmitting a few packets. This number is controlled by the Congestion window – which specifies the number of outstanding packets that has been transmitted but for which an acknowledgement of receipt from the receiver has not yet been received. As acknowledgements are received, the congestion window is expanded, one TCP segment at a time till an acknowledgement fails to arrive. Then the sender assumes that with the congestion window size of that instant, the network gets congested. However, a high bandwidth network can sustain a quite large congestion window without choking up. The slow start algorithm can take quite some time to reach that threshold – leaving the network under-utilized for a significant time.

The new TCP/IP stack also supports Explicit Congestion Notification (ECN) to keep throughput hit due to network congestion as low as possible. Without ECN, a TCP message segment is dropped by some router when its buffer is full. Hosts get no notice of building congestion until packets start being dropped. The sender detects the segment did not reach the destination; but due to lack of feedback from the congested router, it has no information on the extent of reduction in transmission rate it needs to make. Standard TCP implementations detect this drop when they time out waiting for acknowledgement from the receiver. The sender then reduces the size of its congestion window, which is the limit on the amount of data in flight at any time. Multiple packet drops can even result in a reset of the congestion window, to TCP's Maximum Segment Size, and a TCP Slow Start. Exponential backoff and only additive increase produce stable network behaviour, letting routers recover from congestion. However, the dropping of packets has noticeable impacts on time-sensitive streams like streaming media, because it takes time for the drop to be noticed and retransmitted. With ECN support enabled, the router sets two bits in the data packets that indicate to the receiver it is experiencing congestion (but not yet fully choked). The receiver in turn lets the sender know that a router is facing congestion and then the sender lowers its transmission rate by some amount. If the router is still congested, it will set the bits again, and eventually the sender will slow down even more. The advantage of this approach is that the router does not get full enough to drop packets, and thus the sender does not have to lower the transmission rate significantly to cause serious delays in time-sensitive streams; nor does it risk severe under-utilization of bandwidth. Without ECN, the only way routers can tell hosts anything is by dropping packets. ECN is like Random Early Drop, except that the packets are marked instead of dropped. The only caveat is that both sender and receiver, as well as all intermediate routers, have to be ECN-friendly. Any router along the way can prevent the use of ECN if it considers ECN-marked packets invalid and drops them (or more typically the whole connection setup fails because of a piece of network equipment that drops connection setup packets with ECN flags set). Routers that don't know about ECN can still drop packets normally, but there is some ECN-hostile network equipment on the Internet. For this reason, ECN is disabled by default. It can be enabled via the netsh interface tcp set global ecncapability=enabled command.

In previous versions of Windows, all processing needed to receive or transfer data over one network interface was done by a single processor, even in a multi processor system. With supported network interface adapters, Windows Vista can distribute the job of traffic processing in network communication among multiple processors. This feature is called Receive Side Scaling. Windows Vista also supports network cards with TCP Offload Engine, that have certain hardware-accelerated TCP/IP-related functionality. Windows Vista uses its TCP Chimney Offload system to offload to such cards framing, routing, error-correction and acknowledgement and retransmission jobs required in TCP. However, for application compatibility, only TCP data transfer functionality is offloaded to the NIC, not TCP connection setup. This will remove some load from the CPU. Traffic processing in both IPv4 and IPv6 can be offloaded. Windows Vista also supports NetDMA, which uses the DMA engine to allow processors to be freed from the hassles of moving data between network card data buffers and application buffers. It requires specific hardware DMA architectures, such as Intel I/O Acceleration to be enabled.