Multipath TCP (MPTCP) Meeting : IETF90, Monday July 21, 2014, 13:00-15:00 Location : Toronto, Tudor Chairs : Philip Eardley Yoshifumi Nishida AD : Martin Stiemerling URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Alan Ford --------------------------------------------------------------------------- 1: Chair Slide Request to IESG for new threats publishing. We'll need operational experience before 6824bis can be published as PS. It would be good to have proxy discussions because middlebox implication is in the charter. A new WG tcpinc was formed and tcpcrypt will be discussed there. Note - 3rd party IPR declaration on MPTCP proxy Phil: Any news for implementaion? Shoaib Rao: Oracle MPTCP Solaris implementation has started. We have some issues which are not discussed in RFCs. We might want to discuss some folks who has some experiences in linux or freebsd. --------------------------------------------------------------------------- 2: Experience with Multipath TCP - Olivier Bonaventure (Olivier explained handover) Dino Farinacci: what if one connection doesn't work over wifi, how can the reverse path work? Olivier: if you have two subflows: one is wifi and the other is 3G, it is not possible to have asymmetric paths because subflows operate independently. Dino Farinacci: have you ever do some experiments on moving the IP address to a new interface? Olivier answer: We haven't done yet. But, I know some people in Paris have been looking at combining mptcp with LISP. Olivier: in implementations only client creates subflows. Full mesh mode or use different ports (eg data centre). Question whether 6824bis should say MUST use same port (makes simpler for server) (Olivier explained MPTCP schedulers framework in linux, eg lower RTT or round robin) Alan Ford: what level of granularity is this scheduling undertaken? Olivier: per segment Alan Ford: so this means that the earlier identified issue around REMOVE_ADDR being lost is either a big deal (if the lost path is considered to be lowest RTT) or not a deal at all (if it had worst RTT). (Olivier explained interactions with DNS) Martin Stiemerling: big overlap with mif regard to CDNs. Looking at DNS on multiple interfaces. Olivier: in summary, RFC6824 protocol is solid. Performance gain through packet scheduling and path management. Should IETF specify path management policies? Alan Ford: API stuff already specified in RFC6897 and the appendix lists the ability to control scheduling. Olivier: yes. although nobody has implemented RFC6897. Alan: that's true, but the concepts are there and we should await implementations actually needing to do this rather than the IETF looking at it right now. Jim Roskin: Please explain why 3g/wifi handover graph is not a sum but less. Olivier: Retransmissions occur on both subflows at times when packets are lost. Jana Iyengar: very similar to SCTP multihoming discussions. When retransmission keep happening, there's no reason to keep retransmit to old path. Olivier: yes. Will check what is done in SCTP. Yuchung Cheng: Question on CDNS and MPTCP slide. how do you cope with performance loss when you have 3G server is not closer than wifi CDN server? Olivier: You'll need to choose between keeping MPTCP connection up and connecting closest server. You don't move MPTCP connections from one server to another. MPTCP logic is to keep connection open, even if it's not the closest one now you've moved network. HTTP could handle this at the application level, for example. Yuchung Cheng: It might be interesting if you explore this kind of situation. Jana Iyengar: reminiscent of RSPOL (reliable server polling), migrating transport services state across servers. Was looked at before, but is very hard. Applications know much better whether move contexts or not. Michael Tuexen: get API developers involved. TAPS is not very relevant here, however TAPS will give the application writer an api; mptcp complexity this would be hidden by TAPS so this would need a new API. --------------------------------------------------------------------------- 3: Use-cases and Requirements for MPTCP Proxy in ISP Networks - Lingli Deng Chair: (show of hands) about 6 people have read draft. Please send comments --------------------------------------------------------------------------- 4: MPTCP proxy mechanisms - Xinpeng Wei --------------------------------------------------------------------------- 5: Some thoughts on MPTCP proxies and middleboxes - Ed Lopez Proxy near the edge is most likely. Sri Gundavelli from Cisco: Are you planning on writing a document? Please bring in wifi-3G issues. Ed: yes! I'm actively working on it. Keith Moore: would be really useful to have a mechanism of informing the end users what's happened and why. Jana Iyengar: we need to think about what kind of info will be exposed and will not be exposed. if it's exposed, expect that they can do anything with it. Many middleboxes assume 'single session bias'; so mptcp impacts. --------------------------------------------------------------------------- 6: Processing of RST segments by Multipath TCP - Olivier Bonaventure Proposing to add info on why server(especially) has stopped a subflow. Ed Lopez: I agree with the idea. But, not sure we need to go down to this level of granularity. Olivier: We can reduce the number of reasons Karen Nielsen: will the reconnected subflow reset CC parameters, or does it inherit old CC parameters? Olivier: I don't know what to do with host cache yet. We should do some measurements to understand the issues. --------------------------------------------------------------------------- 7: TFO support for Multipath TCP - Olivier Bonaventure --------------------------------------------------------------------------- 8: New MPTCP congestion control algorithm - Anwar Walid Hoping to include in Louvain implementation - waiting for internal approval.