Multipath TCP (MPTCP) Meeting : IETF101, Thursday March 22, 2018, 13:30 - 15:30 (Afternoon session I) Location : Viscount Chairs : Philip Eardley Yoshifumi Nishida AD : Mirja Kühlewind URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Christoph Paasch -------------------------------------------------------------------------- 1: WG Updates - Chairs Phil: Discussion of RFC6824bis status Proxy work item: tcpm working group has added a working group item on TCP converter. Encourage participants of MPTCP working group to get involved in tcpm and participate to that work Enhanced API document: no working group document for this item at this stage, we'll need to discuss at one point -------------------------------------------------------------------------- 2: Implementation Updates - Christoph Paasch Christoph: New stable release on Linux 4.14 LTS. No major feature, mainly upstreaming, 72 changes from 6 developers at 5 different companies. Bigger effort of upstreaming with Tessares, Intel, Oracle and some others and new MPTCP upstream discussion list We will probably have to remove some features from the 0.94 implementation to go upstream. It seems acceptable trade-off as they could be pushed back later on once MPTCP has been accepted in the mainline Linux kernel. Hackathon in Louvain-la-Neuve with open-source iOS applications. See slides for additional information: - Radio app - Web browser: search suggestion - Multipathtester - Issues: when apps use lower/higher level net lib Yoshi: is there a gap between 0.94 and RFC6824bis? Christoph: 0.94 is still RFC6824, the code for the bis implementation has not yet been released. I'll check how to release the 6824bis implementation. -------------------------------------------------------------------------- 3: 6842bis update - Alan Ford Alan: Updates to MP_FASTCLOSE with RST. Tussle between being able to correctly close a Multipath TCP connection and allow a server to get rid immediately of a Multipath TCP connection. Adds an option to RST to solve this problem TCP Fast Open: based on earlier draft from Gregory Detal and Sebastien Barre. How to interact with MPTCP option space and when is it appropriate to use it ? TFO is used on first subflow only. Enough space in SYN, a bit more difficult in SYN+ACK. Exclude TFO data from DSS to cope with middlebox interference that could modify data in SYN. DSS starts after the data in the SYN. Mirja: TFO only works for the first subflow, not for the additional ones? Alan: Correct. No options space on later subflows and no clear delay benefits. Mirja: What happens if you loose the data and have to retransmit? Alan: Not worse than regular TCP Christoph: If the TFO data does not get acknowledge, it will be sent as regular MPTCP data after the handshake has finished Mirja: Not exactly like TCP. Christoph: TCP sequence number will be the same, but we add DSS to the retransmission Mirja: If you add information to the packet and it was already too long, it does not work anymore. I have to look at the details. Are you convinced that there is no problem? Christoph: Yes Alan: We might need to rework a bit the text to make it clearer. Yoshi: Fast Open is optional, not mandatory to implement? Alan: Agreed. This is to say if you implement TFO+MPTCP, these things you should consider. Yoshi: We push this draft as a proposed standard. When I read the draft, it was not clear that this part was optional. Make sure that we are explicit for the parts that are not mandatory to implement Uma Chunduri (?) from Huawei: in section 2.7, which threats of RFC6181 have been addressed? Alan: Pretty much all of RFC6181 have been addressed with the HMAC, objective is to be no worse than TCP. If you're on path, even normal TCP can be attacked but adding subflows should not make things worse. Uma: Might expand the section Phil: Moving to a slot for discussing whether this could be WGLC now. We made some changes to RFC6824, version number has been bumped and this will obsolete RFC6824. Olivier: One comment about RFC6824bis about the experimental MPTCP options. Quentin Deconinck tried to implement it and there are still some issues. Suggestion: Remove it from the core text and rather write an RFC outside of the main document that specifies the experimental MPTCP options. Alan: Yes, we could do this. And just say in the bis that there may be other options sent under this version-number. Phil: After the update of the document we'll be able to issue a last call. -------------------------------------------------------------------------- 4: A socket API to control Multipath TCP - Fabien Duchene Fabien: Quick update on the socket API. Added support for IPv6 Segment Routing. Can add SRv6 option to a subflow to steer traffic. - Using disjoint paths - Traffic engineered path Uma from Huawei: How do you get the network path to the host? Fabien: we have a paper that describes a possible approach Uma: how does the endhost now the path ? Fabien: could be an SDH controller Uma: If you expose the network paths, there could attacks. Sri: Trying to understand the motivation for this. If I bind to a Wifi address, that's a path, in which situations would you use that ? Fabien: There are use cases where you want to have disjoint paths, this could be a way to obtain those paths that are really disjoint. Gives more insight to transport layer. Sri: Endpoints doing that, not completely believe the picture. What are your thoughts on the interaction with the MPTCP converter? Fabien: Still need to think about the interactions. Olivier: Just one comment: There was a presentation by Daniel Bernier at PANRG. He wanted to use IPv6 SR in his core-networking and expose the paths to the end-hosts. I will send that paper to the list. -------------------------------------------------------------------------- 5: Extended Socket APIs to control subflow priority in Multipath TCP - Samar Shailendra Samar: Based on experiments with drones with RobotOS. Wanted to have control at the application layer through the socket Expanded on draft-hesmans-socket-api Control subflow priority Phil: What is the status of your system ? Samar: still a prototype, commercial drones do not expose their kernel Yoshi (from floor): If we reconnect, can we get the same subflow? Samar: we use a list with addresses and all subflows with the same address get the same priority. Yoshi: What about port number? Samar: We only check addresses. -------------------------------------------------------------------------- 6: Considerations for MPTCP operation in 5G - Xavier de Foy Xavier: This is for release 15, deployment in 2020. Yoshi: Are you doing experiments? Xavier: Not so far. Alan: Are you planning to do that? Xavier: This is possible. Sri: Trying to understand the proposal. 5G has different types of addresses, you want this to be exposed to MPTCP? Xavier: 5G stack will behave in ways that are different than 4G. The assumptions in MPTCP will be wrong. 5G handles mobility in a different way. 5G is more distributed and could be leveraged to have better performance Idea is to provide information about the type of address. These modes will have one-to-one mapping to IETF specs, this should address some of your concerns. How do we expose that to the socket layer? IETF has a spec in last call in dmm working group, maybe it covers some of your concerns Xavier: Will check DMM drafts Uma: 3GPP sent a liaison statement to DMM working group. Maybe something need to be done in MPTCP for that Phil (from floor): In DMM, would you be able to use MPTCP? Is there a change needed in DMM? Sri: If you already expose the modes to the socket layer, the application already has visibility on the properties. Are you willing to define additional logic in MPTCP? Xavier: Based on the DMM work, MPTCP could get in which mode a given address is attached done. Maybe there is some mapping to be done between the applications and the interfaces Sir: Will think about it Phil: Need to make sure that MPTCP can use the DMM information Are the changes needed for MPTCP? Did you find any? Xavier: I think that what we have found mainly impacts scheduler and path management and probably not the protocol itself Phil: During WGLC, make comments if anything needed. -------------------------------------------------------------------------- 7: First Experimentations with iOS Multipath TCP - Quentin De Coninck Quentin: MultipathTester performs bandwidth measurements and mobility measurements to measure the performance of handovers Compare Multipath TCP with QUIC and Multipath QUIC to see which protocol performs better 200 tests already collected from 50 different devices Application is available from https://www.multipath-quic.org and available on Apple's store as MultipathTester Yoshi (from the floor): very interesting. What is the difference between MPTCP scheduler and MultipathQUIC's Quentin: At server side, we use low latency scheduler, on scheduler same but we prefer WiFi over cellular on MPTC Yoshi: Lowest rtt is not always the best? Is it what you are trying to say? Quentin: Linux has potentially failed paths, there might be something similar in iOS. This is a work to improve the scheduling and path management Zhen Cao: Why iOS MPTCP is different from Multipath QUIC Quentin: Sometimes my QUIC implementation sends over cellular when it should not and there were some issues with Multipath QUIC that are being fixed Zhen: If MPQUIC sends the request but does not go through the network, you should not consider this delay as infinite. If you have a threshold for handover, you should send request and maximum delay should be the same. We'll see when we have more data -------------------------------------------------------------------------- 8: One Way Latency Considerations for MPTCP - H Anthony Chan A Path-aware Scheduling Scheme for Multipath Transport Protocols, Jing Zuo Jing: Scheduling taking into account one-way latency and using redundant transmissions from time to time to obtain data from all the paths, e.g. during one second packets are scheduled according to the one-way latency Proposed Multipath one way latency option Phil: Have you built this? Jin: Part has been done Yoshi (from floor): If path is completely disjoint, redundant makes sense, but if the paths merge, then you overload this shared part of the path affecting one way delay measurements? Jin: redundant is only run for a period of time. Mirja: When not only TCP timestamp option? Jin: It carries two timestamps, we do not want to change the meaning of these options. If you think it can be used, we can use that Mirja: What would you need to change? Jin: delayed ack might be an issue Mirja: Don't think one-way delay is a specific function for MPTCP. If you want a different option, it should be a TCP option Mark: What do you do in the redundant phase? Is congestion control applied in the two transmissions? if a path has low cwnd and the other large, how do you cope? Jin: don't consider CC at this stage. Mark: unclear how your proposal would work. Jin: uncoupled congestion control Mark: If you send in this redundant mode, the other path may become very slow, do you stop then? Jin: We could set a threshold for that -------------------------------------------------------------------------- 9: SOCKS Protocol Version 6 - Vladimir Olteanu Vlad: Uses TLS and includes new socket options. Clients can place them in SOCKS requests and servers in replies, includes bypass feature like draft-ietf-tcpm-converters Yoshi: about the bypass. When the client identifies the support of MPTCP on the server. Application has the responsibility to use this information? Vlad: in implementation, application is probably a proxyfier that can take care of that