Previous Contents Next

nifretx: Retransmissions Report

This program post-processes the output of nifpan, and is used to automatically detect lost and retransmitted TCP packets. The nifpan text file being used as input must have been generated with -v2 or -v3 (ie. detail levels 2 or 3).

Its output file is a modified version of the input file, in which all lines that represent a TCP retransmission are flagged as such. At the end of the file, a statistical summary is printed, which shows a sorted table of the retransmission ratios for each connection.

This utility therefore has two main uses:

Run nifretx on a nifpan text file that represents a particular session, and search for the strings RETX and LOST (see format description below) to quickly locate the retransmissions and losses (if any), and then inspect the surrounding packets to determine the effect this had on the connection.
Run nifretx on a nifpan text file which represents a day's (or week's, etc) worth of TCP traffic for the services of interest (eg. WWW and FTP server traffic), and then use the sorted summary table at the end, to determine which remote locations are experiencing above average rates of retransmissions and losses.

Note that when originally running niftap to create the logfile that will eventually be fed into nifretx, the snapshot length can be set low enough to capture the TCP header only, there is no need to capture TCP data. In a typical scenario, with no LLC layer and no IP options, this means that -t60 would be enough.
However, truncating the captured packets means that checksums cannot be verified, so if you suspect that corrupt checksums are the reason for retransmissions, you need to turn off truncation (ie. use -t0), when running niftap.

Also note that on a session that represents outgoing data packets, lost packets will be manifested as retransmissions, and on a session that that represents incoming data packets, lost packets will be detectable by means of out-of-sequence packets, ie. if you see out-of-sequence packets coming in, that is because their predecessors got lost.

Command-line Syntax
Report Format

Command-Line Syntax

nifretx reads the nifpan text file on its standard input, and writes its report to standard output.

nifretx [-d | -l]

nifretx -h

-d The statistics summary table at the end is to be sorted by the number of data packets, ie. display the busiest connections first. The default is to sort by the retransmissions ratio, ie. ratio of retransmitted data packets, to the total number of data packets.

-l The statistics summary table at the end is to be sorted by the number of out-of-sequence data packets.

-h Display a usage synopsis.

Report Format

It is important to be aware that when this program processes a nifpan text file, it creates 2 internal entries for each TCP connection, because it treats each direction of packet flow between a unique pair of TCP/IP addresses independently.
eg. if TCP port 80 on host alpha is connected to TCP port 33132 on host beta, then all Acks and data packets sent from alpha to beta are considered to be one nifretx "connection", and all Acks and data packets sent in the other direction are treated as an unrelated connection.
This manual refers to each such nifretx entry as a "half-connection".

Any TCP packet whose initial sequence number is less than the next expected sequence number for that half-connection is treated as a retransmission.
Any packet that consumes sequence numbers is treated as a data packet, for the purpose of this program (eg. SYN and FIN packets).

1) Retransmitted Data Packets

nifpan lines that represent retransmitted data packets have a retransmission marker added to them, an example entry is shown here, in which the marker appended by this program is indicated in red.

- Evt=167 (17.606377): ETH; IP: alpha->beta , id=56032.0; %TCP: 443->34475 , seq=717970-719429, ack=90791, win=8760; data=1460 [] -- RETX=2 (3/13) next=725270

The initial 2 indicates that this is the second consecutive data-packet retransmission for this half-connection. Such a sequence is broken by the transmission of any original packet (data or ack), and is neither broken nor extended by a retransmitted Ack (ie. a packet with no data).
The 3 in brackets means that this brings the number of data-packet retransmissions for this half-connection to 3.
The 13 in brackets means that this is the 13th data packet sent so far, for this half-connection. This figure includes retransmissions and originals.
The next value indicates the next expected TCP sequence number for this half-connection. In this example, we were expecting 725270, which means that it has already sent packets spanning sequence numbers up to 725269 incl.

2) Original Data Packets

nifpan lines that represent original data packets have an "OK" marker appended to them, which is analagous to the retransmission marker explained above.

- Evt=168 (17.606377): ETH; IP: alpha->beta , id=56032.0; %TCP: 443->34475 , seq=717970-719429, ack=90791, win=8760; data=1460 [] -- OK=1 (9/11)

The initial 1 indicates that this is the 1st in a sequence of successive original data packets (ie. last data packet was a retransmission). Such a sequence is broken by the retransmission of any packet (data or ack), and is neither broken nor extended by a original Ack (ie. a packet with no data).
The 9 in brackets means that this brings the number of original data packets for this half-connection to 9.
The 11 in brackets means that this is the 11th data packet sent so far, for this half-connection. This figure includes retransmissions and originals.

OK entries may end with a string such as LOST=1460
This means that this packet is out-of-sequence, ie. it is an original transmission, but some earlier packets have been lost. The number is the number of missing bytes, eg. this example is 1460 bytes ahead of the next packet we were expecting, in the data stream.

3) Acks

nifpan lines that represent TCP Acks (ie. packets with no data) simply have the string "OK" or "RETX" (and possibly "LOST" as well) appended to them, to indicate whether their sequence number is original, or has been sent already.
Seeing an Ack marked with "RETX" is very unlikely, and implies that its sender is also a data sender, but did not attach any data to this packet. It does not mean that this is a duplicate Ack.

4) Statistical Summary Table

This is appended to the report, and contains a sorted summary of all the half-connections contained in the nifpan text file. The table can be sorted either by the volume of data traffic, the ratio of retransmitted data packets, or the number of out-of-sequence packets, as explained in the help section above, for the command-line usage.

An example follows:

This file contains 4 transmitter/receiver packet flows.
Sort by: Data-packet retransmissions ratio

- 1: alpha:80 -> beta:34475
Total packets: 28/31, Ok=21, Retx=7, Unordered=0
- 2: alpha:80 -> gamma:33125
Total packets: 20/23, Ok=17, Retx=3, Unordered=0
- 3: beta:34475 -> alpha:80
Total packets: 5/24, Ok=5, Retx=0, Unordered=2
- 4: gamma:33125 -> alpha:80
Total packets: 5/18, Ok=5, Retx=0, Unordered=0

The format of each half-connection summary is therefore:
Total packets: a/b, Ok=c, Retx=d, Unordered=e

a represents the total number of data packets sent
b represents the total number of packets sent (ie. including Acks)
c represents the number of original data packets
d represents the number of retransmitted data packets
e represents the number of out-of-sequence data packets

Therefore sorting by data-packet retransmissions means sorting on the value of d/a, sorting by number of data packets means sorting by a, and sorting by out-of-sequence packets means sorting by e.

Previous Contents Next

-d	The statistics summary table at the end is to be sorted by the number of data packets, ie. display the busiest connections first. The default is to sort by the retransmissions ratio, ie. ratio of retransmitted data packets, to the total number of data packets.
-l	The statistics summary table at the end is to be sorted by the number of out-of-sequence data packets.
-h	Display a usage synopsis.