Context

• Version of iperf3: Any

• Hardware: Any

• Operating system (and distribution, if any): Any

• Other relevant information (for example, non-default compilers,
  libraries, cross-compiling, etc.): default

Bug Report

In current design of iperf reverse mode, iperf3 client will wait on receiving four state messages from the server before creating receiving threads, those four state messages are: PARAM_EXCHANGE, CREATE_STREAMS, TEST_START, TEST_RUNNING,
After the server sent the TEST_RUNNING, it also starts to send the data packets through the data stream channel.

There is a time gap between the receiving threads being ready and the arrival of the testing data stream. This time gap may not be sufficient for the receive socket buffer to buffer all the data arriving during this period. When the time difference is relatively large, or the receive socket buffer is relatively small, the UDP packets may be dropped or TCP will send ZERO-window signal to suppress source sending.

So, the impacts of this issue on iperf3 could be the following aspects:

• may case unnecessary drop for UDP test.

• may affect the accuracy of the throughput measurement for TCP test.

When will this time gap increase? I think the following factors may affect the time gap:

1. the loss rate of the network path:

   When the path has a certain loss rate, there is a possibility that TEST_RUNNING message will be retransmitted, which will increase the time gap. The higher the loss rate, the longer the time gap.

2. run iperf3 test over a proxy network:

   In a proxy network, the time gap may be longer since the control message and data message MAY BE transmitted through different paths and the path of the control message may have a higher RTT.

@davidBar-On sorry, I need to describe the issue clearly so i closed the original one.

• Expected Behavior

In iperf3 reverse mode, the iperf3 should be in a ready-receiving state when after CREATE_STREAMS was received; or be in a ready-receiving state before TEST_RUNNING.

• Actual Behavior

In iperf3 reverse mode, the iperf3 is in ready-receiving state only after TEST_RUNNING message was received.

• Steps to Reproduce

This issue is not easy to reproduce in general scenarios. I was able to reproduce it on a non-open source proxy project. Therefore, my reproduction steps are not suitable here.

• Possible Solution

1. The client should create the receiving threads as soon as it receives the CREATE_STREAMS message from the server.
2. The client should be in ready-receiving state before TEST_RUNNING state.

Enhancement Request

• Current behavior

• Desired behavior

• Implementation notes