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.