TCP testing

Transmission Control Protocol (TCP) turns the ‘best effort’ nature of IP networks into reliable communication services. Tests are, however, needed to ensure optimal performance.

Communication is essential for the modern society and its enterprises. Many enterprises cover a large geographical area with a number of remote branch offices that also need to be included in the enterprise communication network to get access to applications and services needed for their business.

To ensure they get the performance and quality they need, enterprises typically sign a service level agreement (SLA) with a service provider for their communication through the service provider’s network. The SLA will be based on layer 2-3 parameters and contains worst case values for parameters like bandwidth, latency, packet jitter, frame loss ratio and availability. The service provider can verify that the SLA requirements are met using RFC 2544 and Y.1564 test methodologies. However, even if the tests show that all criteria are fulfilled, the enterprises may complain that they get less bandwidth than expected or that they experience long response times from the applications they use. The reason for the complaints will in many cases be non-optimal configuration of the layer 4 TCP. TCP is the de facto standard way of interconnecting hosts over the internet. 

TCP turns the ‘best effort’ nature of IP networks into reliable communication services by adding mechanisms, which guarantee that data sent over a network will actually be delivered to the recipient in the right order. To achieve this, TCP needs to buffer the data at both the sending and receiving end of a connection. If these buffers are dimensioned incorrectly, customers may experience bandwidth or response time issues. Even though end-to-end TCP connections typically is handled by equipment managed by enterprise IT departments, the service provider will often get complains about degraded network performance in case of TCP layer problems. Therefore, the service providers will benefit from having tools to test and verify the network’s TCP performance and discuss the TCP issues with the enterprises.

In RFC 6349 the Internet Engineering Task Force (IETF) has defined a “Framework for TCP Throughput Testing”, providing a methodology for testing sustained TCP Layer performance. In addition to finding the TCP throughput at the optimal buffer size, RFC 6349 presents metrics that can be used to better understand the results. With RFC 6349 service providers can document their network’s TCP performance to their customers.

TCP

TCP is a transport protocol carried over the Internet Protocol (IP) — together the two protocols are often called the TCP/IP protocol stack. The TCP is a host-to-host protocol; its scope is to provide a reliable process-to-process communication in a multinetwork environment. Where IP provides no guarantee that sent packets are actually delivered to the intended recipient in the right order, TCP detects these problems, retransmits lost data, removes duplicated data and rearranges out-of-order data. TCP provides reliable, ordered and error-checked data delivery between applications communicating through an IP network. Many applications like the World Wide Web, email and file transfer use TCP, and with many users on a network accessing these applications, the number of concurrent TCP connections in the network can be very high. Applications that do not require reliable data delivery can use the connectionless user datagram protocol (UDP), which provides reduced latency and reliability.

TCP is a connection-oriented protocol and includes connection establishment and closing phases. Data received from higher protocol layers are divided into segments with sequence numbers and sent through the network. The receiving end must acknowledge the segments; if the sending end does not receive the acknowledgement (ACK) within a certain time frame, the segment will be retransmitted. TCP sequence numbers are 32 bits long; a sequence number is assigned to each byte sent. When a packet containing a TCP segment is sent, the TCP header will include the sequence number of first byte in the segment. ACK packets include the next sequence number expected by the receiver.

Buffers — or windows — are used at sending and receiving ends to avoid throughput reduction. For each connection, TCP maintains a Congestion Window (CWND), limiting the total number of unacknowledged segments that may be in transit (or be ‘in-flight’) end to end. If the CWND is too large the network may be congested ie, receive more data than it can handle and it will drop some of the data. This will lead to retransmissions, which will reduce the effective TCP throughput. Therefore, algorithms have been defined to avoid undue congestion by adjusting the size of the CWND. The algorithms will increase the CWND size until packets are lost and then find a lower CWND size for the connection. The original TCP congestion avoidance algorithm was known as “TCP Tahoe”, but later many other algorithms have been defined (eg, TCP Reno, TCP New Reno, TCP Vegas, FAST TCP and TCP Hybla).

The sending part can send all the contents of the CWND without receiving any ACKs. When ACKs are received the related part of the CWND is released and can be used for new segments.

RFC 6349

The RFC 6349 “Framework for TCP Throughput Testing” provides a methodology for testing sustained TCP Layer performance. In addition to finding the TCP throughput at the optimal buffer size, RFC 6349 presents metrics that can be used to better understand the results.

RFC 6349 testing is done in three steps: identify the path maximum transmission unit (MTU); identify the baseline round-trip time (RTT) and the bottleneck bandwidth (BB); and perform the TCP connection throughput tests. However, before starting the TCP tests, RFC 6349 recommends that layer 2/3 tests are conducted to verify the integrity of the network. This may be manual measurements of throughput, loss and delay. This can also be done with RFC 2544 tests (although RFC 2544 was not intended for use outside a lab) or Y.1564 tests.

Together with the TCP throughput measurement, RFC 6349 presents metrics that can be used to better understand the results, including: the TCP Transfer Time Ratio; the TCP Efficiency Percentage. These metrics must be measured in each direction.

RFC 6349 based TCP throughput testing and stress load testing is supported by Xena Networks test solutions. To generate test signals with stateful TCP traffic for throughput testing and for generation of a very high number of concurrent TCP connections the Xena Networks testers supporting layer 4-7, XenaScale and XenaAppliance are suitable. Testing at lower layers like RFC 2544 testing is supported by the XenaBay and XenaCompact test chassis equipped with relevant test modules.

Conclusion

Incorrect dimensioning of buffers for the layer 4 TCP may mean that customers experience performance degradation even though service providers can prove that their layer 2/3 IP network operates in accordance with a service level agreement (SLA) signed with the customer.

RFC 6349 provides a methodology for testing sustained TCP Layer performance. In addition to finding the TCP throughput at the optimal buffer size, RFC 6349 presents metrics that can be used to better understand the results. The Xena layer 4-7 test solutions XenaScale and XenaAppliance together with the layer 2-3 test solutions XenaBay and XenaCompact support powerful TCP testing based on RCF 6349. In addition, XenaScale and XenaAppliance support extreme RFC 6349 testing with millions of concurrent TCP connections.