This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

I have the following simple network topology:

  1. Two Laptops using Linux Ubuntu 14.04 and 16.04 with Kernel Version 4.4.0
  2. They are directly connected using 1Gbps Ethernet interface.
  3. PC1: 10.0.0.1/24 & PC2: 10.0.0.2/24
  4. PC2 runs netem to add artificial delay of 100ms
  5. Both laptops run iperf v2.0.9
  6. PC1 runs as a server and PC2 as a client

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%20Assasa's gravatar image

Hany Assasa
21101114
accept rate: 0%

edited 10 Nov '16, 13:15

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.

(10 Nov '16, 13:13) Bob Jones

@Bob Jones, I added more description. Tomorrow I will upload the capture files.

(10 Nov '16, 13:16) Hany Assasa

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.

permanent link

answered 10 Nov '16, 13:36

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

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?

 client                server
    |--------            | \
    |        SYN         |  > forward delay
    |           -------->| /
    |                    |
    |             -------| \
    |      SYN/ACK       |  > return delay
    |<-----              | /
    |                    |
    |--------            | \
    |        ACK         |  > forward delay
    |           -------->| /

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".

           silicon               copper
 client                netem                server
    |--------SYN-------->|                    |
    :                    :                    :
    |                    |                    |
    |                    |--------SYN-------->|
    |                    |<-----SYN/ACK-------|
    :                    :                    :
    |<-----SYN/ACK-------|                    |
    |--------ACK-------->|                    |
    :                    :                    :
    |                    |--------ACK-------->|
(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
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×752
×549
×28
×8

question asked: 10 Nov '16, 12:45

question was seen: 1,440 times

last updated: 11 Nov '16, 04:30

p​o​w​e​r​e​d by O​S​Q​A