[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits] [IPR]

Versions: 00

Multipath TCP Working Group                                     M. Amend
Internet-Draft                                          Deutsche Telekom
Intended status: Experimental                               July 8, 2019
Expires: January 9, 2020


        Multipath TCP extension for Robust Session Establishment
                       draft-amend-mptcp-robe-00

Abstract

   Multipath TCP extends the plain, singlepath limited, TCP towards the
   capability of multipath transmission.  This greatly improves the
   reliability and performance of TCP communication.  For backwards
   compatiblity reason the Multipath TCP was designed to setup
   successfully an inital path first, after which subsequent paths can
   be added for multipath transmission.  For that reason the Multipath
   TCP has the same limitations as the plain TCP during connection
   setup, in case the selected path is not functional.

   RobE provides the ability to simultaneously use multiple paths for
   connection setup.  This document presents with RobE a set of
   extensions to Multipath TCP to overcome its singlepath limitation
   during connection initialisation and extends it to a full fledged
   multipath protocol.  RobE ensures connecitivity if at least one
   functional path out of a bunch of paths is given and offers beside
   that the opportunity to significantly improve loading times of
   Internet services.

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 January 9, 2020.






Amend                    Expires January 9, 2020                [Page 1]


Internet-Draft                 MPTCP RobE                      July 2019


Copyright Notice

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

   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Comparison of RobE and traditional MPTCP  . . . . . . . .   4
     1.3.  Simple RobE (RobE_SIM)  . . . . . . . . . . . . . . . . .   6
     1.4.  Extended RobE (RobE_EXT)  . . . . . . . . . . . . . . . .   6
   2.  Operation Overview  . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  MP_JOIN_CAP option  . . . . . . . . . . . . . . . . . . .   7
     2.2.  RobE_EXT negotiation  . . . . . . . . . . . . . . . . . .   7
     2.3.  States of operation . . . . . . . . . . . . . . . . . . .   7
       2.3.1.  RobE_SIM  . . . . . . . . . . . . . . . . . . . . . .   7
       2.3.2.  RobE_EXT  . . . . . . . . . . . . . . . . . . . . . .   7
     2.4.  Fallback mechanism  . . . . . . . . . . . . . . . . . . .   8
     2.5.  TFO support . . . . . . . . . . . . . . . . . . . . . . .   8
   3.  Practical implications  . . . . . . . . . . . . . . . . . . .   9
     3.1.  Performance compared to MP-TCP  . . . . . . . . . . . . .   9
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Multipath TCP Robust session Establishment (MPTCP RobE) is a set of
   extensions to regular MPTCP [RFC6824] and its next upcoming version
   [I-D.ietf-mptcp-rfc6824bis], which releases single path limitations
   during the initial connection setup.  Several scenarios requires and
   benefit from a reliable and in time connection setup which is not
   covered by [RFC6824] and [I-D.ietf-mptcp-rfc6824bis] so far.  MPTCP
   was designed to be compliant with the TCP standard [RFC0793] and
   introduced therefore the concept of an inital TCP flow and adding



Amend                    Expires January 9, 2020                [Page 2]


Internet-Draft                 MPTCP RobE                      July 2019


   subsequent flows after sucessfull multipath negotiation on the
   initial path.  While fulfilling its purpose, MPTCP is however fully
   dependent on the transmission characteristics of the communication
   link selected for initiating MPTCP.

   RobE aims to overcomes the limitations of [RFC6824] and
   [I-D.ietf-mptcp-rfc6824bis] using one initial flow and introduces the
   concept of potential initial flows triggered simultaneously.
   Potential initial flows gives the freedom to use more than one path
   to request multipath connectivity and select the initial flow at a
   later point.  Potential initial flow mechanisms and the gain of
   robustness and performance over the traditional MPTCP connection
   setup are evaluated in [RobE_slides] and [RobE_paper].

   Two mechanisms of RobE, a simple and an extended version are
   specified in this document and are further referred to as RobE_SIM
   and RobE_EXT.  RobE_SIM is a break-before-make mechanism,
   guaranteeing at least the robust connection establishment, however
   the RobE_EXT reuses every potential inital flow request to combine it
   with less overhaed and accelerated multipath availability, leveraging
   a new MPTCP option MP_JOIN_CAP.  From a standardization perspective,
   the RobE_SIM is fully compliant with [RFC6824] and
   [I-D.ietf-mptcp-rfc6824bis] and is herein more of a descriptive and
   procedurale nature.  The RobE_EXT requires a new MPTCP option but
   with the potential to significantly improve the MPTCP experience.

   Table 1 summarizes the impact of RobE_SIM and RobE_EXT compared to
   [RFC6824] and [I-D.ietf-mptcp-rfc6824bis].  Considered are the
   scenarios where the initial path (IP) is disturbed and the impact on
   connection setup duration for the IP and multipath (MP) availability.
   In particular both setup durations are a mean to significantly
   improve the quality of experience.



















Amend                    Expires January 9, 2020                [Page 3]


Internet-Draft                 MPTCP RobE                      July 2019


   +----------------+--------------+--------------+--------------------+
   | Scenario       | MPTCP        | MPTCP +      | MPTCP + RobE_EXT   |
   |                |              | RobE_SIM     |                    |
   +----------------+--------------+--------------+--------------------+
   | IP packet loss | Delayed      | No impact    | No impact          |
   |                | connection   |              |                    |
   +----------------+--------------+--------------+--------------------+
   | IP broken      | No           | No impact    | No impact          |
   |                | connection   |              |                    |
   +----------------+--------------+--------------+--------------------+
   | IP setup       | default      | fastest path | fastest path       |
   | duration       | route        |              |                    |
   | dependency     |              |              |                    |
   +----------------+--------------+--------------+--------------------+
   | MP             | MP_CAPABLE + | MP_CAPABLE + | max(MP_CAPABLE_1,  |
   | availability   | MP_JOIN      | MP_JOIN      | MP_CAPABLE_2)      |
   | duration       |              |              |                    |
   +----------------+--------------+--------------+--------------------+

                     IP: Initial Path; MP: Multi-Path

      Table 1: Overview RobE features during initial connection setup

   This document presents the protocol, procedures and changes required
   to extend MPTCP by a robust session setup; specifically, those for
   signaling and setting up multiple paths ("subflows")

1.1.  Terminology

   This document makes use of a number of terms that are either MPTCP-
   specific or have defined meaning in the context of MPTCP, as follows:

      Path: A sequence of links between a sender and a receiver, defined
      in this context by a 4-tuple of source and destination address/
      port pairs.

      Subflow: A flow of TCP segments operating over an individual path,
      which forms part of a larger MPTCP connection.  A subflow is
      started and terminated similar to a regular TCP connection.

1.2.  Comparison of RobE and traditional MPTCP

   Section has DRAFT status

   Figure 1 shows the traditional way of MPTCP handshaking with a
   MP_CAPABLE first, followed when successful by additional flows
   engaging MP_JOIN.  MPTCP v0 [RFC6824] and MPTCP v1




Amend                    Expires January 9, 2020                [Page 4]


Internet-Draft                 MPTCP RobE                      July 2019


   [I-D.ietf-mptcp-rfc6824bis] differ in that a Key-A is sent with the
   first MP_CAPABLE or not.

               Host A                                  Host B
        ------------------------                       ----------
        Address A1    Address A2                       Address B1
        ----------    ----------                       ----------
            |             |                                |
            |            SYN + MP_CAPABLE(Key-A[*])        |
            |--------------------------------------------->|
            |<---------------------------------------------|
            |          SYN/ACK + MP_CAPABLE(Key-B)         |
            |             |                                |
            |        ACK + MP_CAPABLE(Key-A, Key-B)        |
            |--------------------------------------------->|
            |             |                                |
            |             |   SYN + MP_JOIN(Token-B, R-A)  |
            |             |------------------------------->|
            |             |<-------------------------------|
            |             | SYN/ACK + MP_JOIN(HMAC-B, R-B) |
            |             |                                |
            |             |     ACK + MP_JOIN(HMAC-A)      |
            |             |------------------------------->|
            |             |<-------------------------------|
            |             |             ACK                |

            [*] Key-A in the first MP-capable is related to
                MPTCP v0 only and does not exist in MPTCP v1.

                     Figure 1: MPTCP connection setup

   Figure 2 changes the concept of the subsequent establishment in
   Figure 1 towards simultaneous requests (potential initial flows).
   For that, on several paths the MP_CAPABLE is used, like independent
   initial flow establishment.  The final decision which path is
   selected as the main one and the handling of the remaining flow(s)
   differs in SA6.1 when RobE_SIM is applied or instead SA6.2 RobE_EXT.














Amend                    Expires January 9, 2020                [Page 5]


Internet-Draft                 MPTCP RobE                      July 2019


                Host A                                  Host B
        ------------------------                       ----------
        Address A1    Address A2                       Address B1
        ----------    ----------                       ----------
            |             |                                |
            |            SYN + MP_CAPABLE(Key-A[*])        |
    (SA1)   |--------------------------------------------->|  (SB1)
            |             |    SYN + MP_CAPABLE(Key-A'[*]) |
    (SA2)   |             |------------------------------->|  (SB2)
            |             |                                |
    (SA3)   |<---------------------------------------------|  (SB3)
            |          SYN/ACK + MP_CAPABLE(Key-B)         |
    (SA4)   |             |<-------------------------------|  (SB4)
            |             |   SYN/ACK + MP_CAPABLE(Key-B') |
            |             |                                |
            |        ACK + MP_CAPABLE(Key-A, Key-B)        |
    (SA5)   |--------------------------------------------->|  (SB5)
            |             |             RST                |
    (SA6.1) |             |------------------------------->|  (SB6.1)
   RobE SIM |             |                                |
   (robust) |             |                                |
   -------------------------------------------------------------------
   RobE EXT |             |                                |
   (+fast)  |             | ACK + MP_JOIN_CAP(Key-A, HMAC) |
    (SA6.2) |             |------------------------------->|  (SB6.2)

            [*] Key-A in the first MP-capable is related to
                MPTCP v0 only and does not exist in MPTCP v1.

          Figure 2: MPTCP RobE_SIM and RobE_EXT connection setup

1.3.  Simple RobE (RobE_SIM)

   Sender only implementation, no negotiation required, robust according
   to Table 1, connection setup benefits from fastest path

1.4.  Extended RobE (RobE_EXT)

   Extends RobE_SIM by reusing the potential initial flows.  This
   eliminates the overhead from RobE_SIM and accelerate the transmission
   speed by early availablity of multiple paths.  Further it relaxes the
   dependency on a reliable third ACK of the 3-way handshake in MPTCP v1

2.  Operation Overview







Amend                    Expires January 9, 2020                [Page 6]


Internet-Draft                 MPTCP RobE                      July 2019


2.1.  MP_JOIN_CAP option

                      1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+-------+-------+---------------+
   |     Kind      |    Length     |Subtype|       |    ADDR_ID    |
   +---------------+---------------+-------+-------+---------------+
   |                    Sender's Key-A (64 bits)                   |
   |                                                               |
   |                                                               |
   +---------------------------------------------------------------+
   |                        HMAC (>=96 bits)                       |
   |                                                               |
   |                                                               |
   :                                                               :
   +---------------------------------------------------------------+
    Key-B_fast_hash = crc16(Key-B) & 0x3FF          -> (10bit)
    HMAC_keys =  HMAC(Key-A+Key-B+Key-B')           -> (>=96bit)
    HMAC =  (HMAC_keys & ~0x3FF) | Key-B_fast_hash  -> (size HMAC_keys)


                           Figure 3: MP_JOIN_CAP

   The ADDR_ID field of the MP_JOIN_CAP in Figure 3 is set according to
   the definition of MP_JOIN in [RFC6824] [I-D.ietf-mptcp-rfc6824bis].

2.2.  RobE_EXT negotiation

   [Tbd]

2.3.  States of operation

   [Tbd], according to Table 1 describe for MPTCPv0/v1 the different
   states which can occure; Section has DRAFT status

2.3.1.  RobE_SIM

   [Tbd]

2.3.2.  RobE_EXT

   1.  In the flow diagram Figure 2, A1<->B1 is assumed to be the
       initial flow.  A2<->B1 shall be recycled and the ACK is sent with
       MP_JOIN_CAP.  Furthermore, the MP_CAPABLE arrives first at Host B
       (SB5) and the MP_JOIN_CAP afterwards (SB6.2).  When the
       MP_JOIN_CAP is received, Host B has to iterate over the
       connection list once (like MP_JOIN) and check for Key-A
       availability.  If a Key-A connection is found, this one is



Amend                    Expires January 9, 2020                [Page 7]


Internet-Draft                 MPTCP RobE                      July 2019


       validated against the HMAC value.  The validation has two
       reasons: first, several Key-A can exist, because different hosts
       may choose the same Key-A by accident.  Furthermore, no one can
       join a connection by just recording/brute-forcing Key-A and
       duplicating the request.

   2.  Like above, but MP_JOIN_CAP arrives before last MP_CAPABLE at
       Host B

       *  [I-D.ietf-mptcp-rfc6824bis]; Based on Key-A, Host B will
          iterate over the connection list, but it will not find a
          match, because Key-A of the previous selected initial flow
          (SA3, SA5) has not arrived yet.  So it will continue with a
          fast iteration only over the connections which are still in
          establishment phase using the 10 bit Key-B fast hash
          (crc16(Key-B) & 0x3FF).  If it matches against a (precomputed)
          existing Key-B_fast_hash in the connection list, it will
          validate the request using the HMAC(Key-A+B+B') to ensure
          legitimation.  If successful, both, the initial flow and the
          MP_JOIN_CAP flow, can be immediately established.  This is
          true, because without the knowledge of Key-B, Host A could not
          calculate the HMAC.  So it is clear, that Host A had received
          the SYN/ACK (SB3).  This also mitigates the exchange of a
          reliable ACK during the handshake process.  MPTCP sends the
          Key-A only with the last ACK and therefore prevents subsequent
          flow establishment until successful reception at Host B.
          Using RobE_EXT, the reception of a MP_JOIN_CAP
          ([I-D.ietf-mptcp-rfc6824bis]) is sufficient to establish both,
          the path carrying Key-B and Key-B'.

       *  [RFC6824]; Can match based on Key-A, same effort as for a MP
          JOIN.

   3.  A2<->B1 is selected as initial flow, because the respective SYN/
       ACK returns earlier at Host A.  It is the same as above, just the
       other way round.

2.4.  Fallback mechanism

   [Tbd], e.g. one path does not support RobE or MP-TCPv0/v1

2.5.  TFO support

   [Tbd]







Amend                    Expires January 9, 2020                [Page 8]


Internet-Draft                 MPTCP RobE                      July 2019


3.  Practical implications

3.1.  Performance compared to MP-TCP

   [Tbd]

4.  Security Considerations

   [Tbd]

5.  Acknowledgments

   [Tbd]

6.  IANA Considerations

   [Tbd]

7.  Informative References

   [I-D.ietf-mptcp-rfc6824bis]
              Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
              Paasch, "TCP Extensions for Multipath Operation with
              Multiple Addresses", draft-ietf-mptcp-rfc6824bis-18 (work
              in progress), June 2019.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <https://www.rfc-editor.org/info/rfc793>.

   [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>.

   [RobE_paper]
              Amend, M., Rakocevic, V., Matz, A. P., and E. Bogenfeld,
              "RobE: Robust Connection Establishment for Multipath TCP",
              ANRW '18 p. 76-82, July 2018,
              <http://doi.acm.org/10.1145/3232755.3232762>.

   [RobE_slides]
              Amend, M., Matz, A. P., and E. Bogenfeld, "A proposal for
              MPTCP Robust session Establishment (MPTCP RobE)", IETF
              99 Multipath TCP WG session, July 2017,
              <https://datatracker.ietf.org/meeting/99/materials/slides-
              99-mptcp-a-proposal-for-mptcp-robust-session-
              establishment-mptcp-robe-01>.



Amend                    Expires January 9, 2020                [Page 9]


Internet-Draft                 MPTCP RobE                      July 2019


Author's Address

   Markus Amend
   Deutsche Telekom
   Deutsche-Telekom-Allee 7
   64295 Darmstadt
   Germany

   Email: Markus.Amend@telekom.de










































Amend                    Expires January 9, 2020               [Page 10]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/