IBM Global Services (IGS) can now analyze TCP/IP performance problems very quickly using a TCP/IP analysis tool that is part of IBM's Network Traffic Analysis (NTA) service offering.

NTA has been available since 1989, with the Web-based TCP/IP analysis tool becoming available in mid-1999.

This article takes you through an analysis using NTA's Web-based TCP/IP tool. We will use a trace file with IP packets captured by a LAN protocol analyzer. An analysis can be done on many LAN-captured traces or an OS/390® packet CTRACE.

Because this tool is on the Web and has a demo function that allows actual analysis of a trace, you can follow along if you have Internet access and Netscape Version 4.5 or higher.

First, go to the demo at ibm.com/services/tsm/nta/. Click on the last picture on this page, with the caption "Login to the System."

A pop-up window will ask for your user ID and password. Enter demo for the user ID, leave the password field blank, and click OK.

The next display shows a list of traces under "Server Files for demo."

Click homework1. This trace will then be highlighted. Now click Detailed Analysis.

This displays a count of IP flows and subprotocols such as TCP. The next-to-last column shows the peak 1-second data rate for all of the connections. Check the TCP radio button and then click Display Problem Virtual Circuits.

The next display shows the problem: 5665 packets with long round-trip times (RTTs). The RTT is the time that elapses between sending a packet and receiving its acknowledgment (ACK). The RTT count is incremented when a packet's RTT is 200 ms or more.

In this example, the tracing is at the server, which is sending the data packets. This means that you actually see the full network time for this socket pair. Keep in mind that the round-trip time (RTT) for data packets received at the trace point, inbound to the server, will simply be the IP stack processing time. In this case, you are able to see the problem clearly because the trace point is at the sender. If you wanted to determine to what extent the 300-ms delay was in the network rather than at the client, you would analyze a trace taken at the destination of the packet flow, which is the client. Although you can quickly see the cause of the poor performance, you still don't know how to improve it.

By clicking the radio button for the socket pair with high RTTs and then clicking Stat Report, you can display a statistical report that shows about 40 fields. Each row represents a 1-second collection of data for this socket pair

(130.147.031.001:00020-->192.168.002.111:01389).

Notice that the RTT columns show consistent values a little less than 300 ms. The data rate is mostly 28,672 bytes per second and the maximum segment size is 512 bytes. That's small and is probably a default value that should be changed. Most important, look at the field labeled Max RcvWin. You will need to be looking at the statistical report after login to NTA to see this field. There are too many fields in this report to display all of them easily in the figure, and therefore, the Max RcvWin field is not shown here. Its value is 8576. This means that the receiver of this socket pair, 192.168.002.111:01389, is sending back an advertised window of 8576 bytes.

Now look at the field labeled Max Unack. This is the count of the maximum number of bytes that are in transit. In other words, it is the number of bytes transmitted by the sender but not yet acknowledged by the receiver. This value can be as large as the advertised window, or the congested window size. Its value is 8192 bytes. The problem is that the advertised window of 8576 bytes is too small. The sender transmits a window of data and waits for an ACK. The ACK takes almost 300 ms to come back. Note that the number of bytes in transit, plus one more packet of 512 bytes, would mean that the number of bytes in transit would be 8704 (8192+512), which is larger than the receiver's advertised window allows.

The number of unacknowledged packets in transit is 16 (8192 ÷ 512). To get better throughput, the client will need to have a larger TCP receive buffer. The current size, 8576 bytes, is not large enough to allow for continuous transmission with a 300-ms round-trip delay. Setting the client's TCP receive buffer to at least 16K bytes should dramatically improve data throughput beyond the current 28 672 bytes per second.

The figure shows only a portion of the fields available in the statistical report that we use to determine the problem cause. There are many other reports available, including "Global" reports that provide information from all packets traced. You can display these reports while you are logged in to the demo.

In summary, this demo shows you how quickly a performance problem can be detected and fixed through a trace analysis using the NTA tools. Saving time when analyzing network performance problems is what NTA is all about. If you have any questions on the NTA service offering, please call the NTA team 1 800 876-8801 or 919 461-5131 from outside the U.S. and Canada, or e-mail us at ntateam@us.ibm.com.