I'm currently trying to find a method that identifies TCP retransmission
and out-of-order in TCP flows from the monitor's point of view.
Keeping previous sequence numbers (and cleaning them out after the
acknowledgement) in the list and seeing if the current sequence number
is already in the list or not, could be a simple approach for
identifying retransmissions.
However, in this case, we cannot detect segments which are lost before
the monitoring point.
Thus, I think that following scenario should be considered as a
retransmission.
[A] - [B] (lost before the analyzer) - [C] - [B] (Retransmission)
So, the analyzer sees [A] - [C] - [B].
In this case, when the analyzer processes the segment B (the last
segment), the analyzer can realize that the segment is re-sent because
the sequence number of B is smaller than the latest seen segment (C).
Now, the ambiguousness is caused when we consider the out-of-order. See
the following scenario:
[A] - [C] - [B] (Delayed)
The analyzer sees the same sequence numbers in the same order as the
previous scenario shows. However, the segment B here is not a
retransmission.
Is there any good methods for distinguishing retransmissions from
out-of-orders?
Is there any good methods for distinguishing retransmissions from
out-of-orders?
A fairly robust method involves estimating the connection's minimum RTT
and then attributing out-of-sequence packets to reordering if their
interarrival time is less than an RTT, and to retransmission otherwise.
This will fail for very large reordering intervals, but from measurement
studies those are quite rare.
For some flows, you can also inspect the IPID field (or I guess timestamps,
if present, though I don't know if anyone has tried that). If it normally
increases monotonically, then a step backward is a strong indicator of
reordering.
(Note, we're planning for the next Bro release to contain a bunch of
transport analysis, including detection of reordering and retransmission.)
I just found out that Wireshark uses a fixed amount of time (3ms) instead of
the minimum RTT.
Do you have any idea where this number came from?
I would assume they just figured it was a resonable cutoff. Most reordering
is indeed quite short-lived, but 3ms strikes me as aggressive in this regard.
Tracking the RTT can be a headache, too, though, if the vantage point isn't
known to be near a data sender. But it's more sound.
I didn't check the source code of tcptrace yet, but it seems that
tcptrace doesn't detect retransmission as I expected. I think tcptrace
identifies a segment as a retransmission only when the same sequence
number is seen multiple times.
As was mentioned earlier in this thread, it treats any packet with a
sequence number below a hole as reordering. That's incorrect if packets
can be lost upstream from the monitoring point.