This report will focus on the areas of which TCP performance is significantly improved. IETF, RFC, multi-rate networks, wireless networks, TCP/IP, adaptive window, end-to-end performance, TCP improvements with regard to high-performance networks are some of the topics that will be touched on. But more focus will be on improving TCP performance over wireless network and the adaptive window size manipulation and Next Generation TCP/IP under high-loss environments.
Reliable transport protocols such as TCP are tuned to perform well in traditional networks where packet losses occur mostly because of congestion. However, networks with wireless and other lossy links also suffer from significant losses due to bit errors and handoffs. TCP responds to all losses by invoking congestion control and avoidance algorithms, resulting in degraded end-to-end performance in wireless and lossy systems
1.2] Problems with traditional TCP over wireless network:
Ø Assume congestion to be the primary cause for packet losses and unusual delays, while communication over wireless link is often characterized by sporadic high bit-error rates and intermittent connectivity due to handoffs .
Ø Invoke congestion control and avoidance algorithms, resulting in significant degraded end-to-end performance and very high interactive delays .
Chapter 2: Improving TCP performance over large bandwidth*delay product (BDP’s) and very high-speed paths:
2.1] TCP Receive Window and TCP Throughput:
To optimize TCP throughput (assuming a reasonably error-free transmission path), the sender should send enough packets to fill the logical pipe between the sender and receiver. The capacity of the logical pipe can be calculated by the following formula .
Capacity in bits = path bandwidth in bits per second x round-trip time (RTT) in seconds
The capacity is known as the bandwidth-delay product (BDP). The pipe can be fat (high bandwidth) or thin (low bandwidth) or short (low RTT) or long (high RTT). Pipes that are fat and long have the highest BDP. Examples of high BDP transmission paths are those across satellites or enterprise wide area networks (WANs) that include intercontinental optical fiber links .
2.1.1] TCP window scale option:
The window scale extension increases the definition of the TCP window to 32-bits and then uses a scale factor to carry this 32-bit value in the 16-bit Window field of the TCP header. The scale factor is carried in a new TCP option, Window Scale .
A TCP Window Scale option includes a window scaling factor that, when combined with the 16-bit Window filed in the TCP header, can increase the receive window size to a maximum of approximately 1GB .
This option is sent only in a SYN segment(a segment with the SYN bit on), hence the window scale is fixed in each direction when a connection is opened .
Both TCP peers can indicate different window scaling factors to use for their receive window sizes. By allowing a sender to send more data on a connection, TCP window scaling allows TCP nodes to better utilize some types of transmission paths with high BDPs .
Although the receive window size is important for TCP throughput, another important factor for determining the optimal TCP throughput is how fast the application retrieves the accumulated data in the receive window (the application retrieve rate). If the application does not retrieve the data, the receive window can begin to fill, causing the receiver to advertise a smaller current window size. In the extreme case, the entire maximum receive window is filled, causing the receiver to advertise a window size of 0 bytes. In this case, the sender must stop sending data until the receive window has been cleared. Therefore, to optimize TCP throughput, the TCP receive window for a connection should be set to a value that reflects both the BDP of the connection's transmission path and the application retrieve rate .
2.1.2] Receive Window Auto-Tuning in Windows Vista and later:
Receive Window Auto-Tuning enables TCP window scaling by default, allowing up to a 16MB maximum receive window size. As the data flows over the connection, the Next Generation TCP/IP stack monitors the connection, measures its current BDP and application retrieve rate, and adjusts the receive window size to optimize throughput. The Next Generation TCP/IP stack no longer uses the TCPWindowSize registry value .
To optimize TCP throughput, especially for transmission paths with a high BDP, the Next Generation TCP/IP stack in Windows Vista and Windows Server 2008) supports Receive Window Auto-Tuning. This feature determines the optimal receive window size by measuring the BDP and the application retrieve rate and adapting the window size for ongoing transmission path and application conditions .
18.104.22.168] Benefits of Receive Window Auto-tuning:
· It automatically determines the optimal receive window size on a per-connection basis. Applications no longer need to specify TCP window sizes through Windows Sockets options. And IT admin no longer need to manually configure a TCP receive window size for specific computers .
· Windows Vista-based TCP peer will typically advertise much larger receive window sizes than a Windows XP-based TCP peer. This allows the other TCP peer to fill the pipe to the Windows Vista-based TCP peer by sending more TCP data segments without having to wait for an ACK (subject to TCP congestion control) .
· The impact on the network is that a stream of TCP data packets that would normally be sent out at a lower, measured pace, are sent much faster resulting in a larger spike of network utilization during the data transfer .
· Because Receive Window Auto-Tuning will increase network utilization of high-BDP transmission paths, the use of Quality of Service (QoS) or application send rate throttling might become important for transmission paths that are operating at or near capacity. To address this possible need, Windows Vista supports Group Policy-based QoS settings that allow you to define throttling rates for sent traffic on an IP address or TCP port basis .
2.2] Next Generation TCP/IP improvements:
The Next Generation TCP/IP stack supports the following four RFCs in order to optimize throughput in high-loss environments. Examples of high-loss networks are wireless networks, General Packet Radio Service (GPRS), or Universal Mobile Telecommunications System (UMTS)—that can have high packet losses depending on network conditions, signal attenuation, electromagnetic interference, and the changing location of the computer .
2.2.1] RFC 6582: The NewReno Modification to TCP's Fast Recovery Algorithm:
The basic idea of the Fast Recovery algorithm, defined in Section 3.2 of [RFC5681] is as follows. The TCP sender can infer, from the arrival of duplicate acknowledgments, whether multiple losses in the same window of data have most likely occurred, and avoid taking a retransmit timeout or making multiple congestion window reductions due to such an event . Although the Reno algorithm works well for single lost segments, it does not perform as well when there are multiple lost segments .
The NewReno modification applies to the fast recovery procedure that begins when three duplicate ACKs are received and ends when either a retransmission timeout occurs or an ACK arrives that acknowledge all of the data up to and including the data that was outstanding when the fast recovery procedure began .
The NewReno algorithm provides faster throughput by changing the way that a sender can increase their sending rate during fast recovery 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 has been successfully received) .
2.2.2] RFC 2883: An Extension to the Selective Acknowledgment (SACK) Option for TCP:
RFC 2018 specified the use of the SACK option for acknowledging out-of-sequence data not covered by TCP's cumulative acknowledgment field. This note extends RFC 2018 by specifying the use of the SACK option for acknowledging duplicate packets. This note suggests that when duplicate packets are received, the first block of the SACK option field can be used to report the sequence numbers of the packet that triggered the acknowledgment. This extension to the SACK option allows the TCP sender to infer the order of packets received at the receiver, allowing the sender to infer when it has unnecessarily retransmitted a packet. A TCP sender could then use this information for more robust operation in an environment of reordered packets, ACK loss, packet replication, and/or early retransmit timeouts .
2.2.3] RFC 3517: A Conservative Selective Acknowledgment-based Loss Recovery Algorithm for TCP:
The current 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 have been received, replacing the older fast recovery algorithm when SACK is enabled on a connection. The Next Generation TCP/IP stack keeps track of SACK information on a per-connection basis and monitors incoming acknowledgments as well as duplicate acknowledgments to more quickly recover when multiple segments are not received at the destination .
2.2.4] 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 increase in RTT, leading the retransmission timeouts (RTOs) of previously sent segments to begin to expire and TCP to start retransmitting them. If the increase occurs just before sending a full window of data, a sender can retransmit the entire window of data. The F-RTO algorithm prevents spurious retransmission of TCP segments through the following behavior.
When the RTO expires for multiple segments, TCP retransmits just the first segment. When the first acknowledgment is received, TCP begins sending new segments (if allowed by the advertised window size). If the next acknowledgment confirms the other segments that have timed out but have not been retransmitted, TCP determines that the timeout was spurious and does not retransmit the other segments that have timed out.
The result is that for environments with sudden and temporary increases in the RTT, such as when a wireless client roams from one access point to another, F-RTO prevents unnecessary retransmission of segments and more quickly returns to its normal sending rate. The use of SACK-based loss recovery and F-RTO are best suited for connections that use GPRS links .
There are many interesting ways to optimize TCP performance. All of which have extremely worthwhile benefits. The internet protocols are ever evolving and all thanks to a group of people called The Internet Engineering Task Force who are responsible for writing the RFC documents and all those who contribute to improving protocol operations. TCP/IP protocols and others will never stop evolving. It will only get better and better as technology improves. This will provide much more business opportunities and new markets in the future and increase our standard way of living.
V. N. P. Hari Balakrishnan, “A Comparison of Mechanisms for Improving TCP Performance over Wireless Links,” IEEE/ACM TRANSACTIONS ON NETWORKING, vol. 5, no. 6, pp. 3-7, 1997.
J. Davies, “The Cable Guy: TCP Receive Window Auto-Tuning,” TechNet Magazine, 2007. [Online]. Available: https://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx. [Accessed 20 September 2015].
R. B. D. B. V. Jacobson, “RFC 1323: TCP Extensions for High Performance,” Cray Research, May 1992. [Online]. Available: https://www.ietf.org/rfc/rfc1323.txt. [Accessed 27 September 2015].
S. F. A. G. Y. N. T. Henderson, “RFC 6582 : The NewReno Modification to TCP's Fast Recovery Algorithm,” Internet Engineering Task Force (IETF) , April 2012. [Online]. Available: https://tools.ietf.org/html/rfc6582. [Accessed September 2015].
Network Sorcery.Inc, “TCP Option 5, Selective Acknowlegdment,” RFC Sourcebook, 2012. [Online]. Available: http://www.networksorcery.com/enp/protocol/tcp/option005.htm. [Accessed 27 September 2015].
J. M. M. M. S. Floyd, “RFC 2883 SACK Extension,” The Internet Society, July 2000. [Online]. Available: https://tools.ietf.org/html/rfc2883. [Accessed 21 September 2015].