Members of the Tessares R&D team conducted a series of tests to compare the performance of two MPTCP deployments: SOCKS protocol and 0-RTT Converter (also called Transport Converter).  This blog post shares data coming from experiments performed with MPTCP-capable smartphones.

Background information

We presented in our blog post entitled “MPTCP deployment options” how the SOCKS protocol & the 0-RTT converter work. We also explained why using the SOCKS protocol increases the latency of all connections to a remote server.

The relevant KPI  that has been selected to measure this delay is The Time to first byte (TTFB). It is a metric used as an indication of the responsiveness of a server. TTFB measures the duration from the client making an HTTP request to the first byte of the page being received by the client’s browser.  When the TTFB is low, visitors spend less time waiting for the website to start loading, improving the Internet experience, a key issue for ISPs.

Test protocol setup

As only few servers can support MPTCP, this set up (figure 1) puts a SOCKS-like server proxy between smartphones and remote servers. This allows smartphones to transfer data using Multipath TCP  over mobile & WiFi networks to the proxy, which can then send the same data using TCP to the final destination servers.

Fig. 1- High level view of testbed

Here are the items involved in the experiments:

The SOCKS client & proxy that have been implemented are called ShadowSocks¹: a light SOCKSv5-like proxy adapted for both client and server sides².

Methodology

Numbers of RTTs before exchanging data between client & server

As shown in the following figures, the SOCKSv5 protocol has 3 more RTTs compared to the 0-RTT Converter that uses SYN payload to send information (IP address + port). This mechanism allows a reduction of one RTT. The other two extra RTTs result from the authentication steps required in SOCKSv5.

Fig. 2 – Simplified data flows

As shown in the previous figure, if you remove the authentication steps of the SOCKSv5 protocol, you get the same flow as the ShadowSocks proxy. By measuring the TTFB of ShadowSocks proxy, the team could calculate the TTFB of SOCKSv5 proxy by multiplying by 2.

Configuration for the measurements

The SOCKS-like proxy server is configured to trace packets. Using the packet timestamps, two sets of data were produced:

1. The time to establish the connection with the SOCKS Proxy, defined as:
   > tcp.SYN                                   → start
   < tcp.SYN+ACK                         → stop
2. The Time To First Byte (TTFB) from the server contacted by the SOCKS-like Proxy, defined as:
   > tcp.SYN                                   → start
   < tcp.SYN+ACK
   > tcp.ACK
   > ShadowSOCKS.Req (IP+Port)
   < tcp.ACK                                   → stop

TTFB value for SOCKSv5 derived from (2) above can be multiplied by 2 (for a total of 4 RTTs).

In the data flow number 3 in the figure 2, we can also safely state that the TTFB for 0-RTT Converter can be derived from (1).

This allows us to create a model to compare the TTFB performance of the 0-RTT Converter versus SOCKSv5 MPTCP Proxy, as shown in the next section.

Results & Analysis

Let’s have a look at the Cumulative Distribution Function (CDF) plot of data coming from more than 30k connections generated in the testbed described above.

The plot shows that TTFB performance from 0-RTT convert protocol is better than the SOCKSv5. The additional round-trips from the SOCKS protocol negatively impacted the delay.

Fig. 3: CDF for TTFB between Transport Converter and SOCKSv5 Proxy

Figure 4 below depicts the time to exchange SOCKSv5 commands between the client and SOCKS Proxy. It is interesting to note that the last 15% of the connections have RTTs higher than 50ms, thus delaying TTFB by a minimum of 150ms due to SOCKSv5 protocol.

For the last 5%, the minimum is 450ms! According to Google, the server response time should be less than 200ms³.

Fig. 4: CDF for TTFB between Transport Converter and SOCKSv5 Proxy

These test results have been used  by Apple in a paper as part of the discussions when considering the MPTCP deployment options for the ATSSS function in Release 16 from 3GPP⁴.

References: 

⁽¹⁾ – Software can be downloaded here
⁽²⁾ – Details of these experiments can be found here
⁽³⁾ – https://developers.google.com/speed/docs/insights/Server
⁽⁴⁾ – See paper from Apple on the 3GPP website