With the Advanced TCP Activity overview you can view the values of advanced TCP activity counters from either the client or server perspective in a client-server relationship.

To get the Advanced TCP Activity overview, select ANALYZE > Overview > IP Traffic > Advanced TCP Activity and then select if you want to view information about TCP client sockets (Client TCP) or TCP server sockets (Server TCP).

To fully understand the Advanced TCP Activity overview it's important that you're familiar with the client-server relationship. In the overview, a server isn't necessarily a computer with a server operating system. Instead, you should view server as the part in a client-server relationship that serves data requested by the client in that relationship.

Whether a computer can be seen as a client, a server, or both, in the overview is determined by the agent configuration group that the computer belongs to: As part of the agent configuration group settings you can specify if the PerformanceGuard agent should automatically collect TCP client socket data reports, TCP server socket reports, or both. This means that if a computer with a regular client operating system has automatic collection of TCP server socket data enabled through the configuration of its PerformanceGuard agent, that computer can be seen as a server in the overview (provided it has been involved in TCP traffic).

When you use the overview, it can be helpful to imagine that the PerformanceGuard agent is the center of the world (click thumbnail to view image in full size):

Client TCP

Select this option when you want to look at TCP client sockets.

1. In the Interval list, select the period of time that you want your overview to cover. If the predefined intervals don't suit you, select Custom to specify your own interval.
   
   
2. Select which Port you want your overview to cover. You can only select between monitored ports, that is ports that you have defined as being particularly interesting to keep an eye on.
   
   
3. In the Agent menu, select whether you want your overview to cover traffic from all client computers or from computers that belong to a particular group of computers.
   
   
4. In the Server menu, select whether you want your overview to cover traffic to all servers or to a particular server. You can only select between monitored servers, that is servers that you have defined as being particularly relevant to keep an eye on.
   
   

5. Click the Update button.
   
   

   Ports, computer groupings and servers are only selectable in the menus if there has been TCP traffic on them. 

Server TCP

Select this option when you want to look at TCP server sockets.

1. In the Interval list, select the period of time that you want your overview to cover. If the predefined intervals don't suit you, select Custom to specify your own interval.
   
   
2. Select which Port you want your overview to cover.
   
   
3. In the Agent menu, select the server from which you want traffic to be covered by your overview. Keep in mind that in the overview's context, the term server means the part in a client-server relationship that serves data requested by the client in that relationship. Thus, in this context, the term server doesn't necessarily mean a computer that has a server operating system.
   
   
4. In the Client menu, select the client to which you want traffic to be covered by your overview.
   
   

5. Click the Update button.
   
   

   Ports, servers and clients are only selectable in the menus if there has been TCP traffic on them. 

Understand the Table of Results

Your results are shown in a table with the following columns:

• Server or Client IP address (depending on which variant of the overview you have selected)
• Protocol.
• Port.
• Samples: The number of performance data samples available for the connection. The higher the number, the higher the validity of the data about the connection.
• RTT Avg (ms): The average sampled round-trip time in milliseconds. Round-trip time (RTT) is the length of time it takes for a client to send a request plus the length of time it takes for an acknowledgment from the server to be received by the client. RTT does therefore not include the time it takes for server applications to respond or the time required for data transfer.
• RTT Max (ms): The maximum sampled round-trip time in milliseconds. In short, this number tells you how bad things have been.
• Current RTO (ms): The current retransmission timeout value in milliseconds. See RTOs in the following.

• RTOs: The number of retransmission timeouts. Retransmissions themselves are bad. Retransmission timeouts (RTOs) are really bad because they really slow down traffic: RTOs occur when senders get too few acknowledgments from receivers and therefore decide to break for a short moment before they attempt to send data again. Once the senders begin to send data again, they do it with a slow start, and this can lead to delays in traffic.

   What's a slow start?

  When a TCP connection is established, the sender carefully tests the capacity of the network by first sending only two packets of data. If that goes well, the sender sends four packets, and so on. The benefit of this is that TCP will ideally not send more data than the network and the receiver are able to handle. The downside is that it takes a while before a TCP connection is working at its full capacity. If slow starts only happen when connections are established, they are generally not a problem. However, if connections often time out and have to be re-established, slow starts can be a great problem because it takes time for the connection to get up to speed again each time it's re-established.

• Spurious RTOs: The number of acknowledgments about data that has already been sent again due to a retransmission timeout (RTO). A spurious retransmission is basically data that was sent again even though the receiver has already acknowledged receipt of it. The number thus tells you about data that has needlessly traveled on the network twice.
• Fast Retran.: The number of invocations of the Fast Retransmit algorithm. A high number of fast retransmissions can indicate a performance issue with a high number of lost frames.
• Bytes Retran.: The number of bytes retransmitted. This number tells you how much data that has been sent again because the original sending failed. The number thus tells you about the amount of data that has traveled on the network twice.
• DupAcksIn: The number of duplicate acknowledgments. This number indicates receptions where data packets were missing or re-ordered.
• selective acks rcvd: The number of selective acknowledgments (SACKs—that's where the receiver explicitly lists which packets, messages, or segments in a stream are acknowledged, either negatively or positively). Again, this number indicates receptions where packets were missing or re-ordered.

• congestion count: The number of times that the size of congestion window has been decreased because the sender detected signs of congestion on the connection. Such signs can be, for example, fast retransmits or timeouts. If the congestion count is high, it tells you that it has often been necessary to decrease the size of the congestion window, which in turn is a sign of a limited ability to successfully send data over the connection.

   What's a congestion window?

  It's a congestion control mechanism that determines the number of outstanding bytes that's allowed on the connection. It's thus a way of preventing the connection from being overloaded. The size of the congestion window is adjusted up/down by the sender based on the amount of data that the sender is able to send and get acknowledged by the receiver. If sent data is successfully received and acknowledged by the receiver, the congestion window will grow exponentially until a timeout occurs, after which the window is reset. When a timeout occurs, and the congestion window is reset, a slow start (see the previous) takes place. It's best if the congestion window is reset as few times a possible.

  Note that retransmission timeouts (RTOs) reduce the size of the congestion window because RTOs determine how often slow starts are required (see What's a slow start? in the previous).
• pre cong sum count: The sum of the values of the congestion window, in bytes, captured each time that the sender detects a sign of congestion.

View Results in a Graph

Some of the values in the table of results are clickable. If you click one of the links, you can view the selected data in the interactive TCP Counters graph. Example:

Export Overview

Once you have generated an overview, you can export it in two formats:

• Excel Export: Export to Microsoft Excel .xls format
• OOXML Export: Export to Office Open XML, a zipped XML-based format