I have the following simple network topology:
When I start the TCP connection on PC2, iperf reports the correct RTT which is around 100ms, however when I capture the traffic using wireshark again on PC2 and try to analyze the RTT. The RTT given by Wireshark is very small compared to what it should be. My question what is the cause of this behavior? asked 10 Nov '16, 12:45  Hany Assasa edited 10 Nov '16, 13:15 |
One Answer:
When the client runs at the same PC like netem (PC2), Wireshark shows the actual RTT (the delay from the SYN packet sent by the client to the SYN,ACK sent by the server) as seen on the wire because the client's SYN packet is delayed before reaching the wire and the server's SYN,ACK packet is delayed on the way from the wire to the IP stack, and netem is further from the wire than libpcap. If you swap the roles and run the client at PC1 and server at PC2, the values shown by iperf and Wireshark should match. answered 10 Nov '16, 13:36  sindy It's probably another example of why capturing on one of the two systems involved is not a good idea. A third, independent capture PC between sender and receiver should show what really happens. (11 Nov '16, 01:00) Jasper ♦♦ @Jasper, I disagree, for this particular case it is irrelevant whether you capture "in the middle of the wire" or at one end of it. The problem here is that the delay is inserted between the wire and the client application, and the RTT is evaluated as "SYN+ACK.timestamp - SYN.timestamp". So the "software delay" between the wire and the application has to be inserted at the server end. (11 Nov '16, 02:24) sindy @sindy okay, maybe I'm overthinking this. I always evaluate RTT via SYN - SYN/ACK - ACK. (11 Nov '16, 03:20) Jasper ♦♦ Why? So to me, both (SYN to SYN/ACK delay) and (SYN/ACK to ACK) delay contain the complete round trip, i.e. one pass through the client->server path and one pass through the server->client path (and should thus be almost the same). So maybe you calculate the RTT as an average of the two? The problem here that the delay is not in the network but between the NIC and the application (iperf in this case) at one of the ends. So yes, I should probably extend my answer as "if you look at the SYN to SYN/ACK distance in the capture, the netem must run at server side; if you measure the SYN/ACK to ACK value, the netem must run at client side". (11 Nov '16, 03:55) sindy @sindy I need to be able to determine RTT via the handshake no matter where the capture device is placed, because for best capture quality I cannot capture on either client or server as the results are always biased. SYN to SYN/ACK and SYN/ACK to ACK are not good enough unless you're on or very close to client or server. How I do this I documented here: https://blog.packet-foo.com/2014/07/determining-tcp-initial-round-trip-time/ (11 Nov '16, 04:10) Jasper ♦♦ OK, @Jasper, your article covers the generic case (very nicely as always). I was trying to share the perspective of the OP who captures either at client or at server machine, except that the path causing the delay is not between the two machines as usually but inside one of the machines. Also, the iperf always measures the RTT from the point of view of either the server or the client, not from the middle of the path. (11 Nov '16, 04:24) sindy Thanks @sindy, and you're right, this question is more about a different aspect of RTT. (11 Nov '16, 04:30) Jasper ♦♦ showing 5 of 7 show 2 more comments |
Which PC is running Wireshark? Which side reports this RTT? Both, or just the client? Can you post a short piece of trace in a public location? Since it is iperf traffic, there should not be any confidentiality issues.
@Bob Jones, I added more description. Tomorrow I will upload the capture files.