Looking at multiple capture files and is there a rule of thumb or best practice that says If X percentage of packets in a TCP stream are deemed bad those should be investigated before trying to resolve the main issue? For example If I'm reading this correctly I created a BAD TCP button and when I clicked on it for this entire capture it says 70,637 packets, displayed 4,785 or 6.8% so I assume this means 6.8% of all the packets are considered bad. Is this a problem I should address before moving on?
asked 14 Feb, 12:16
It also is important to understand exactly what BAD TCP is filtering for. If you created the button to display tcp.analysis.flags - that will show you TCP events like retransmissions, duplicate acks, and window updates - among other things.
Some of these are not inherently bad on their own, and may not be directly related to the problem you are troubleshooting. For example, I have a trace I use in training that has several TCP Window Updates that are caught by that filter, but are not the root cause of the delay in the trace.
So some context is important. You could have the filter capture full of TCP events, but have nothing to do with what you are trying to analyze. So it is hard to put a rule of thumb that works for all situations, networks, and applications.
For me, if I capture performance issue between a client and server, filter on that conversation, and then apply the analysis filter, that is when I pay close attention to the errors reported by the tcp.analysis.flags filter. If I see a bunch of retransmissions accompanied by delays, then I will start digging to find the cause of the packet loss.
I hope this is helpful toward answering your question. It is just hard to put a fixed number on such a dynamic thing.
answered 15 Feb, 14:13
If you observe the packets in transit, going from system A to system B and recorded by system C, then you are in trouble.
It would help, if you can upload a trace file and give a few hints on the scenario.
answered 15 Feb, 11:34