Which tcpdump metrics reveal server connectivity problems vs client problems?

Question

I am attempting to diagnose a ~45 sec drop (to 0 Kbps) in the reported RTMP streaming bitrate in OBS while publishing a live stream. I had been running a tcpdump the entire time using Apple's recommended settings to capture a packet trace.

Here is a graph of all packets

I would like to try to establish if this disruption came because of a connectivity problem between my Desktop computer and the ingestion node in the cloud, or because my Desktop computer itself was glitching, defective, or underpowered somehow while capturing and encoding the video stream from the camera.

Here is a graph of bytes in flight:

You can see that the bytes in flight get disrupted. I'm assuming that, if the ingestion node went offline somehow, the bytes in flight would be consistent, or even start to accumulate as it streamed more and more data and didn't get an ACK back.

Using this blog post, I did an analysis of "Bad TCP" by looking at:

(tcp.analysis.flags && !tcp.analysis.window_update)

and found this:

This seems to indicate a spike in TCP errors, so perhaps this does indicate a connection problem between the Desktop PC and the cloud ingest node. However, when I look at the raw packet capture in Wireshark and filter by (tcp.analysis.flags && !tcp.analysis.window_update), all I see during this time window is TCP Retransmission and TCP Dup ACK.

I also looked at tcp.analysis.ack_rtt, on the assumption that if there was a connection issue the round-trip-time would perhaps increase. However, it seemed to follow a pattern identical to bytes in flight.

(apologies about the differences in the x axis; Wireshark crashes frequently when making these graphs).

Based on these graphs, does this indicate that the issue lies in the connection between my Desktop and cloud ingest node, or does this instead indicate that the issues is on the Desktop machine itself?

I still have the complete 600+ MB pcap file so I can readily extract or produce additional graphs as necessary.

---

Update

Thanks everyone - I am going to rerun this test with a tcpdump on both ends, Desktop and Ingest node, and update with more details. FWIW, right now, it appears that the incident began when the Ingest node slashed the TCP Window Size from 4096 to 1383.

Answer 1

Welcome to Network Engineering. It's difficult to say where the problem lies based on the data you have. Data could be lost from the client to the server, or from the server to the client, and it would look the same.

You will need to capture data at each endpoint - the client AND the server and compare packets to see what actually got lost. For example, the server may send data to the client, but it got lost along the way. Or, the client received the data, but the return ACK was lost. You will need to see both sides in order to tell for sure.

Answer 2

One suggestion is to measure the process that is generating the traffic from your desktop, one symptom is that the process consumes a lot of CPU or memory during the issue, this could potentially indicate that the program that manage the communication can have a problem on the implementation. However, as one user mention in other post, measure both sides is a good idea and also monitor the machine if possible.