This is the second post of a series describing our test methodologies. In this article, we explain what is behind our stream traffic and share some surprising results with Multipath TCP with dual-stacked WiFi networks.
The smartphone traffic is a non-negligeable and still growing part of the Internet traffic. As stated by the Cisco Mobile Forecast, the mobile data traffic will grow 7-fold from 2016 to 2021. Such traffic often has to deal with latency requirements coming from the application. An example is a user streaming a video. If the frames does not arrive quickly enough to the client, the user will observe a stall in the video. Another example is voice-activated applications. For example, with Siri, a user can talk to its device which sends voice samples to the server that processes them to provide a reply to the user request. The more the network latency, the more the Siri latency observed by the user.
To evaluate the impact of such traffic on transport protocols, we designed a bidirectional constant bit rate traffic. Both the download and upload cases are evaluated during the test, as depicted on the figure below.
Every 100 ms, each host sends data block of 2 KB, leading to a bit rate of 20 KB/s in each direction for each protocol. Then the data sender can compute the delay between the sending of data and the reception of the applicative acknowledgement relative to data. Notice the difference between (MP)TCP and (MP)QUIC. As there are two data streams in this traffic, two (MP)TCP connections have to be created. In comparison, only one is needed with (MP)QUIC as it has built-in support for multiple streams inside a single connection.
This traffic is used in both multipath and mobile tests. In multipath tests, the performance of MPTCP and MPQUIC are similar. This is expected, as those runs are quite short (7 seconds), the (WiFi) network remains usable and the scheduling strategies of both protocols are the same, i.e, prefer WiFi over cellular. However, we observe quite different results with mobile tests. The figure below shows the maximum delay experienced by the server with the download data stream between its data sending and its applicative acknowledgement reception.
We observe significantly maximum delays with MPQUIC than MPTCP. There are three factors that can explain those results. The first one is the connection sharing of MPQUIC. When the client detects connectivity loss on the upload stream due to a fading WiFi network, it can warn the server about this through the PATHS frame. The server can then decide to retransmit the data over the cellular. In comparison, there are two independent MPTCP connections that do not exchange such connectivity information. The second factor comes from the MPQUIC server that seems to avoid using the WiFi path once it was detected as lossy, while MPTCP tries to reuse the WiFi path once it becomes usable again.
The third factor comes from a combination of the happy-eyeball effect and a lack of full MPTCP specifications support in iOS. An iPhone could have only one path (i.e., one usable address) per interface. When the network is dual-stacked, as our server is dual-stacked too, the source address of the initial path (i.e., the WiFi path) is selected through a classical happy eyeball process. However, in Belgium, it is frequent to have dual-stacked WiFi networks and IPv4-only cellular ones. It sometimes happen that the IPv6 network provides faster connectivity than the IPv4 one. In such cases, the client starts the connection on the IPv6 address of the server. The RFC6824 describes the ADD_ADDRESS MPTCP option that enables hosts to exchange their additional addresses. However, iOS does not implement this feature, probably due to privacy concerns related to sending in clear-text addresses of an host. This prevents the server from communicating its IPv4 address to the client, and therefore the client cannot use the cellular network to perform smooth network handover. The connection could continue only if the device finds another IPv6-capable WiFi network. Notice that this issue does not happen if our server were IPv4-only and the client were using an IPv6-only cellular network. In such cases, NAT64 comes into action.
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!