5G and the 0-RTT TCP Convert Protocol (RFC8803)

  • Analysis

By deploying hybrid access networks based on Multipath TCP (MPTCP), network operators can combine existing fixed and mobile networks to provide higher bandwidth services without having to dig trenches for fiber. Future 5G networks will provide enhanced Wi-Fi / cellular convergence with the Access Traffic Splitting, Steering and Switching (ATSSS) function. These two very different services have a key common characteristic: They both rely on two open-standards protocols: MPTCP and the 0-RTT TCP Convert Protocol. Tessares’ founders played a key role in the design and implementation of MPTCP. The design of the 0-RTT TCP Convert Protocol was driven by Tessares and Orange. This blog post will focus on implications for 5G networks, now that 3GPP has finalized Release 16 (which includes ATSSS) in June 2020 and the IETF has published RFC8803 on 0-RTT TCP Convert Protocol in July 2020.

Fig. 1 – RFC8803 0-RTT TCP Convert Protocol abstract

True convergence with low latency

One of the main improvements in 5G over previous generations is the reduction in latency. 5G bonding experiments have been conducted where mobile clients move between ubiquitous 4G, low latency 5G and Wi-Fi networks. MPTCP and its proxy mechanism ATSSS (Access Traffic Steering, Switching, and Splitting) enable true network convergence without adding latency.

What does the Transport Converter do?

At a very high level, the Transport Converter allows the use of TCP extensions that are not supported by the server. In this example MPTCP packets flowing over 4G/5G and Wi-Fi networks are converted into regular TCP packets allowing higher speeds and persistent connectivity without relying on MPTCP support outside the operator’s network. For example, a mobile phone can use MPTCP to connect to Netflix or Facebook even though neither server supports MPTCP.

Fig. 2 –  The Transport Converter allows for the translation between MPTCP and TCP connections, providing the benefit of hybrid access without expecting the web to adopt new protocols

How does the Transport Converter work?

A mobile client has two interfaces: a primary, Wi-Fi interface  (@C1)  and a secondary cellular (4G/5G) interface (@C2). The converter client on the Mobile Client embeds the server’s IP address (@S) and application port inside the payload of the SYN packet. The SYN packet is the first packet of the three-way handshake which opens the primary connection (in this case Wi-Fi). The Transport Converter immediately initiates a connection towards the Server without experiencing extra delay, which is key for 5G networks.. The Transport Converter waits until the receipt of the confirmation that the Server agrees to establish the connection before confirming it to the Client. A secondary connection is made over 5G which also  targets the Transport Converter but all traffic on the Internet side appears to come from the primary connection.

Fig. 3 – Simplified network flow diagram showing the establishment of primary and secondary connections to a server via the Transport Converter

The Transport Converter maintains a relationship between connections on both sides: The upstream connection(s) between the Client and the Transport Converter and the downstream one between the Transport Converter and the Server. Any user data received by the Transport Converter over the upstream connection(s) is proxied over the downstream connection and vice-versa.

With 0-RTT Transport Converter, the client targets the Converter but the SYN packet encodes the final destination (Server) IP address and port number. Notice that the MPTCP option, MP_CAPABLE is also removed before passing the packet on to the Server. We can use MPTCP and 0-RTT Transport Converter TCP options without relying on the adoption of those options by servers outside of our control.

Full PDF version of RFC8803 is available here.

  • Share