This is the first post of a series describing our test methodologies. Today, we will focus on the ping test used to choose the test server.
Latency is a factor that considerably influences the transport protocol performances. While the network bandwidth has seen significant increases over the years thanks to medium improvements (Ethernet links from 10 Mbps to 10 Gbps, 802.11b from 11 Mbps to 802.11n at 600 Mbps,…), the network delay remains bounded by a physical limitation: the speed of the light. The more the (physical) distance between hosts, the more the (theoritical) latency lower bound. A client trying to connect to a server located the other side of the world will experience (theoritical) round-trip-time of at least 130 ms. In practice, such hosts will observe larger delays due to the potential presence of congestion, bufferbloat and network processing. This influences the current architecture of the Internet. Websites rely on Content Delivery Networks (CDNs) located close to clients to offer low page load times.
Any service that wants to be accessible world-wide should rely on servers covering several continents. This is why we deployed three test servers: one in France, one in Canada and one in Japan. Those are intended to serve the Europe, the America and the Asia continents, respectively. However, the selection of the “closest” server, defined as the one offering the lowest latency, is not trivial. CDNs often rely on DNS queries, but this could sometimes leads to sub-optimal choices (see for instance this paper).
However, the number of test servers MultipathTester uses is quite small. Therefore, we decided to check which is the closest server from the client perspective at the beginning of our benchmarks. This is done for both mobile and multipath tests. The latency measurement is performed using concurrent TCP connections, as shown in the figure below.
Once all TCP connections has been established, the client sends a small request to each of the server at the same time. It then waits for the reply of all servers and computes the response delays. Five requests are sent to each server, and the server having the best median response delay is selected for the tests. Notice that the client waits for responses of all the server before sending the next request. For instance, consider the case shown below.
Here, the client already received the response from the France server, while the response from Canada is in its way and the Japan server did not received the request yet. The client will send the next request to all servers once all responses have been received. This allows a fair comparison between all servers if a transient network perturbation occurs on a path common to all servers (e.g, between the client and the WiFi Access Point).
In addition to TCP pings, multipath tests also perform QUIC pings. There are two benefits from doing this. First, the client can check if QUIC can go through the network before launching other QUIC tests. Second, it allows finding out possible service differentiation between TCP and QUIC in the network.
Want to get the application? Simply click on the MultipathTester logo below!
Do you have comments, suggestions or feedbacks? Don’t hesitate to contact us by mail!