I'm considering these packets as "Bad TCP" (as suggested by Laura C) (tcp.analysis.flags) && !(tcp.analysis.window_update) I'm just curious at what % should I start getting worried and start digging through the OSI layers. asked 26 Mar '15, 10:29  patrick_harrold |
One Answer:
The "Bad TCP" coloring rule (tcp.analysis.flags && !tcp.analysis.window_update) is a quick indicator of what's wrong with TCP communications in a trace file, but it's a crude measure, so we really can't give a percentage that's meaningful. While it matches mostly bad things, it also includes things that aren't necessarily bad, such as out-of-order packets, and Keep-Alive and Keep-Alive ACK packets. Also, note that Wireshark can misidentify out-of-order packets as retransmissions and vice versa. In the case of packet loss, for each lost packet there should ideally be one retransmission. However, the number of duplicate ACKs will very greatly depending on the round-trip time between the two systems. So if the systems are close together, for each lost packet you will see (depending on where you're capturing) one "previous segment not captured," one retransmission or fast retransmission, and a small number of duplicate ACKs. If the systems are far apart, you will see one "previous segment not captured," one retransmission or fast retransmission, and a large number of duplicate ACKs. Since duplicate ACKs match the Bad TCP rule, the percentage of Bad TCP will vary simply based on how far apart the two systems are, even though the actual level of packet loss might not be very different. Obviously, the smaller the percentage of Bad TCP the better, but you need to do a deeper analysis than just comparing to a percentage. answered 26 Mar '15, 14:14  Jim Aragon |
Thanks for the detailed reply Jim.
I never knew that tcp.analysis.flags also included keep-alive packets, and had not considered that the out-of-order packets were not necessarily "bad."And a single duplicate ACK is probably acceptable in most cases.
It seems that for this specific filter there is no ball-park percentage/rule. However, do you have a suggested filter that you might use for an initial look at the overall health of a specific trace? Any pointers/links/etc would be very appreciated.
You can filter a lot of the false positives with:
&& !tcp.analysis.duplicate_ack_num > 1
chained to the end of your filter.
It wont make it better, but it will show you fewer chains and give you a more realistic feel for the amount of retransmissions. Most retransmissions will then appear with an "Out Of Order" or "Previous segment not captured" in close proximity.