Welcome to this last issue of Multipath News of the year !
This edition of the Multipath news focuses on the recent discussions within the IETF. Later issues will summarise the evolution of the Multipath TCP implementation in the Linux kernel and the scientific papers.

The multipathtcp mailing list has been relatively quiet since the publication of the previous issue of our Multipath News.

A new version of RFC6824bis has been published. This update fixes the security issue that was identified in A. Munir et al, Multipath TCP Traffic Diversion Attacks and Countermeasures, ICNP 2017. The main modification in RFC6824bis is that the the MP_PRIO option does not contain anymore an address identifier.

Another point that was discussed is the utilisation of the FAST_CLOSE option to quickly terminate a Multipath TCP connection. This option is defined in section 3.5 of RFC6824bis. When a host wants to quickly terminate a Multipath TCP connection, it should send a TCP RST on all subflows except one. On this subflow, it must send an ACK containing the FAST_CLOSE option. When a host receives such a ACK with a FAST_CLOSE option, it must reply by terminating all subflows with a RST. The Multipath TCP connection is then considered as being closed upon reception of a this RST. Unfortunately, deployment experience has shown that when losses occur, this procedure does not always works well and forces the host that wants to quickly terminate a connection to continue to maintain state for this connection while waiting for the RST that confirms the delivery of the FAST_CLOSE option. This happens at a time where the Multipath TCP stack could already be under memory pressure and needs to quickly remove existing connections.

A first approach to solve this problem was proposed by Francois Finfe. This was discussed on the mailing list and a new text for section 3.5 of RFC6824bis was proposed later.

Another discussion item on the list has been the support for Multipath TCP proxies. This is one of the points of the charter of the Multipath TCP working group. Since IETF99, the working group discussions have been focussed on draft-bonaventure-mptcp-converters . The IETF Area Director has asked to move the discussion to the TCPM working group to see whether the solution proposed in draft-bonaventure-mptcp-converters could become a generic TCP solution and not be target at Multipath TCP. This discussion has only started.

The Multipath TCP working group met during IETF100 in Singapore. The chairs’ presentation started with a summary of the status of RFC6842bis. The remaining items before a working group last call were :

• Guideline about MPTCP and TFO interactions,
• Fast Close Updates,
• Reason codes for MPTCP reset.

The first point has been address with the publication of the revised version of draft-barre-mptcp-tfo-02. The second point has been discussed above. The third point remains open for discussion

Besides this, there were three technical presentations. In Considerations for MPTCP operations in 5G, D. Purkayastha explained some of the ongoing discussions while 5G is being defined. One of the issues that was discussed is the fact that a 5G device could have different IP addresses attached to the same interface. A multipath transport such as Multipath TCP should not blindingly use all available IP addresses to create subflows. During the discussion, several attendees pointed out that there are other situations were a single host may receive multiple IP addresses on a single interface.

In A proactive approach to avoid performance degradations in MPTCP Jing Zuo reported the results of several experiments conducted with MPTCP-enabled Android smartphones on high speed trains. This was the first experiment that used Multipath TCP with the BBR congestion control scheme. The experiments focused on bandwidth aggregation and Stuart Cheshire pointed out that bandwidth is not the only benefit that endusers can obtain with Multipath TCP. Multipath TCP brings increased reliability and lower delay, which can be more important than higher bandwidth for many applications.

Finally, Vlad Olteanu presented in SOCKS Protocol version 6 the recent updates to their SOCKSv6 proposal. The main improvement in this document is the utilisation of TLS 1.3 to replace the older SOCKS encryption scheme.