We do have several expert info from wireshark but all are indicative based on the recevied/sent SEQ number with adjacent packets and it is not reflecting the reality on the wire. How can I get the exact percentage/rate of packet loss using wireshark (if I for instance setup a specific lost rate using TC netem). For instance (on receiver side trace): "tcp.analysis.lost_segment" could happen even when there is no packet loss, it could happen when packets received out of order with the next one (the next one will have out-of-order expert info). (also on receiver side trace): there could be multiple instances of "tcp.analysis.duplicate_ack" for single lost packet from the sender since the sender keep sending packets with higher SEQ and the receiver keep sending duplicate ACKs (with SACK option enabled telling sender to just resend the missing SEQ range). So all in all using those filters we can only get a percentage of packets that is related/triggered by packet loss and not the exact packet loss rate/percentage itself which can be configured on Netem, is there a way to get the exact packet loss rate from the trace? I think doing it manually on one TCP stream at the time could work but that is too inefficient. asked 31 Oct '15, 14:33  yhzs8 |
One Answer:
If you try to do it with manually, you won't get exact results for UDP (as there is no SEQ/ACK numbers) and you will face the very same problems that Wireshark has with packets out of order, real missing frames, etc.
You can only determine the exact packet loss by capturing at two places, near the sender and near the receiver, and then compare the capture files. Regards answered 31 Oct '15, 15:48  Kurt Knochner ♦ edited 02 Nov '15, 08:17 |
Yes I only discuss TCP here.
Well by capturing at two places and compare them will become even more manual/inefficient work. I think capturing at the receiver-end should get the exact packet loss under the assumption that the sender is fully TCP-RFC compliant and whatever packet is lost is due to netowrk. from the receiver end trace it should understand those two different kind of packet loss: downstream packet loss resulting in tcp.analysis.lost_segment followed by tcp.analysis.duplicate_ack. upstream packet loss will result in tcp_analysis.retansmission followed by tcp.analysis.duplicate_ack. but as said before those could be false positives and it need to be studied on case-by-case basis.
Can you please elaborate more technically why both side of traces are needed and why we can not be 100% certain if only using receiver-side trace?
It depends on the definition of packet loss. If you define it as missing frames in a TCP conversation (sounds like that's what you are after) then you can detect that at one side by looking at the TCP SEQ/ACK numbers. You will have the same 'problems' as Wireshark, meaning you'll have to take into account packet reordering, duplicates, etc. If you can do that manually or via scripting, you're fine.
Still, just looking at SEQ/ACK may not be good enough as you can still run into out of orders or packet loss after the capture location. Each packet loss needs to be verified specifically by looking at all the symptoms and timings.
Very true. It all depends on the defintion of packet loss and what the OP want's to figure out.
especially in that case (artificial packet loss), you will probaly see DUP-ACK in one direction, but no missing frames in the other direction if re-sending worked, which would always be the case if the TCP stream finished successfully. That's what I meant by 'the same problems as Wireshark'.
As I said: It all depends on the definition of 'packet loss' and one will only get the 'big (correct) picture' by looking at the capture files taken at both sides.