Internet DRAFT - draft-defoy-mptcp-considerations-for-5g

draft-defoy-mptcp-considerations-for-5g







Network Working Group                                          X. de Foy
Internet-Draft                                                 M. Perras
Intended status: Informational               InterDigital Communications
Expires: December 24, 2018                                   U. Chunduri
                                                              Huawei USA
                                                               K. Nguyen
                                                               M. Kibria
                                                               K. Ishizu
                                                               F. Kojima
                                                                    NICT
                                                           June 22, 2018


                Considerations for MPTCP operation in 5G
               draft-defoy-mptcp-considerations-for-5g-01

Abstract

   This document describes scenarios where the behavior of the 5G
   mobility management framework is different from earlier cellular
   generations, and describes how it may benefit from some form of
   adaptation of MPTCP implementations and protocol aspects in the 5G
   system.  This document also describes how MPTCP may be leveraged in
   5G system specifications.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 24, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





de Foy, et al.          Expires December 24, 2018               [Page 1]

Internet-Draft                 MPTCP IN 5G                     June 2018


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Need for Adapting MPTCP to 5G Session and Service
           Continuity  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Opportunity for Leveraging MPTCP in 5G Dual Connectivity
           Feature . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Impact of 5G Session and Service Continuity on MPTCP  . . . .   3
     2.1.  New Inputs for MPTCP stacks . . . . . . . . . . . . . . .   4
     2.2.  SSC mode 1  . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  SSC mode 2  . . . . . . . . . . . . . . . . . . . . . . .   6
     2.4.  SSC mode 3  . . . . . . . . . . . . . . . . . . . . . . .   7
     2.5.  Behavior of Remote Peer . . . . . . . . . . . . . . . . .   9
   3.  MPTCP with 5G Dual Connectivity . . . . . . . . . . . . . . .  10
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   MPTCP [RFC6824] is being deployed and widely adopted in today's smart
   devices, which typically have multiple network interfaces such as
   Cellular and Wifi.  It provides reliability, bandwidth aggregation
   capability, and handover efficiency.

   This document describes scenarios where the behavior of the 5G
   mobility management framework is different from earlier cellular
   generations, and describes how it may benefit from some form of
   adaptation of MPTCP implementations and protocol aspects in the 5G
   system (see Section 1.1).  This document also describes how MPTCP may
   be leveraged in 5G system specifications (see Section 1.2).








de Foy, et al.          Expires December 24, 2018               [Page 2]

Internet-Draft                 MPTCP IN 5G                     June 2018


1.1.  Need for Adapting MPTCP to 5G Session and Service Continuity

   With regards to 5G session and service continuity mechanisms, MPTCP
   stack behavior (including path manager and scheduling) should be
   updated to achieve optimal performance:

   o  Proposed 5G MPTCP behavior is described in Section 2.2,
      Section 2.3 and Section 2.4.

   o  To enable this behavior, MPTCP will need additional information
      about local IP addresses: (1) its session continuity service type
      and (2) a notification that a new IP address has been provided for
      service continuity.  This is described in Section 2.1.

   o  Remote MPTCP peers may need access to the IP address SCS type
      (through MPTCP signaling or otherwise).  This is discussed in
      Section 2.5.

1.2.  Opportunity for Leveraging MPTCP in 5G Dual Connectivity Feature

   With regards to dual connectivity, MPTCP can be closely integrated
   with the 5G stack to avoid duplicating its feature in 5G, as
   discussed in Section 3.  As a summary:

   o  MPTCP should be aware of the presence of multiple DC radio links,
      which may be exposed as a single or distinct network interfaces/IP
      addresses.

   o  MPTCP should optimally partition traffic or duplicate a data flow
      over DC links, depending on the application's need, network policy
      and conditions.

2.  Impact of 5G Session and Service Continuity on MPTCP

   One of the goals of 5G systems, as outlined in [_3GPP.23.501], is to
   enable low latency services and access to local data networks where
   mobility anchors can be deployed close to devices, thereby satisfying
   use cases with stringent transmission delay and high reliability.
   Mobility in 4G networks, as described at the architecture level in
   [_3GPP.23.401], was based on a central mobility solution that made it
   difficult to relocate mobility anchors closer to the end user.  In
   contrast, 5G uses a distributed mobility solution based on multiple
   anchors providing different IP addresses as the device moves from one
   area to another.

   The base scenario in this section is: a 5G device connected to a
   single-homed server is in an area with no usable Wifi coverage.  An
   application using MPTCP sends traffic over a single subflow, over the



de Foy, et al.          Expires December 24, 2018               [Page 3]

Internet-Draft                 MPTCP IN 5G                     June 2018


   cellular air interface.  Then, as the device moves, the 5G device
   reacts to mobility events.  Additionally, we briefly discuss cases
   where the device switches from a Wifi to a cellular backup
   connection, and other cases where both MPTCP peers are 5G mobile
   devices.

   In 5G, every unit of a network connectivity service (PDU session) has
   a type which can be IP (IPv4 or IPv6), Ethernet or unstructured.
   While session continuity is supported for all types, we will focus on
   PDU sessions of IP type primarily.  Different PDU sessions will
   typically correspond to distinct network interfaces on the device
   (though this is not explicit in the standard, and some
   implementations may possibly behave differently).

   In 4G networks, session continuity is enabled by anchoring a PDN
   Connection (as PDU Sessions are referred to in 4G networks) to a P-GW
   which allocates an IP address to the mobile device: PDN connection
   and IP address allocation are maintained as long as the device
   remains attached to the network, even when the device moves around.
   In 5G, different types of session continuity can be provided, and are
   indicated by a "Session and Service Continuity" (SSC) mode value of
   1, 2 or 3 (defined in [_3GPP.23.501] section 5.6.9).  Every PDU
   session is associated with a single SSC mode, which cannot be changed
   on this PDU session.  The following sub-sections will study how 5G
   handles each SSC mode, and potential effects on MPTCP.

2.1.  New Inputs for MPTCP stacks

   IP Address Session Continuity Service Type

      The "session continuity service type" (SCS type) of an IP address
      allocated by the network can be used as input by MPTCP
      implementations.  It has been defined for on-demand mobility
      management [I-D.ietf-dmm-ondemand-mobility], as:

         FIXED IP address: valid for a very long time, for session
         continuity and IP address reachability.

         SESSION_LASTING IP address: valid for the lifetime of an IP
         session, even if the mobility host moves.

         NON_PERSISTENT IP address: which does not provide session
         continuity nor IP address reachability.

         GRACEFUL_REPLACEMENT IP address: similar to a non-persistent
         address, but adding a limited graceful period for the
         transition from one address to another.




de Foy, et al.          Expires December 24, 2018               [Page 4]

Internet-Draft                 MPTCP IN 5G                     June 2018


      This information needs to be conveyed to the device by the network
      that allocates the address: for example, as described in
      [I-D.feng-dmm-ra-prefixtype], the SCS type of IP address may be
      conveyed through router advertisements.  The MPTCP stack may
      obtain the SCS type of a local IP address using a programmatic
      API.  This information does not directly tell which SSC mode the
      application is using, nevertheless it is sufficient for MPTCP to
      appropriately and non-ambiguously decide how to handle new IP
      addresses in the context of SSC in 5G.

   Notification of a New IP Address from Session Continuity

      As in non-5G cases, MPTCP starts handling the initial socket
      created by the application.  The initial connection attempt
      triggers the creation of the first PDU session (or the reuse of an
      existing one), associated with a network interface and an IP
      address on this interface.  Later on, the network decides to use a
      new anchor, e.g., when a mobility event occurs or when a Local
      Data Network becomes available.  The network then triggers the
      modification of the existing PDU session, or creation of a new PDU
      session, and ultimately a new IP address is provided to the 5G
      device, respectively on the same or a new network interface.

      The 5G stack on the device is aware of the relationship between
      the old and new IP addresses, and can therefore notify the MPTCP
      stack.  Such a notification may include both the old and new IP
      addresses , which ensures that the MPTCP stack has all necessary
      information (for example, the MPTCP stack may then obtain the SCS
      type of the new IP address, and the validity lifetime associated
      with the old IP address, if it is still up).

2.2.  SSC mode 1

   In SSC mode 1 the same network anchor is kept regardless of device
   location.  An application running on the device will therefore be
   able to keep using the same IP address on the same interface.

   Additionally, in SSC mode 1, the network may decide to add and
   remove, dynamically, additional network anchors (and therefore IP
   addresses) to the PDU session, while always keeping the initial one.

   PROPOSED MPTCP BEHAVIOR SPECIFICATION:

   These steps are applicable when the initial IP address returned by
   the network stack is FIXED or SESSION_LASTING.

      MPTCP should not close all subflows originated from this original
      IP address at any point during the session, since this IP address



de Foy, et al.          Expires December 24, 2018               [Page 5]

Internet-Draft                 MPTCP IN 5G                     June 2018


      is the only one that is guaranteed, under normal circumstances, to
      be maintained over time for this application.

      At any time during the session, a new IP address of SCS type
      NON_PERSISTENT may become available.  MPTCP may create new
      subflows for the application, using this IP address (this IP
      address is likely to provide shorter path subflows, but may
      disappear at any time).

2.3.  SSC mode 2

   SSC mode 2 has a break-before-make behavior.  When the device leaves
   the service area of its first network anchor, the network stops using
   it and starts using a new second network anchor closer to the device.
   (Such service areas may have a highly variable size depending on
   network deployments.)  On the device, this can result in the
   currently used network interface being brought down, and after a
   short time a new network interface being brought up.  The time
   between these 2 events is not standardized and implementation
   dependent.

   Break-before-make within cellular technology

      When MPTCP is active on cellular only, this break-before-make
      behavior is similar to the existing break-before-make capability
      usually used in cellular/Wifi offload (section 3.1.3 of [RFC6897]
      and section 2.2 of [RFC8041]).  A similar MPTCP behavior is
      therefore needed: wait for a given time for a new IP address to be
      configured.  As per [RFC6897], to benefit from this MPTCP
      resilience feature, the application should not request using a
      specific network interface.

   Cellular and Wifi

      Additionally, when Wifi is active and cellular is used as backup,
      MPTCP implementations should also support this break-before-make
      behavior to maintain a usable backup IP address on cellular.  In
      rare cases where a switch-to-cellular backup would be needed
      during a break-before-make transition on cellular, MPTCP's
      existing break-before-make capability can ensure MPTCP waits for a
      new cellular-facing IP address to be available.

   PROPOSED MPTCP BEHAVIOR SPECIFICATION:

   These steps are applicable when the initial IP address returned by
   the network stack is NON_PERSISTENT.





de Foy, et al.          Expires December 24, 2018               [Page 6]

Internet-Draft                 MPTCP IN 5G                     June 2018


      At any point in time, the current NON_PERSISTENT IP address may be
      taken down by the network stack.  The MPTCP stack should wait for
      another NON_PERSISTENT IP address to be made available by the
      network stack.  If such an address is made available within a
      given time limit, the MPTCP stack should create new subflows using
      this new address (effectively following the existing break-before-
      make behavior present in MPTCP).

      Additionally, if an initial backup IP address is a NON_PERSISTENT
      address, the MPTCP stack should consider any subsequent
      NON_PERSISTENT IP address as a backup IP address in replacement of
      the initial NON_PERSISTENT address.

2.4.  SSC mode 3

   SSC mode 3 has a make-before-break behavior.  When the device leaves
   the service area of its first network anchor, the network selects a
   second network anchor closer to the device, and either creates a new
   PDU session (i.e. new IP address on new network interface) or share
   the existing PDU session (i.e. new IP address on same network
   interface).  The first network anchor keeps being used for a given
   time period, which is communicated to the device by the network using
   the "valid lifetime" field of a prefix information option in a router
   advertisement ([RFC4861], [RFC4862]).  5G does not mandate a specific
   range for this valid lifetime.  The first/older IP address should not
   be used to create any new traffic ([RFC4862] section 5.5.4).  In some
   implementations, the network (SMF) may decide to release the first
   network anchor as soon as it stops carrying traffic.

   There is no limit set by the 5G standard for the number of
   concurrently used network anchors.  We expect that in usual cases the
   first network anchor will be released before a third network anchor
   starts being used.  Nevertheless, to our knowledge nothing prevents a
   5G system deployment to allow a third network anchor to be selected
   while the first one is still in use.

   On the 5G device, when using SSC mode 3, mobility will therefore
   result in a new IP address being configured, either on the same
   network interface initially used, or on a different interface.  In
   general, an application will see a single cellular-facing IP address,
   and during transient phase it will see 2 IP addresses (with a
   possibility for more than 2 concurrent IP addresses on some 5G system
   implementations).  In cases where the server is single-homed and the
   Wifi interface is down, and assuming a full-mesh path manager policy,
   there will be in general one subflow, and from time to time,
   temporarily 2 subflows (or more on some 5G systems).  In cases where
   two mobile 5G devices are communicating with each other over MPTCP
   and with the same assumptions on Wifi and path manager policy, there



de Foy, et al.          Expires December 24, 2018               [Page 7]

Internet-Draft                 MPTCP IN 5G                     June 2018


   will be in general one subflow, and from time to time, temporarily 2
   or even more rarely 4 subflows (again, possibly more on some 5G
   systems).

   MPTCP must create new subflows when a new IP address on a same or a
   new cellular-facing network interface becomes available to the
   application.  MPTCP may keep using the first subflow during a
   transient phase.  Here are some considerations related to this
   transient phase:

   o  When compared with simply waiting for the first IP address to be
      brought down, ramping down usage of the first subflow will not
      incur inefficiencies from resending lost segments.  This may
      especially help low-latency applications by avoiding throughput
      drop.

   o  Assuming a lowest-rtt-first scheduling policy is used, after the
      initial TCP slow start, the shortest path subflow should typically
      carry the most traffic.  Ramping down should ideally start after
      the initial slow start is over.

   o  To make sure the ramping down completes before the interface is
      brought down by the network, the MPTCP stack should be aware of
      how long will the first network anchor be kept in use, e.g.
      through configuration or communication with the local 5G stack.

   o  Ramping down and closing flows on the first network anchor as soon
      as possible will help recycling network resources more rapidly.
      This is especially true in cases where more than 2 network anchors
      may be used concurrently.

   o  There may be some level of contention between subflows during the
      transient phase, since they share the same air interface, and
      especially if they share the same PDU session and QoS marking.
      The shortest path subflow may therefore not reach its full
      capacity during the transient phase.

   o  Additionally, the shortest subflow must not be closed during the
      transient phase (even if it is less efficient for some reason), to
      avoid losing all connectivity at the end of the transient phase.
      To avoid this issue, the MPTCP stack could for example follow a
      policy not to close any subflow created using the latest IP
      address, during the transient period (in SSC mode 3).

   In cases where cellular is used for backup, there is a possibility
   that the switch to using backup occurs during a transient phase.  To
   support this case, MPTCP should keep creating and releasing subflows
   as described above, even when cellular subflows are used as backup,



de Foy, et al.          Expires December 24, 2018               [Page 8]

Internet-Draft                 MPTCP IN 5G                     June 2018


   to ensure that the backup is always usable.  When a backup event
   occurs during a transient phase, MPTCP should use the subflows
   associated with the most recent cellular-facing IP address, i.e.
   corresponding to the latest/closest network anchor.

   PROPOSED MPTCP BEHAVIOR SPECIFICATION:

   These steps are applicable when the initial IP address returned by
   the network stack is GRACEFUL_REPLACEMENT.

      At any point in time, a new GRACEFUL_REPLACEMENT IP address may be
      made available by the network stack.  The MPTCP stack must create
      new subflows using this new address, gracefully transfer traffic
      to these new subflow(s), and close subflow(s) using the previous
      GRACEFUL_REPLACEMENT IP address before its scheduled closing
      (known by obtaining the valid lifetime of the IP address from the
      operating system).

      Additionally, if an initial backup IP address is a
      GRACEFUL_REPLACEMENT address, the MPTCP stack should consider any
      subsequent GRACEFUL_REPLACEMENT IP address as the new backup IP
      address, in replacement of the first GRACEFUL_REPLACEMENT IP
      address.

2.5.  Behavior of Remote Peer

   The SCS type of an IP address is only available locally, which limits
   to only one peer the MPTCP behavior specified in sections
   Section 2.2, Section 2.3 and Section 2.4.  This can potentially cause
   problems:

      A remote may for example close subflows that should be maintained
      e.g. closing all subflows to a SESSION_LASTING IP address or to
      the latest GRACEFUL_REPLACEMENT address.

      A remote may also not behave optimally in some cases, e.g. because
      it cannot distinguish between a transition from
      GRACEFUL_REPLACEMENT to GRACEFUL_REPLACEMENT, from a temporary
      addition of a NON_PERSISTENT address to a SESSION_LASTING address.

   There are two possible ways to handle this: either explicitly
   transmit the SCS type over MPTCP signalling, or use heuristics on the
   remote peer (e.g. never close a subflow created by a peer, mirror
   behavior of peer, etc.).  In the explicit solution, a MPTCP peer
   provides the SCS type of IP addresses to its remote peer, using
   existing or new options (mp_capable, add_addr, mp_join, or an
   experimental option).  When compared to using heuristics,
   transmitting the SCS type can lead to a less complex and more



de Foy, et al.          Expires December 24, 2018               [Page 9]

Internet-Draft                 MPTCP IN 5G                     June 2018


   explicit implementation, which can help better handling unusual or
   error cases, and adapt to future evolution of 5G or other mobility
   management systems.

3.  MPTCP with 5G Dual Connectivity

   One of the key features of 5G [_3GPP.23.501] is dual connectivity
   (DC).  With DC, a 5G device can be served by two different base
   stations.  DC may play an essential role in leveraging the benefit of
   5G new radio, especially in the evolving architecture with the
   coexistence of 4G and 5G radios.

   On a 5G device with DC, an application is able to send data to the
   destination (e.g., a single-home server) through multiple radio
   links, over one or more PDU sessions.  Some PDU sessions may be over
   a single radio link, while others may have flows over each radio
   link.  Therefore, in a first case, DC can be made visible to
   applications through different IP addresses, while in a second case,
   DC can be used by different flows terminated at the same IP address
   on the device.

   In any of those cases, the issues of out of order delivery and
   diverse latency values need to be supported in DC.  However, such
   reliable communication scenarios have not been addressed in the
   current DC architecture.  Based on the design history of DC in
   earlier systems, the 5G system will need to incorporate features to
   support robustness/reliability (e.g., backup and duplication), that
   will likely result in added complexity.  Meanwhile, similar issues
   have been solved in MPTCP (e.g., two types of sequences at subflow
   and connection levels for out of order delivery, etc.).  MPTCP hence
   could be leveraged in those scenarios.  On the other hand, to satisfy
   new QoS requirements of 5G applications as well as to benefit the
   most from DC, 5G devices are expected to include advanced algorithms
   that control data transmissions over each radio link optimally.  For
   example, those algorithms could aim to minimize overall latency or
   satisfy latency requirements of applications.  Hence, the 5G device
   needs to dynamically select the most suitable path for a given radio
   condition.  Additionally, algorithms for shifting, based on
   congestion, ongoing traffic between transmissions over radio links
   are also necessary.

   MPTCP, which includes path manager, scheduler, and congestion control
   functions, shows a lot of potential to address the issues mentioned
   above.  MPTCP could, therefore, be integrated with DC and the 5G
   protocol stack, as an alternative to developing 5G-specific
   solutions.  As part of this integration, the MPTCP stack should be
   aware of the presence of multiple radio links, whether they are
   exposed using multiple IP addresses or hidden under a single IP



de Foy, et al.          Expires December 24, 2018              [Page 10]

Internet-Draft                 MPTCP IN 5G                     June 2018


   address.  MPTCP's scheduler should optimally partition traffic or
   duplicate a data flow over different links, depending on the
   application's need, network policy, and conditions.

4.  IANA Considerations

   This document requests no IANA actions.

5.  Security Considerations

   No new security considerations are identified at this time.

6.  Acknowledgements

   Thanks to following people for contributing, reviewing or providing
   feedback: Debashish Purkayastha, Akbar Rahman, Ulises Olvera-
   Hernandez, Sri Gundavelli.

7.  Informative References

   [_3GPP.23.401]
              3GPP, "General Packet Radio Service (GPRS) enhancements
              for Evolved Universal Terrestrial Radio Access Network
              (E-UTRAN) access", 3GPP TS 23.401 15.3.0, 3 2018,
              <http://www.3gpp.org/ftp/Specs/html-info/23401.htm>.

   [_3GPP.23.501]
              3GPP, "System Architecture for the 5G System", 3GPP
              TS 23.501 15.14.0, 3 2018,
              <http://www.3gpp.org/ftp/Specs/html-info/23501.htm>.

   [I-D.feng-dmm-ra-prefixtype]
              Feng, W. and D. Moses, "Router Advertisement Extensions
              for On-Demand Mobility", draft-feng-dmm-ra-prefixtype-02
              (work in progress), March 2018.

   [I-D.ietf-dmm-ondemand-mobility]
              Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S.
              Jeon, "On Demand Mobility Management", draft-ietf-dmm-
              ondemand-mobility-14 (work in progress), March 2018.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <https://www.rfc-editor.org/info/rfc4861>.






de Foy, et al.          Expires December 24, 2018              [Page 11]

Internet-Draft                 MPTCP IN 5G                     June 2018


   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
              <https://www.rfc-editor.org/info/rfc6824>.

   [RFC6897]  Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application
              Interface Considerations", RFC 6897, DOI 10.17487/RFC6897,
              March 2013, <https://www.rfc-editor.org/info/rfc6897>.

   [RFC8041]  Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and
              Operational Experience with Multipath TCP", RFC 8041,
              DOI 10.17487/RFC8041, January 2017,
              <https://www.rfc-editor.org/info/rfc8041>.

Authors' Addresses

   Xavier de Foy
   InterDigital Communications, LLC
   1000 Sherbrooke West
   Montreal
   Canada

   Email: Xavier.Defoy@InterDigital.com


   Michelle Perras
   InterDigital Communications, LLC
   Montreal
   Canada

   Email: Michelle.Perras@InterDigital.com


   Uma Chunduri
   Huawei USA
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Email: uma.chunduri@huawei.com






de Foy, et al.          Expires December 24, 2018              [Page 12]

Internet-Draft                 MPTCP IN 5G                     June 2018


   Kien Nguyen
   National Institute of Information and Communications Technology
   YRP Center No.1 Building 7F, 3-4 Hikarinooka, Yokosuka
   Kanagawa  239-0847
   Japan

   Email: kienng@nict.go.jp


   Mirza Golam Kibria
   National Institute of Information and Communications Technology
   YRP Center No.1 Building 7F, 3-4 Hikarinooka, Yokosuka
   Kanagawa  239-0847
   Japan

   Email: mirza.kibria@nict.go.jp


   Kentaro Ishizu
   National Institute of Information and Communications Technology
   YRP Center No.1 Building 7F, 3-4 Hikarinooka, Yokosuka
   Kanagawa  239-0847
   Japan

   Email: ishidu@nict.go.jp


   Fumihide Kojima
   National Institute of Information and Communications Technology
   YRP Center No.1 Building 7F, 3-4 Hikarinooka, Yokosuka
   Kanagawa  239-0847
   Japan

   Email: f-kojima@nict.go.jp

















de Foy, et al.          Expires December 24, 2018              [Page 13]