Skip to main content

Minutes IETF102: mptcp
minutes-102-mptcp-00

Meeting Minutes Multipath TCP (mptcp) WG
Date and time 2018-07-16 19:50
Title Minutes IETF102: mptcp
State Active
Other versions plain text
Last updated 2018-07-25

minutes-102-mptcp-00
Multipath TCP (MPTCP)
Meeting  : IETF102, Monday July 16, 2018, 15:50 - 17:50 (Afternoon session II)
Location : Saint-Paul/Sainte-Catherine
Chairs   : Philip Eardley
           Yoshifumi Nishida
           AD       : Mirja Kühlewind
           URL      : http://tools.ietf.org/wg/mptcp/
           Note Taker: Christoph Paasch, Xavier De Foy

--------------------------------------------------------------------------

1: WG Status - Chairs

   Yoshi:
      Any implementation news?

   Christoph:
      at Linux netdev conference, we presented MPTCP to the Linux networking
      community. Feedback was positive. Linux TCP maintainer is encouraging us
      to move forward.

   Phil:
      Thanks Christoph and colleagues at Intel.

   Steven Fuerst:
      The F5 Big IP supports MPTCP on the client side.

   Yoshi:
      Any proxy work?

   Steven:
      By default, Big IP is a MPTCP proxy on the server side, not on the client
      side. We do MPTCP on the client-facing side. Regular TCP to the backend
      servers.

--------------------------------------------------------------------------

2: 6842bis update - Christoph Paasch

   Christoph:
      Latest update corresponds to the version 10 to 11 update.
      We removed experimental and moved TCP fast open to appendix (since TFO is
      experimental RFC only). WGLC is ongoing.  Added echo flag + echo flag to
      ADD_ADR for reliability. A question remains: can an attacker use the echo
      flag (since it is not protected by HMAC)

   Yoshi (from floor):
      an attacker would also need to steal some keys, so it should not be a
      problem.

   Christoph:
      agree, it should not be a problem.

   Christoph: another change:
      ID was removed from MP_PRIO in v9 because of a possible attack.  Now
      Backup is indicated in the ADD_ADDR.

   Yoshi (from floor):
      agree with this suggestion.

   Phil:
      do you have the authorization to release the code.

   Christoph:
      will work on this this week, and will let you know.

   Xavier de Foy:
      what will happen to the experimental option?

   Christoph:
      need to check with Olivier, who removed it.

   Phil:
      only both chairs have agreed to review the document, are there any
      volunteers for more?

   Xavier and Rahul Jadhav will review the document and provide some comments

--------------------------------------------------------------------------

3: Considerations for MPTCP operation in 5G - Xavier de Foy

   Phil:
      Do you see any implications for MPTCP protocol? Does local MPTCP stack
      can handle by itself?

   Xavier:
      there may be a need to send session continuity type, for SSC mode 3
      server side MPTCP may need to use it for a graceful transition from first
      to second path.

   Phil: put a summary in the mailing list, what and why specific modifications
   are required for MPTCP?
      This could be part of the review of the bis draft.

   Mirja Kühlewind:
      Is it an interface issue or an implementation issue? Is it a local
      decision? Otherwise, how network will send information to client?

   Xavier:
      it may be local but there may be a need to transmit the session
      continuity type over MPTCP signaling.

   Yoshi:
      let's put this in an email and we can discuss it further.

   Chunshan Xiong:
      The way 3GPP is defining SSC mode works on IP layer. Why MPTCP is
      required? Should you propose it to IP related WG? This is a general issue
      and may be applied to all protocol. Referring back to 3GPP, Release 16,
      proposed lots of solutions for traffic steering over different RAT. For
      Dual Connectivity, L2 technology is proposed/being worked in 3gpp. Do we
      need MPTCP?

   Christoph:
      Dual connectivity is complicated in downstream. Upstream is possible.

   Xavier:
      Kien (co-author) will likely address this issue in future updates.

   (Post-meeting note: this feature is probably not supported today and would
   need to be introduced in 3GPP, some form of traffic filtering possibly).

   Yoshi (from floor):
      SSC mode is determined in 5g network. Can application chose SSC mode?
      Clarification required about how this is chosen and propagated?

   (Post-meeting note: this will need to be clarified in draft).

--------------------------------------------------------------------------

4: Potential work items discussion

   Yoshi:
      any opinions on future topics?

   Zhen Cao:
      Is there any timeline?

   Yoshi:
      not at this moment, but, we might skip a few meetings until some topics
      are proposed.

   Zhen Cao:
      will the list of topics become charter items?

   Phil: we need a community of interest, not one person, this is the selection
   criteria.

   Zhen:
      do we need draft to accompany this list?

   Phil:
      no, you just need to express a need/interest on the mailing list.

   Mirja:
      we may also just close the working group - there is no need to
      re-charter. Maintenance work would go to TCPM.

   Christoph:
      people are busy deploying, this is why activity has come down.
      Also the level of activity in the meeting is location dependent (more
      active in Europe for example). We should wait a bit and see where it goes.

   Yoshi:
      what about APIs?

   Christoph:
      the IETF not the place for API standardization. How to expose MPTCP to
      user space.

   Mirja:
      you should still work on MPTCP, there will be a place in the IETF, for
      example in TCPM.