Understanding Conversations

Many generic metrics are computed on TCP streams. To be able to interpret these correctly, it may be useful to be aware of a few things.

Client or Server?

To find out which peer is the client, the sniffer tries several options:

• If it understands the protocol at hand (and has successfully identified it), then client/server identification is usually trivial. Unfortunately, most traffic does not fall into this category.
• In TCP, the client is the peer that actively opens the connection (i.e., sends the initial SYN). But we may miss the SYN or we may have forgotten it if we have not received traffic for that socket for more than 2 minutes (especially problematic for lengthy connections such as remote control protocols).
• In either TCP or UDP, we may have indicative port numbers. A port number below 1024 on one side and greater than 1024 on the other is a strong indication of the server location.
• In TCP, we may have seen past SYNs directed at one of the ports, which again gives an indication of that port being the server.
• When all else fails, the server is chosen according to a complex heuristic that’s mostly equivalent to choosing at random.

Keep-Alive

Applicative keep-alives are small messages that are sent from either peer to the other when no traffic has used this socket for some time. They must not be taken into consideration when computing SRT, DTT, and so on. The ica_keepalive_max_size parameter is dedicated to the detection of ICA (citrix) keep-alive messages.

The standard TCP keep-alive packet is normally detected using its size and sequence number, according to the RFC. In case the previous sequence number is unknown, though, the tcp_keepalive_timer may be used as an alternative; after this inactivity period, any TCP packet that looks like a keep-alive will be ignored.

DTT Timeouts

The objective of the TCP DTT metric is to measure the duration of a single write (or of a sequence of closely related writes). For protocols that do not follow the pattern request/response, it is very important to detect when two data transfers are separate in time (suggesting they are unrelated). The tcp_dtt_timeout parameter helps with that. If two packets are separated by more than this duration, they do not belong to the same DTT. By default, it is set to 1s so that neither lost packets nor a full reception buffer would interrupt the DTT, but an actual pause from the sending application will be detected as such.

What is a retransmission?

According to the sniffer, any TCP packet with a payload (or a SYN, a FIN or RST flag) with a sequence number that was already covered is a retransmission (here, covered means that this sequence number was in a packet that has already been analyzed).

Fast retransmission is thus counted as retransmission.

For more information visit Conversation.