Windows 7 / Networking

---

Efficient Networking

Most network communications-including downloading files, browsing the Web, and reading e-mail-use the TCP Layer 3 protocol. TCP is considered a reliable network protocol because the recipient must confirm receipt of all transmissions. If a transmission isn't confirmed, it's considered lost and will be retransmitted.

However, confirming transmissions can prevent TCP transfers from using all available bandwidth. This happens because TCP breaks blocks of data into small pieces before transmitting them, and recipients must confirm receipt of each piece of the data. The number of pieces that can be sent before waiting to receive confirmation receipts is called the TCP receive window size.

When TCP was designed, network bandwidth was very low by today's standards, and communications were relatively unreliable. Therefore, waiting for confirmation for small pieces of a data block did not have a significant impact on performance. However, now that bandwidth is measured in Mbps instead of Kbps, a small TCP receive window size can slow communication significantly while the computer sending a data block waits for the receiving computer to send confirmation receipts.

Figure below demonstrates how TCP confirms portions of a data block.

TCP works well and does indeed provide reliable transfers over a variety of networks. However, waiting to confirm each portion of a data block causes a slight delay each time a confirmation is required. Just how much delay depends on two factors:

• Network latency Network latency is the delay, typically measured in ms, for a packet to be sent to a computer and for a response to be returned. Latency is also called the round-trip time (RTT). If latency is so high that the sending computer is waiting to receive confirmation receipts, latency has a direct impact on transfer speed because nothing is being transmitted while the sending computer waits for the confirmations.
• How much of the file can be transferred before waiting for confirmation (TCP receive window size) The smaller the TCP receive window size, the more frequently the sending computers might have to wait for confirmation. Therefore, smaller TCP receive window sizes can cause slower network performance because the sender has to wait for confirmations to be received. Larger TCP receive window sizes can improve performance by reducing the time spent waiting for confirmations.

As you can see, high network latency can hurt performance, especially when combined with small TCP receive window sizes. Computers can reduce the negative impact of highlatency networks by increasing the TCP receive window size. However, versions of Windows prior to Windows Vista used a static, small, 64-KB receive window. This setting was fine for low-bandwidth and low-latency links, but it offered limited performance on high-bandwidth, high-latency links. A TCP connection can get with various static values of the receive window over different latency conditions. As you can see, the maximum throughput of a TCP connection with the default receive window of 64 KB can be as low as 5 Mbps even within a single continent and can go all the way down to 1 Mbps on a satellite link.

Windows Vista and Windows 7 include an auto-tuning capability for TCP receive window size that is enabled by default. Every TCP connection can benefit in terms of increased throughput and decreased transfer times, but high-bandwidth, high-latency connections will benefit the most. Therefore, Receive Window Auto-Tuning can benefit network performance significantly across both satellite and WAN links. However, performance on high-speed LANs where latency is very low will benefit less.

Receive Window Auto-Tuning continually determines the optimal receive window size on a per-connection basis by measuring the bandwidth-delay product (the bandwidth multiplied by the latency of the connection) and the application retrieve rate, and it automatically adjusts the maximum receive window size on an ongoing basis. For auto-tuning to dramatically improve the throughput on a connection, all of the following conditions must be true:

• High latency connection For example, RTTs of greater than 100 ms.
• High bandwidth connection For example, greater than 5 Mbps.
• Application does not specify a receive buffer size Some applications may explicitly specify a receive buffer size, which would override the Windows default behavior. This can offer similar benefits on older versions of Windows, but changing the receive buffer size is uncommon.
• Application consumes data quickly after receiving them If an application does not immediately retrieve the received data, Receive Window Auto-Tuning may not increase overall performance. For example, if the application retrieves received data from TCP only periodically rather than continually, overall performance might not increase.

When TCP considers increasing the receive window size, it pays attention to the connection's past history and characteristics. TCP won't advertise more than the remote host's fair share of network bandwidth. This keeps the advertised receive window in line with the remote host's congestion window, discouraging network congestion while encouraging maximum utilization of the available bandwidth.

The Windows Vista and Windows 7 TCP/IP stacks support the following RFCs to optimize throughput in high-loss environments:

• RFC 2582: The NewReno Modification to TCP's Fast Recovery Algorithm The NewReno algorithm provides faster throughput by changing the way that a sender can increase the sending rate when multiple segments in a window of data are lost and the sender receives a partial acknowledgment (an acknowledgment for only part of the data that is successfully received). You can find this RFC at http://www.ietf.org/rfc/rfc2582.txt.
• RFC 2883: An Extension to the Selective Acknowledgment (SACK) Option for TCP SACK, defined in RFC 2018, allows a receiver to indicate up to four noncontiguous blocks of received data. RFC 2883 defines an additional use of the fields in the SACK TCP option to acknowledge duplicate packets. This allows the receiver of the TCP segment containing the SACK option to determine when it has retransmitted a segment unnecessarily and adjust its behavior to prevent future retransmissions. The fewer retransmissions sent, the better the overall throughput. You can find this RFC at http://www.ietf.org/rfc/rfc2883.txt.
• RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP If a packet is lost in a TCP session, TCP assumes that it is caused by network congestion. In an attempt to alleviate the source of the problem, TCP lowers the sender's transmission rate. With ECN support on both TCP peers and in the routing infrastructure, routers experiencing congestion mark the packets as they forward them. This enables computers to lower their transmission rate before packet loss occurs, increasing the throughput. Windows Vista and Windows 7 support ECN, but it is disabled by default. You can enable ECN support with the following command.
  netsh interface tcp set global ecncapability=enabled
  You can find this RFC at http://www.ietf.org/rfc/rfc3168.txt.
• RFC 3517: A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP The implementation of TCP/IP in Windows Server 2003 and Windows XP uses SACK information only to determine which TCP segments have not arrived at the destination. RFC 3517 defines a method of using SACK information to perform loss recovery when duplicate acknowledgments are received, replacing the fast recovery algorithm when SACK is enabled on a connection. Windows Vista and Windows 7 keep track of SACK information on a per-connection basis and monitor incoming acknowledgments and duplicate acknowledgments to recover more quickly when multiple segments are not received at the destination. You can find this RFC at http://www.ietf.org/rfc/rfc3517.txt.
• RFC 4138: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP) Spurious retransmissions of TCP segments can occur with a sudden and temporary increase in the RTT. The Forward Retransmission Timeout (F-RTO) algorithm prevents spurious retransmission of TCP segments. The result of the F-RTO algorithm is that for environments that have sudden and temporary increases in the RTT-such as when a wireless client roams from one wireless access point to another-F-RTO prevents unnecessary retransmission of segments and more quickly returns to its normal sending rate. You can find this RFC at http://www.ietf.org/rfc/rfc4138.txt.