If you look at each line of TCP trace, you'll see at the end of the line the number of bytes included in the TCP data segment that was transmitted. (Octets in Internet-speak, since in the early days some machines on the net used 36-bit words and a byte was not necessarily 8 bits.) At the beginning of the line is the time of the event.
You'll note that each segment sent is ACKed by the TCP receiver. Since this is sometimes you (like during a download), and sometimes the other guy (like when you request a download), you'll see in the second column a pair of port numbers connected by an arrow that tells who was sending and who was receiving. (The remote sender's port number will most likely be the well-known socket for each high-level protocol; e.g. 21 for FTP, or 80 for HTTP. Yours will be some port number available at the time.)
You'll also see reference to the segment's sequence number which is in hexadecimal, and increments each time by the number of data bytes in the segment last sent. In the above example, at time 2718.4 the 512-byte segment beginning with byte number 00000465 was received and receipt of all bytes up to (but not including) 00000665 (an increase of 2*256 in hex) was ACKed. The ACK was clearance to send more data beginning with byte number 00000665, up to a window size of 3776 bytes (512 bytes less than the RWIN setting in this example).
By design, the Internet allows multiple routing paths from the TCP sender to you. Sometimes, this results in IP transmission units containing later TCP data segments arriving before those containing older data segments, as in the next TCP trace:
At time 2594.3, the 512-byte segment beginning with byte number 000928C0 arrived and was ACKed. However, the next transmitted 512-byte segment (beginning with byte number 00092AC0) took a slower route through the Internet and didn't arrive until time 2597.7, after the next 6 transmitted segments (beginning with 00092CC0, 00092EC0, 000930C0, 000932C0, 000934C0 and 000936C0, respectively). Once it did, the entire window-full (which had been held, eventually reducing the available window to only 704 bytes) was ACKed up to byte number 000938C0.
If the TCP sender didn't get your ACK before his RTOmax time-out, he would retransmit a segment you've already "accepted." You will then see unacceptable segment denoting this repeat. You'll note that the sequence number is an older (smaller) number than the other segments you've most recently received.
In the above example, at time 2725.1, a 512-byte segment beginning with byte number 00001A65 was received, but the ACK noted that it was immediately followed by 2 more 512-byte segments which resulted in the ACK of receipt of everything up to byte number 00002065, and reduction of the window from 4288 (RWIN) to 2752. This was followed, at time 2725.6, with ACK of 4 more 512-byte segments, starting with byte 00002065. Unfortunately, the ACK wasn't received by the sender before his RTOmax timeout, so he re-transmitted the 512 bytes from 00002265 to 00002465, which having already been accepted, were now an unacceptable segment.
Repeated unacceptable segment notices with the same sequence number are evidence of more fundamental, underlying reasons for a basic inability to complete even one TCP transaction. They are indicative of packet corruption by errors at lower protocol layers, and you should turn on the Traces for IP (which shows IP addresses) and PPP (which shows PPP frame check errors) in order to try to find the cause.
If you ask for an FTP transfer, you should see a smooth stream of TCP segments, all of the size of your MSS. (If the sender decides to stay within your declared maximum segment size by using a smaller number, they should all be that smaller size - like 512 instead of a requested 536, in the above illustrations). If, on the other hand, you request and he sends 536-byte segments, but some IP router between you can't pass an IP transmission unit larger than 552 bytes, then you'd see alternating fragments of 512 bytes and 24 bytes, and a substantial speed reduction.
If you see groups of the same number of segments (and ACKs), interspersed with significant pauses, you'll know that the number of segments that fit in the RWIN you and the TCP sender are using is more than the number of IP packet buffers your access provider's communications server has allocated per connection. The excess packets are being dropped due to your much slower machine not being able to unload them as fast as they come into your access provider's machine from the Internet. As a result, the TCP sender never gets an ACK for the last segments in the RWIN-full he just sent, so he re-transmits them and waits again; another speed loss. (Some communication servers have a default setting of 3 buffers, so the pattern would be triples of segment/ACK pairs, with pauses after each triple. In that case, reduce your RWIN to 3*MSS while you complain to your ISP.)
NOTE: If everything is just generally slow, try downloading from the same site at different times of the day, to see if it's just traffic loading rather than your settings. If your 28.8Kbps retail access provider is buying his wholesale access in 56Kbps chunks, rather than 1.544MBps full T1 hunks, then he may be your bottleneck. If you're trying to download across trans-oceanic links, it may not be his fault at all. Time of day for the part of the 'net you're traversing, and especially the part from which the TCP segments are being sent, can be a big factor with some downloads.
One tool for measuring speed is Trumpet's TCPmeter program, which can be started once winsock.dll has been loaded. Like the winsock.dll whose performance it monitors, there is a separate version of TCPmeter.exe for each version of TCPMan.
This FAQ is available as a Windows Help® file for off-line viewing
Copyright© 1995 by Albert P. Belle Isle