Internet DRAFT - draft-bonaventure-mptcp-long-options

draft-bonaventure-mptcp-long-options







MPTCP Working Group                                       O. Bonaventure
Internet-Draft                                                 UCLouvain
Intended status: Informational                             July 06, 2015
Expires: January 7, 2016


              Supporting long TCP options in Multipath TCP
                draft-bonaventure-mptcp-long-options-00

Abstract

   The extensibility of TCP is severely limited by the Data Offset field
   of the TCP header that limits the number of bytes that can be used in
   each segment to transport options.  This document considers Multipath
   TCP as the starting point and analyses different alternatives to
   improve the ability of Multipath TCP to transport TCP extensions.

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 http://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 7, 2016.

Copyright Notice

   Copyright (c) 2015 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
   (http://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.



Bonaventure              Expires January 7, 2016                [Page 1]

Internet-Draft             MPTCP Long Options                  July 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Lessons learned with Multipath TCP  . . . . . . . . . . . . .   3
   3.  Extending the DSS option  . . . . . . . . . . . . . . . . . .   4
     3.1.  First approach : TCP EOL as marker  . . . . . . . . . . .   6
     3.2.  Second approach : Option length in DSS  . . . . . . . . .   9
     3.3.  Third approach : using the control stream for options . .  10
     3.4.  Middlebox interference  . . . . . . . . . . . . . . . . .  12
   4.  Negotiating the extended DSS option . . . . . . . . . . . . .  16
   5.  Compatibility with the existing TCP options . . . . . . . . .  16
     5.1.  End-of-Option List  . . . . . . . . . . . . . . . . . . .  16
     5.2.  Maximum Segment Size  . . . . . . . . . . . . . . . . . .  16
     5.3.  No-Operation  . . . . . . . . . . . . . . . . . . . . . .  16
     5.4.  SACK-Permitted  . . . . . . . . . . . . . . . . . . . . .  16
     5.5.  SACK option . . . . . . . . . . . . . . . . . . . . . . .  17
     5.6.  Timestamps  . . . . . . . . . . . . . . . . . . . . . . .  17
     5.7.  TCP-TFO . . . . . . . . . . . . . . . . . . . . . . . . .  17
     5.8.  TCP-AO option . . . . . . . . . . . . . . . . . . . . . .  17
     5.9.  TCP-User Timeout  . . . . . . . . . . . . . . . . . . . .  17
     5.10. Multipath TCP options . . . . . . . . . . . . . . . . . .  17
   6.  Security consideration  . . . . . . . . . . . . . . . . . . .  18
   7.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  18
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  19
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   Multipath TCP is an extension to TCP [RFC0793] that was standardized
   in [RFC6824].  Multipath TCP uses several types of TCP options to
   exchange data.  Like other TCP extensions, Multipath TCP suffers from
   the 4 bits Data Offset field of the TCP header that limits the size
   of the entire header, including options to 60 bytes.  This limits the
   total length of the TCP options to 40 bytes, which becomes a problem
   for segments that include SACK [RFC2018], Timestamp [RFC1323],
   Multipath TCP [RFC6824] and TCP-AO [RFC5925].  For example, it
   becomes difficult to combine these four option types in a single
   segment.

   Various techniques to extend the TCP option space are being discussed
   [I-D.ietf-tcpm-tcp-edo] within the TCPM working group.  As of this
   writing, there is not enough experience with such extensions and
   their possible interference with middleboxes that are known to limit
   the extensibility of TCP [IMC11].

   Instead of starting from regular TCP as the other proposals, we
   assume that Multipath TCP has been successfully negotiated for the



Bonaventure              Expires January 7, 2016                [Page 2]

Internet-Draft             MPTCP Long Options                  July 2015


   TCP connection and evaluate how the unique features of Multipath TCP
   can be tweaked to carry large TCP options including long SACK blocks.
   Instead of changing the semantics of the Data Offset field, adding a
   new TCP option or encoding the payload, we start from the DSS options
   used by Multipath TCP.  This gives us more flexibility and leverages
   the middlebox resilience provided by Multipath TCP.

   In this document, we focus on the transport of longer TCP options
   once the Multipath TCP connection has been established.  We leave for
   further work the problem of extending the TCP option space in the SYN
   segment during the three-way handshake.

   This document is organized as follows.  We first discuss the lessons
   that were learned from the specification, implementation and
   deployment of Multipath TCP in section Section 2.  We then discuss in
   Section 3 several solutions that modify the DSS option to support the
   transmission of additional TCP options.  We propose in Section 4 to
   negotiate the utilisation of this option as a new Multipath TCP
   version.  Section 5 discusses how the existing TCP options can be
   supported with the solution proposed in this document.

2.  Lessons learned with Multipath TCP

   During the design, implementation and deployment of Multipath TCP
   during the last years we have learned some lessons on how various
   types of middleboxes can interfere with a TCP extension.  These
   lessons have been documented in several scientific publications
   [IMC11] [HotMiddlebox13], but it is worth summarising them again.

   The first lesson concerns the initial three way handshake.  Most TCP
   extensions assume that the utilisation of a new option can be safely
   negotiated by sending an option inside the initial SYN segment and
   verifying that the same option is present in the returned SYN+ACK.
   This is the approach used for SACK [RFC2018] and to some extent the
   WSCALE and TS extensions defined in [RFC7323].  Unfortunately,
   measurements with Multipath TCP showed that there are middleboxes
   that simply echo in the SYN+ACK segment any unknown option received
   in the SYN segment.  To cope with such middleboxes, the TCP option
   used to negotiate the utilisation of a TCP extension cannot be the
   same in the SYN and SYN+ACK segments.  The active opener must verify
   that the option sent in the SYN segment has not been modified before
   being returned in the SYN+ACK segment.

   The second lesson is also about the initial three way handshake.  A
   middlebox can modify the SYN+ACK segment on the return path without
   having observed the option contained in the SYN segment.  This kind
   of middlebox interference can be a problem for the negotiation of the
   utilisation of a TCP extension since the states of the active and the



Bonaventure              Expires January 7, 2016                [Page 3]

Internet-Draft             MPTCP Long Options                  July 2015


   passive opener might disagree.  Multipath TCP solves this problem by
   sending information in the third ACK.

   The third lesson is that despite a successful negotiation during the
   three way handshake by using option type x, middleboxes might still
   remove option type x in some segments on the connection.  Any TCP
   extension must be able to cope with segments that do not contain an
   expected option.

   The fourth lesson is that middleboxes can split segments.  Such
   middleboxes can be located inside the network or be simply the TSO
   implementation on the network interface card of the sending hosts
   [IMC11].  These network interface cards are very popular and it is
   difficult for a TCP stack to correctly detect their exact behaviour
   concerning the handling of TCP options.  These cards expose a large
   MSS to the TCP stack and then split the large segment in smaller
   segments that are (usually) checksummed by the card.  According to
   [IMC11] all the tested cards copy all the options included in the
   large segment into the smaller ones.

   The fifth lesson is that middleboxes can coalesce segments.  Such
   middleboxes can be located inside the network or more likely on the
   receiving host.  Most network interface cards implement GRO by
   performing the opposite operation of TSO.  If the segments that are
   received in sequence always contain the same option, then these
   segments are coalesced in a larger segment which is delivered to the
   TCP stack.  Note that the size of the segments that are delivered to
   the TCP stack will vary in function of the packet losses and also of
   the utilisation of options by the sending host.

   The sixth lesson is that middleboxes can modify, inject or remove
   data from the payload of TCP segments.  A typical example are the
   Application Level Gateways used on Network Address Translators to
   "seamlessly" support application-level protocols that exchange IP
   addresses in the bytestream.  To support these applications, ALGs
   need to modify the IP addresses (and possibly port numbers) exchanged
   in the bytestream.

3.  Extending the DSS option

   The DSS option is defined in [RFC6824].  This option has a variable
   length depending on the utilisation of the 'm', 'M', 'a' and 'A'
   flags.  The format of this option in shown in Figure 1.  An important
   point to note is that it contains several flags that are currently
   reserved for future use.






Bonaventure              Expires January 7, 2016                [Page 4]

Internet-Draft             MPTCP Long Options                  July 2015


                           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|  ( reser.) |F|m|M|a|A|
      +---------------+---------------+-------+----------------------+
      |           Data ACK (4 or 8 octets, depending on flags)       |
      +--------------------------------------------------------------+
      |   Data sequence number (4 or 8 octets, depending on flags)   |
      +--------------------------------------------------------------+
      |              Subflow Sequence Number (4 octets)              |
      +-------------------------------+------------------------------+
      |  Data-Level Length (2 octets) |      Checksum (2 octets)     |
      +-------------------------------+------------------------------+


                           Figure 1: DSS option

   We assume in this document that the utilisation of the modified DSS
   option is negotiated as a new Multipath TCP version in the three way
   handshake.

   The general approach evaluated in this document is to place the
   additional TCP options inside the payload and modify the DSS to
   indicate which part of the payload contains TCP options (if any) and
   which part contains payload data (if any).  The generic solution is
   shown graphically in Figure 2.

                                 <- ext. ->
                                   options

    +--------+---------+--------+----------+--------...-----+
    | ip hdr | TCP hdr |  DSS   | Options  |    User Data   |
    +--------+---------+--------+----------+--------...-----+
                        <- DO -> <- Payload of TCP segment-->
                        covered    covered by DSS mapping


                Figure 2: Usage of the modified DSS option

   The key question for all the approaches discussed in this section is
   how to modify the DSS option to indicate the boundary between the
   additional TCP options and the payload.  For simplicity, we assume in
   this section that only the Multipath TCP DSS option is placed in the
   extended TCP header.  The other TCP are placed inside the payload
   which is covered by the DSS option.






Bonaventure              Expires January 7, 2016                [Page 5]

Internet-Draft             MPTCP Long Options                  July 2015


3.1.  First approach : TCP EOL as marker

   A first approach to extend the TCP option space is to simply assume
   that each DSS option is always followed by one or more TCP options
   and that the EOL option, defined in [RFC0793] is used to mark the end
   of the additional TCP options.  For simplicity, we assume that the
   DSS option is the only option that consumes space in the TCP header
   extension (i.e.  the Data Offset field of the TCP header has a value
   equal to the length of the DSS option, possibly with a few NOP
   options to align it on 32 bits boundaries).  The length included in
   the DSS option remains the length of the payload which is part of the
   bytestream without taking into account the bytes consummed by the
   included TCP options.  This is illustrated in Figure 3.  If the DSS
   checksum has been negotiated, it is computed only on the user data
   and the pseudo-header defined in [RFC6824].

    +--------+---------+--------+--------+-----+------...-----+
    | IP hdr | TCP hdr |  DSS   | Opt x  | EOL |  User data   |
    +--------+---------+--------+--------+-----+------...-----+
                                  <- Payload of TCP segment-->
                                     covered by DSS mapping


    Figure 3: Using the TCP EOL option to mark the boundary between TCP
                           options and user data

   In this figure, Option x and the payload are optional.  With this
   design there is always one byte used by the EOL option inside each
   segment that contains a DSS option.

   Let us now analyse how this solution react to middleboxes that
   coalesce or split segments.  Figure 4 illustrates a middlebox that
   splits a large segment and copies the DSS option in both.  The DSS
   option shows the mapping between the DSN (2) and the subflow sequence
   number (1) and the length covered by the DSS option.
















Bonaventure              Expires January 7, 2016                [Page 6]

Internet-Draft             MPTCP Long Options                  July 2015


      +---------+--------+-----+------...---+
      | TCP hdr |  DSS   | EOL |  Payload   |
      | seq=1   | 2->1   |     | 4 bytes    |
      | len=5   | len=4  |     |            |
      +---------+--------+-----+------...---+
                    ||
                    \/
      +---------+--------+-----+------...---+
      | TCP hdr |  DSS   | EOL |  Payload   |
      | seq=1   | 2->1   |     | 2 bytes    |
      | len=3   | len=4  |     |            |
      +---------+--------+-----+------...---+

      +---------+--------+-------...---+
      | TCP hdr |  DSS   |   Payload   |
      | seq=3   | 2->1   |   2 bytes   |
      | len=2   | len=4  |             |
      +---------+--------+-------...---+


                   Figure 4: Effect of Segment splitting

   If the segment is split as shown in the above example, a Multipath
   TCP receiver will parse the DSS option in the first segment and wait
   until it has received all the mapped data before extracting the EOL
   option and the payload.  Segment splitting does not affect this
   solution.

   If a middlebox coalesces segments, the situation is different.  Let
   us consider the scenario shown in Figure 5.





















Bonaventure              Expires January 7, 2016                [Page 7]

Internet-Draft             MPTCP Long Options                  July 2015


      +---------+--------+-----+------...---+
      | TCP hdr |  DSS   | EOL |  Payload   |
      | seq=1   | 2->1   |     | 2 bytes    |
      | len=3   | len=2  |     |            |
      +---------+--------+-----+------...---+

      +---------+--------+-----+-------...--+
      | TCP hdr |  DSS   | EOL |   Payload  |
      | seq=3   | 4->3   |     |  2 bytes   |
      | len=3   | len=2  |     |            |
      +---------+--------+-----+------...---+
                    ||
                    \/

      +---------+--------+-----+------...---+-----+------...---+
      | TCP hdr |  DSS   | EOL |  Payload   | EOL |  Payload   |
      | seq=1   | 2->1   |     |  2 bytes   |     |  2 bytes   |
      | len=5   | len=2  |     |            |     |            |
      +---------+--------+-----+------...---+-----+------------+

                   or

      +---------+--------+-----+------...---+-----+------...---+
      | TCP hdr |  DSS   | EOL |  Payload   | EOL |  Payload   |
      | seq=1   | 3->3   |     |  2 bytes   |     |  2 bytes   |
      | len=5   | len=2  |     |            |     |            |
      +---------+--------+-----+------...---+-----+------------+



                  Figure 5: Effect of Segment Coalescing

   Since the two small segments do not contain the same option, a
   middlebox should not in theory coalesce them.  Anyway, let us analyse
   what happens in this case.  If the middlebox only copies the TCP
   option in the first segment, then the receiver will process the first
   EOL option and the first block of 2 bytes of payload.  The remaining
   bytes are not covered by a mapping.  The receiver will ack at the
   data level the first block of two bytes in the payload but not the
   second.  After some time, the sender will retransmit the
   unacknowledged data with a new DSS option that will cover the data of
   the second segment.  The same applies if the middlebox copies the
   second DSS option in the coalesced segment.

   A first drawback of this solution is that the TCP stack must parse
   the payload to extract all the options that are included inside a DSS
   map.  A possible alternative to simplify this parsing would be to
   redefine an unused bit of the DSS option to indicate that the mapped



Bonaventure              Expires January 7, 2016                [Page 8]

Internet-Draft             MPTCP Long Options                  July 2015


   payload starts with TCP options.  If this bit is reset, then there
   are no options in the payload and the receiver can process the
   payload as usual.  Parsing the payload might have a performance
   impact on packet filters used on some routers or firewalls that
   process TCP options.

   A second drawback of this approach is that the TCP options consumme
   TCP sequence space and are transmitted reliably.  This implies that a
   measurement application that uses the difference between the sequence
   number of the SYN and FIN segments to compute the number of bytes
   exchanged over a connection will overestimate the number of bytes
   exchanged by the communicating applications.

3.2.  Second approach : Option length in DSS

   The second approach is to include an 'Options length' field inside
   the DSS option to indicate the part of the payload that follows the
   DSS option that is used by TCP options.  This is illustrated with the
   modified DSS option below.

                          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|  ( reser.) |F|m|M|a|A|
     +---------------+---------------+-------+----------------------+
     |           Data ACK (4 or 8 octets, depending on flags)       |
     +--------------------------------------------------------------+
     |   Data sequence number (4 or 8 octets, depending on flags)   |
     +--------------------------------------------------------------+
     |              Subflow Sequence Number (4 octets)              |
     +-------------------------------+------------------------------+
     |  Data-Level Length (2 octets) |      Checksum (2 octets)     |
     +-------------------------------+------------------------------+
     |   TCP  Options  Length        |
     +-------------------------------+



    Figure 6: Extending the DSS option to include a TCP options length

   This 'TCP Options length' field could be encoded in several ways :

   o  as a 16 bits field that encodes the number of bytes used for
      options.  This solution has the advantage of being aligned on 16
      bits boundaries and supports options of up to 64 KBytes.

   o  as an 8 bits field that encodes the number of bytes used for
      options.  This solution supports options of up to 255 bytes.  The



Bonaventure              Expires January 7, 2016                [Page 9]

Internet-Draft             MPTCP Long Options                  July 2015


      DSS option is not aligned on 32 bits boundaries and TCP option
      padding might be required in the TCP extended header.

   o  as an 8 bits field that encodes the number of 32 bits words used
      for options.  This solution supports options of up to 1020 bytes.
      The DSS option is aligned on 16 bits boundaries and TCP option
      padding is required inside the DSS option.

   The last solution is probably the best compromise between overhead
   and extensibility.  It however adds some complexity in the padding
   mechanism that needs to be used to encode the TCP options that appear
   before the DSS option and the TCP options that are encoded within the
   DSS option since both need to be aligned on 32 bits boundaries.

   With the three solutions above, it is possible to send data mapped by
   a DSS option without any TCP option by using a Length field (i.e. 20,
   24 or 28 bytes) for the DSS option that does not include space for
   the 'Options Length'.

3.3.  Third approach : using the control stream for options

   The control stream is an extension to Multipath TCP that was proposed
   in [I-D.paasch-mptcp-control-stream].  This extension redefines one
   flag (called 'S' in Figure 7) of the DSS 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|(reserved)|S|F|m|M|a|A|
     +---------------+---------------+-------+----------------------+
     |        Control ACK (4 or 8 octets, depending on flags)       |
     +--------------------------------------------------------------+
     |Control sequence number (4 or 8 octets, depending on flags)   |
     +--------------------------------------------------------------+
     |              Subflow Sequence Number (4 octets)              |
     +-------------------------------+------------------------------+
     |Control-Level Length (2 octets)|      Checksum (2 octets)     |
     +-------------------------------+------------------------------+


   Figure 7: Modification of the DSS option to indicate whether it maps
                   user data (S=0) or TCP options (S=1)

   The control stream defines two separate bytestreams.  The default
   bytestream is used to carry application level data.  These datas are
   mapped by using the above DSS option with the 'S' flag set to 0.
   When the 'S' flag of the DSS option is set to 1, this indicates that
   the mapped data belongs to the second bytestream.  In



Bonaventure              Expires January 7, 2016               [Page 10]

Internet-Draft             MPTCP Long Options                  July 2015


   [I-D.paasch-mptcp-control-stream], this second bytestream was used to
   exchange options using a special TLV format.  One of the use cases
   mentioned in [I-D.paasch-mptcp-control-stream] was the exchange of
   security keys.  However, this solution was neither implemented nor
   deployed.  We reuse it to map TCP options on the second bytestream.

   Figure 8 shows some examples of segments containing only TCP options,
   only user data or both user data and TCP options.  In the first
   example, the S bit is set to 1 and thus the mapped payload only
   contains TCP options.  In this segment, the DO field of the TCP
   header covers only the DSS option.  In the second example, the S bit
   is set to zero and the payload contains user data.  Again, the DO
   field of the TCP header only covers the DSS option.  The third
   example combines both options and user data in a single segment.  The
   first part of the payload, containing 'Opt x', is covered by the DSS
   with the S bit set to 1.  This DSS maps TCP options.  The second part
   of the payload contains user data.  In this last example, the DO
   field of the TCP header covers the two DSS options.

    TCP segment containing extended options

    +--------+---------+--------------+--------+-------+
    | IP hdr | TCP hdr |  DSS (S=1)   | Opt x  | Opt y |
    +--------+---------+--------------+--------+-------+
                                       <-- Payload ---->
                                         Covered by DSS

    TCP segment containing data

    +--------+---------+--------------+------...---+
    | IP hdr | TCP hdr |  DSS (S=0)   |  Payload   |
    +--------+---------+--------------+------...---+
                                       <- Payload ->
                                      Covered by DSS

    TCP segment containing both extended options and data

                                                   covered by DSS (S=0)
                                                        <-- + --->
    +--------+---------+-----------+-----------+-------+---...---+
    | IP hdr | TCP hdr | DSS (S=1) | DSS (S=0) |Opt x  | Payload |
    +--------+---------+-----------+-----------+-------+---...---+
                                                <- + ->
                                         covered by DSS (S=1)



                  Figure 8: Examples of extended segments



Bonaventure              Expires January 7, 2016               [Page 11]

Internet-Draft             MPTCP Long Options                  July 2015


   Note that to support both data and extended TCP options, two DSS
   options must be placed inside the segment.  This implies that each of
   them must have a length of 20 bytes.  In practice, we do not expect
   that hosts will often need to send extended options and data
   simultaneously.  A better approach is to send data and extended
   options in different segments.

   Each TCP option that is included in the payload mapped by a DSS
   option MUST be encoded by using the standard Type-Length-Value format
   for TCP options [RFC0793].  The TCP options that are included in the
   payload mapped by a DSS option MAY end with TCP option zero (End of
   Option List).  With this modified DSS option, the length of the
   extended TCP options is only limited by the length than can be mapped
   by a DSS option.  Given that a DSS option can map up to 64 KBytes of
   data, it is possible to send up to 64 KBytes worth of options.

3.4.  Middlebox interference

   We now qualitatively evaluate the last solution and analyze how
   middleboxes could interfere with the transmission of extended TCP
   options.

   A first point to note is that although the example below assume for
   simplicity that only the DSS option is part of the TCP header covered
   by the Data Offset, this is not a requirement.  A TCP segment can
   include other TCP options inside the header covered by the Data
   Offset field.

   Our first use case is a middlebox that inserts a new TCP option and
   modifies the TCP Data Offset.  Figure 9 considers the impact of such
   a middlebox on both a segment containing userdata and a segment
   containing extended TCP options.  Such a middlebox was proposed in
   [I-D.ananth-middisc-tcpopt].


















Bonaventure              Expires January 7, 2016               [Page 12]

Internet-Draft             MPTCP Long Options                  July 2015


      Initial segment containing options

      <---     DO covered ---> <-- DSS mapped-->
     +---------+--------------+--------+-------+
     | TCP hdr |  DSS (S=1)   | Opt x  | Opt y |
     +---------+--------------+--------+-------+

      Modified segment containing options

      <---         DO covered        ---> <-- DSS mapped-->
     +---------+----------+--------------+--------+-------+
     | TCP hdr |Added Opt |  DSS (S=1)   | Opt x  | Opt y |
     +---------+----------+--------------+--------+-------+

      Initial segment containing userdata

      <---     DO covered ---> <-- DSS mapped-->
     +---------+--------------+--------+-------+
     | TCP hdr |  DSS (S=0)   |  User data     |
     +---------+--------------+--------+-------+

      Modified segment containing options

      <---         DO covered        ---> <-- DSS mapped-->
     +---------+----------+--------------+--------+-------+
     | TCP hdr |Added Opt |  DSS (S=0)   |    User data   |
     +---------+----------+--------------+--------+-------+



             Figure 9: Impact of the insertion of a TCP option

   The proposed solution correctly copes with such a middlebox.  It does
   not work on a path where a middlebox removes the DSS option because
   this option is required for the operation of Multipath TCP.  In this
   case, Multipath TCP performs a fallback to regular TCP.

   Our second use case is a middlebox that splits a segment that
   contains TCP options or user data and copies the DSS option in both
   resulting segments.  This is illustrated in Figure 10











Bonaventure              Expires January 7, 2016               [Page 13]

Internet-Draft             MPTCP Long Options                  July 2015


      +---------+--------+--------+
      | TCP hdr | DSS(S1)|  Opt x |
      | seq=1   | 2->1   | 4 bytes|
      | len=5   | len=4  |        |
      +---------+--------+--------+
                    ||
                    \/
      +---------+--------+--------+
      | TCP hdr | DSS(S1)|   Opt  |
      | seq=1   | 2->1   | 2 bytes|
      | len=3   | len=4  |        |
      +---------+--------+--------+

      +---------+--------+--------+
      | TCP hdr | DSS(S1)|   Opt  |
      | seq=3   | 2->1   | 2 bytes|
      | len=5   | len=4  |        |
      +---------+--------+--------+


                  Figure 10: Effect of segment splitting

   With such a middlebox that splits a segment and copies the DSS
   option, the receiver can recover the extended option once it has
   received the two segments.  The same applies for user data and is
   already supported by Multipath TCP implementations [IMC13a].

   The third use case is a middlebox that coalesces two segments.  We
   consider the case where a segment containing extended options is
   coalesced with a segment containing user data.  A similar reasoning
   applies for other types of segment.  This is illustrated in
   Figure 11.



















Bonaventure              Expires January 7, 2016               [Page 14]

Internet-Draft             MPTCP Long Options                  July 2015


    +---------+--------+-------------+
    | TCP hdr | DSS(S1)|   Options   |
    | seq=1   | 2->1   |    4 bytes  |
    | len=4   | len=4  |             |
    +---------+--------+-------------+

    +---------+--------+-------- --+
    | TCP hdr | DSS(S0)| User data |
    | seq=5   | 4->5   |  2 bytes  |
    | len=2   | len=2  |           |
    +---------+--------+-----------+
                  ||
                  \/  Coalescing middlebox

    +---------+--------+----------+------------+
    | TCP hdr | DSS(S1)|  Options |  User data |
    | seq=1   | 2->1   |  4 bytes |   2 bytes  |
    | len=6   | len=4  |          |            |
    +---------+--------+----------+------------+

                 or

    +---------+--------+----------+------------+
    | TCP hdr | DSS(S0)|  Options |  User data |
    | seq=1   | 4->5   |  4 bytes |   2 bytes  |
    | len=6   | len=2  |          |            |
    +---------+--------+----------+------------+



                  Figure 11: Effect of Segment Coalescing

   Multipath TCP implementations already support middleboxes that
   coalesce consecutive segments containing data as demonstrated in
   [IMC13a].

   There are two different possibilities depending on whether the first
   or the second DSS option is copied in the coalesced segment If the
   first DSS option is copied, then the receiver has a valid mapping for
   the extended TCP options and can decode them but no mapping for the
   user data.  The sender will timeout and retransmit a segment
   containing the user data with a valid mapping.  If the second DSS
   option is copied, then the receiver can process the user data but has
   to wait for a retransmission of the mapping that covers the extended
   TCP options.






Bonaventure              Expires January 7, 2016               [Page 15]

Internet-Draft             MPTCP Long Options                  July 2015


4.  Negotiating the extended DSS option

   The proposed extended DSS option should only be used between hosts
   that support the extension.  This should be negotiated during the
   three way handshake for the initial subflow.  There are two possible
   solutions for this negotiation :

   o  Redefine one of the unused bits (e.g.  'B') of the MP_CAPABLE
      option [RFC6824] to negotiate the utilisation of the extended DSS
      option

   o  Define a new version of the Multipath protocol [RFC6824]

   Given the impact of the change, it is probable safer to increment the
   protocol version number.

5.  Compatibility with the existing TCP options

   In this section, we discuss how the existing TCP options can be
   transported by using the control stream.

5.1.  End-of-Option List

   If used, this option, defined in [RFC0793] MUST appear as the last
   TCP option in each DSS-mapped payload that contains TCP options.

5.2.  Maximum Segment Size

   The MSS option, defined in [RFC0793] can only appear in SYN segments.
   It MUST never be sent inside a DSS-mapped payload.  If a host
   receives a DSS-mapped payload that contains this option, it MUST
   ignore the entire DSS-mapped payload.

5.3.  No-Operation

   This option, defined in [RFC0793] is often used to align TCP options
   to word boundaries.  Some middleboxes replace existing TCP options
   with this option [IMC11].  A host that sends TCP options inside a
   DSS-mapped payload MAY send one or more No-Operation options inside
   the DSS-mapped payload.

5.4.  SACK-Permitted

   This option, defined in [RFC2018], is used to negotiate the
   utilisation of the selective acknowledgements during the three way
   handshake.  It MUST thus not appear in any DSS-mapped payload.  If a
   host receives a DSS-mapped payload that contains this option, it MUST
   ignore the entire DSS-mapped payload.



Bonaventure              Expires January 7, 2016               [Page 16]

Internet-Draft             MPTCP Long Options                  July 2015


5.5.  SACK option

   This option, defined in [RFC2018], MAY either be sent as a regular
   TCP option or inside a DSS-mapped payload.  Placing the option in a
   DSS-mapped payload has two advantages.  First, the length of the SACK
   option is not anymore limited by the maximum length of the TCP
   header.  Second, this option will be delivered reliably to the
   destination.

5.6.  Timestamps

   This option, defined in [RFC1323] and revised in [RFC7323] SHOULD not
   appear in any DSS-mapped payload.  It does not benefit from the
   reliability provided by the DSS-mapped payload.

5.7.  TCP-TFO

   Two options are defined in [I-D.ietf-tcpm-fastopen] : Fast Open
   Cookie and Fast Open Cookie Request.  These two options can only be
   used inside SYN segments.  For this reason, they MUST never be sent
   inside a DSS-mapped payload.  If a host receives a DSS-mapped payload
   that contains one of these options, it MUST ignore the entire DSS-
   mapped payload.

5.8.  TCP-AO option

   This option, defined in [RFC5925], allows to authenticate the TCP
   segments exchanged between hosts.  Given the processing rules defined
   in [RFC5925], it seems difficult to place it as defined in [RFC5925]
   inside a DSS-mapped payload.  For this reason, a host MUST never send
   the TCP-AO option inside a DSS-mapped payload.

   It should be noted that a DSS option of length 20 bytes can be used
   inside a segment that is covered by a TCP-AO option of 20 bytes or
   less.

5.9.  TCP-User Timeout

   This option is defined in [RFC5482].  It MAY either be sent as a
   regular TCP option or inside a DSS-mapped payload.  Placing the
   option in a DSS-mapped payload provides a reliable delivery of the
   option for the applications requiring it.

5.10.  Multipath TCP options

   Several Multipath TCP options are defined in [RFC6824].  Some of them
   can benefit from the reliability and the unrestricted length of the
   DSS-mapped payload.



Bonaventure              Expires January 7, 2016               [Page 17]

Internet-Draft             MPTCP Long Options                  July 2015


   The MP_CAPABLE and MP_JOIN options can only appear in SYN segments.
   They MUST never be sent inside a DSS-mapped payload.  If a host
   receives a DSS-mapped payload that contains one of these options, it
   MUST reject the entire DSS-mapped payload.

   Similarly, a DSS option cannot appear inside a DSS-mapped payload.
   If a host receives a DSS-mapped payload that contains another DSS
   option, it MUST reject the entire DSS-mapped payload.

   The ADD_ADDR and REMOVE_ADDR can benefit from the reliability of
   being transported inside a DSS-mapped payload.  As discussed in
   [Cellnet12], the loss of such options can impact the performance of
   Multipath TCP in failover scenarios.  Another benefit of the DSS-
   mapped payload is that a multihomed host that has several IPv6
   addresses could advertise all its addresses by sending a single DSS-
   mapped segment.  The MP_PRIO option can also benefit from the added
   reliability of placing it inside a DSS-mapped payload.

   The MP_FAIL option is used when there are problems with middleboxes.
   In this case, placing it inside a DSS-mapped payload is unlikely to
   help.  For this reason, it MUST never appear inside a DSS-mapped
   payload.

   The MP_FASTCLOSE option is used to abruptly terminate an MPTCP
   connection.It can be transmitted as a DSS-mapped option.

6.  Security consideration

   The solution proposed in this document does not modify the security
   properties of Multipath TCP.  The security considerations listed in
   [RFC6824] [RFC6181] apply.

7.  Conclusion

   In this document, we have proposed a simple modification to the
   format of the DSS option in Multipath TCP to support the transport of
   long TCP options inside the TCP payload while leveraging the existing
   Multipath TCP mechanisms.

8.  Acknowledgements

   This work was partially supported by the FP7-Trilogy2 project.  We
   would like to thank Joe Touch and Bob Briscoe whose work on extending
   the TCP option space [I-D.briscoe-tcpm-inner-space]
   [I-D.ietf-tcpm-tcp-edo] has motivated this work.  This document also
   benefitted from comments and suggestions from Fabien Duchene,
   Christoph Paasch and Benjamin Hesmans.




Bonaventure              Expires January 7, 2016               [Page 18]

Internet-Draft             MPTCP Long Options                  July 2015


9.  Informative References

   [Cellnet12]
              Paasch, C., Detal, G., Duchene, F., Raiciu, C., and O.
              Bonaventure, "Exploring Mobile/WiFi Handover with
              Multipath TCP", ACM SIGCOMM workshop on Cellular Networks
              (Cellnet12) , 2012,
              <http://inl.info.ucl.ac.be/publications/
              exploring-mobilewifi-handover-multipath-tcp>.

   [HotMiddlebox13]
              Hesmans, B., Duchene, F., Paasch, C., Detal, G., and O.
              Bonaventure, "Are TCP Extensions Middlebox-proof?", CoNEXT
              workshop HotMiddlebox , December 2013,
              <http://inl.info.ucl.ac.be/publications/
              are-tcp-extensions-middlebox-proof>.

   [I-D.ananth-middisc-tcpopt]
              Knutsen, A., Ramaiah, A., and A. Ramasamy, "TCP option for
              transparent Middlebox negotiation", draft-ananth-middisc-
              tcpopt-02 (work in progress), February 2013.

   [I-D.briscoe-tcpm-inner-space]
              Briscoe, B., "Inner Space for TCP Options", draft-briscoe-
              tcpm-inner-space-01 (work in progress), October 2014.

   [I-D.ietf-tcpm-fastopen]
              Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
              Fast Open", draft-ietf-tcpm-fastopen-10 (work in
              progress), September 2014.

   [I-D.ietf-tcpm-tcp-edo]
              Touch, J. and W. Eddy, "TCP Extended Data Offset Option",
              draft-ietf-tcpm-tcp-edo-03 (work in progress), April 2015.

   [I-D.paasch-mptcp-control-stream]
              Paasch, C. and O. Bonaventure, "A generic control stream
              for Multipath TCP", draft-paasch-mptcp-control-stream-00
              (work in progress), February 2014.

   [IMC11]    Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A.,
              Handley, M., and H. Tokuda, "Is it still possible to
              extend TCP?", Proceedings of the 2011 ACM SIGCOMM
              conference on Internet measurement conference (IMC '11) ,
              2011, <http://doi.acm.org/10.1145/2068816.2068834>.






Bonaventure              Expires January 7, 2016               [Page 19]

Internet-Draft             MPTCP Long Options                  July 2015


   [IMC13a]   Detal, G., Hesmans, B., Bonaventure, O., Vanaubel, Y., and
              B. Donnet, "Revealing Middlebox Interference with
              Tracebox", Proceedings of the 2013 ACM SIGCOMM conference
              on Internet measurement conference , 2013,
              <http://inl.info.ucl.ac.be/publications/
              revealing-middlebox-interference-tracebox>.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

   [RFC1323]  Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
              for High Performance", RFC 1323, May 1992.

   [RFC2018]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
              Selective Acknowledgment Options", RFC 2018, October 1996.

   [RFC5482]  Eggert, L. and F. Gont, "TCP User Timeout Option", RFC
              5482, March 2009.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, June 2010.

   [RFC6181]  Bagnulo, M., "Threat Analysis for TCP Extensions for
              Multipath Operation with Multiple Addresses", RFC 6181,
              March 2011.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, January 2013.

   [RFC7323]  Borman, D., Braden, B., Jacobson, V., and R.
              Scheffenegger, "TCP Extensions for High Performance", RFC
              7323, September 2014.

Author's Address

   Olivier Bonaventure
   UCLouvain

   Email: Olivier.Bonaventure@uclouvain.be











Bonaventure              Expires January 7, 2016               [Page 20]