[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Network Working Group                                     Changqiao Xu
Internet Draft                                                   BUPT
Intended status: Experimental                               Hui Huang
Expires: December 2017                                           BUPT
                                                          Hongke Zhang
                                                                 BUPT
                                                        Chunshan Xiong
                                          Huawei Technologies Co., Ltd
                                                              Lei Zhu
                                          Huawei Technologies Co., Ltd
                                                         June 20, 2017

             Multipath Transmission Control Protocol (MPTCP)
                      Partial Reliability Extension
                       draft-xu-mptcp-prmp-04.txt


Status of this Memo

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

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html




Xu, et al            Expires December 20, 2017               [Page 1]


Internet-Draft   MPTCP Partial Reliability Extension         June 2017


   This Internet-Draft will expire on December 21, 2017.

Copyright Notice

   Copyright (c) 2017 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.

Abstract

   This memo presents an extension to the Multipath Transmission Control
   Protocol (MPTCP) that allows MPTCP endpoints in which case both
   sender side and receiver side support this function to provide
   partially reliable data transmission service to the upper layer
   applications. In order to achieve the above goal, this memo extents
   MPTCP by adding two new subtypes which are expressed as "PR_CAPABLE"
   and "ACK_NOTIFY" and the corresponding processes are also introduced.
   The extension can provide the backward-compatibility with MPTCP if
   the new features are not available.

   Table of Contents


   1. Introduction ................................................ 3
      1.1. Motivation ............................................. 3
      1.2. Overview of PR-MPTCP.................................... 3
   2. Conventions ................................................. 3
   3. New Options ................................................. 3
      3.1. PR_CAPABLE Option
.......................................4
      3.2. ACK_NOTIFY Option
.......................................5
   4. PR-MPTCP Workflow ........................................... 6
      4.1. Connection Initialization
...............................6
      4.2. Process of Forced Acknowledged Packets ..................7
         4.2.1.Sender Side Implementation ......................... 7
         4.2.2.Receiver Side Implementation ....................... 8
   5. Impact on Congestion Control Algorithm .......................8
   6. Security Considerations ......................................9



Xu, et al             Expires December 20, 2017               [Page 2]


Internet-Draft   MPTCP Partial Reliability Extension         June 2017


   7. IANA Considerations ......................................... 9
   8. References .................................................. 9
      8.1. Normative References.................................... 9
      8.2. Informative References
.................................10
   9. Acknowledgments .............................................10

1. Introduction

   PR-MPTCP is the extension of MPTCP which can provide partially
   reliable services when both sender side and receiver side support
   this function. PR-MPTCP introduces the advance confirmation
   mechanism to standard MPTCP which can abandon the transmission of
   invalid data and meet the requirements of real time transport
   services, such as streaming media.

1.1. Motivation

   As an extension of traditional TCP for multipath operation with
   multiple addresses, Multipath Transmission Control Protocol (MPTCP)
   provides a reliable and in-order delivery service to the upper layer
   applications. However, with the development of internet, more and
   more applications seek for the mechanisms which can transport data
   with different reliability level in different ways. This memo
   intends to fill the gap with the extension of MPTCP.

1.2. Overview of PR-MPTCP

   This demo mainly describes the following two changes to MPTCP to
   provide the partial reliable function:

   1. The negotiation of partial reliability function in the
      initialization phase.

   2. The maintaining of partial reliable processing, including sender
      side and receiver side cooperation.

2. Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

3. New Options

   Similar with the manner MPTCP enhances TCP functionality, PR-MPTCP
   extends MPTCP by utilizing the TCP Options field and by defining new



Xu, et al             Expires December 20, 2017               [Page 3]


Internet-Draft   MPTCP Partial Reliability Extension         June 2017


   options. Two new subtype MPTCP options are introduced, named
   "PR_CAPABLE" and "ACK_NOTIFY", which are described next.

3.1. PR_CAPABLE Option

   The communicating endpoints negotiate the availability of the
   partially reliable mechanism during connection establishment. The
   function will be used only if both communicating sides are partial
   reliability capable. In order to negotiate the availability of the
   partially reliable mechanism during connection establishment, we
   define a new subtype of MPTCP option named PR_CAPABLE. This subtype
   extends the MP_CAPABLE option fields described in MPTCP by appending
   partial reliability parameters setting information to the end of the
   MP_CAPABLE option data.

   The detailed format of PR_CAPABLE option is as follows:

                    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|Version|A|B|C|D|E|F|G|H|
   +---------------+---------------+-------+-------+---------------+
   |                 Option Sender's Key (64 bits)                 |
   |                                                               |
   +---------------------------------------------------------------+
   |                Option Receiver's Key (64 bits)                |
   |                   (if option Length == 24)                    |
   +-------------------------------+-------------------------------+
   |         Reserved          |P|T|           Threshold           |
   +---------------------------------------------------------------+

   The new fields include two flags (P and T) and Threshold, which will
   be described next. Naturally the value in the Length field of the
   PR-MPTCP header will also be larger with 4 Bytes than that in the
   similar MPTCP header.

     P: 1 bit

     This flag bit indicates whether the sender wishes to use the
   packet-based partial reliability transmission or not. By setting P
   to 1, the sender requests the receiver to enable packet-based
   partial reliability transmission. If P equals 0, the packet-based
   partial reliability transmission will not be used.

     T: 1 bit




Xu, et al             Expires December 20, 2017               [Page 4]


Internet-Draft   MPTCP Partial Reliability Extension         June 2017


     This flag bit indicates whether the sender wishes to use the time-
   based partial reliability transmission. By setting T to 1, the
   sender requests the receiver to enable time-based partial
   reliability transmission. If T equals 0, the time-based partial
   reliability transmission will not be used.

     Threshold: 16 bits

     The meaning of the value in this field depends on the value of flag
   P and T. If P flag is set to 1, the value in this field is used as
   the maximum number of transmission attempts for each packet. If T
   flag is set to 1, the value in this field is used as the maximum
   delay of transmission for each packet, expressed in milliseconds.

     In order to avoiding the conflict of flags P and T, PR-MPTCP
   specify that only one bit of these two flags can be set to 1 at the
   same time. When the receiver obtains a PR_CAPABLE option which set
   both of the flags P and T to 1 or 0, the receiver performs no action
   and classic MPTCP transmission takes place by default.

3.2. ACK_NOTIFY Option

   The detailed format of ACK_NOTIFY option is as follows:
                    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|       |Num of Subflows|
   +---------------+---------------+-------+-------+---------------+
   |                    Subflow 1 Advanced ACK                     |
   +---------------------------------------------------------------+
   |                    Subflow 2 Advanced ACK                     |
   +---------------------------------------------------------------+
   \                               .                               /
   /                               .                               \
   +---------------------------------------------------------------+
   |                    Subflow N Advanced ACK                     |
   +---------------+---------------+---------------+---------------+
   | Subflow 1 ID  | Subflow 2 ID  |      ...      | Subflow N ID  |
   +---------------------------------------------------------------+

   When the sender identifies a packet maybe useless through the rules
   (exceeding its maximum number of retransmission attempts or
   exceeding its delay limit as set by the Threshold), the packet is
   not transmitted anymore. The sender has to inform the receiver about
   the not-transmitted packet sequence number, so as it will not wait
   for its arrival anymore. This is performed by sending a forced


Xu, et al             Expires December 20, 2017               [Page 5]


Internet-Draft   MPTCP Partial Reliability Extension         June 2017


   acknowledgement with the next data packet with a new option
   ACK_NOTIFY in it. Upon receiving this information, the receiver
   updates its local ACK point and then sends a new ACK as response.
   When receiving this ACK packet indicating the new ACK point by
   passing the not-transmitted packet, the sender releases this packet
   from the sender buffer just like when it is received successfully.
   This process can involve more than one packet on multiple subflows.

   Num of Subflows: 8 bits

    This field indicates how many subflows need to send advanced ACK
   notifications. This field is designed for indexing purpose. For
   example, if the Num of Subflows field is set to 2, it means the
   following 8 bytes (two rows as shown in above figure) contain the
   information of two subflows (first 4 bytes for the first subflow and
   the second 4 bytes for the second subflow) specified with the
   Address ID appended at the end of the ACK_NOTIFY option.

   Subflow # Advanced ACK: 32 bits

     This field indicates the sequence number of the packet to be
   forced acknowledged in subflow #. If more than one data packets need
   to be forced acknowledged in the same subflow, only the largest
   sequence number will be indicated in the ACK_NOTIFY option.

   Subflow # ID: 8 bits

     The address ID is the destination to which the notification should
   be sent.

   If a single option can't contain all forward ACK information for all
   subflows due to the limitation of the TCP option size, the sender
   SHOULD wait for another chance to send these forward information.

4. PR-MPTCP Workflow

4.1. Connection Initialization

   The PR-MPTCP communication initiator sends PR_CAPABLE option instead
   of sending the MP_CAPABLE option, as in the classic MPTCP connection
   initialization case. If the other side is not partial reliability
   capable, but supports MPTCP, the connection initialization will
   follow the regular MPTCP connection establishment process. If the
   other side is not MPTCP capable, TCP connection establishment will
   be performed instead.




Xu, et al             Expires December 20, 2017               [Page 6]


Internet-Draft   MPTCP Partial Reliability Extension         June 2017


   At the beginning, the initiator SHOULD add the PR_CAPABLE option
   into the SYN request packet to declare that it is PR-MPTCP capable.

   Upon receipt of a SYN that contains PR_CAPABLE option, the receiver
   SHOULD send a SYN/ACK containing PR_CAPABLE, if it is PR-MPTCP
   capable; or ignore the PR_CAPABLE option in the SYN and continue to
   act as MPTCP does, if it is not PR-MPTCP capable but MPTCP capable.

   If a connection initiator which is PR-MPTCP capable received a
   SYN/ACK containing PR_CAPABLE option, the transmission will adopt
   the partially reliable approach. Otherwise, if the received SYN/ACK
   does not contain PR_CAPABLE option (maybe the other side is not PR-
   MPTCP capable or the PR_CAPABLE option is stripped off by the middle
   box) but a MP_CAPABLE option contained, the connection will fall
   back to MPTCP connection, or TCP connection will be used.

   The other process such as exchange of address information are the
   same with the operation mentioned in [RFC6824].

4.2. Process of Forced Acknowledged Packets

   In the implementation of partially reliable transmission, the sender
   gives up the retransmission of over-limited packets to ensure the
   requirements of some upper layer applications.

4.2.1. Sender Side Implementation

   Apart from the standard processing in MPTCP, in order to achieve the
   partial reliability goal, the following extra actions MUST be taken:

      1) The sender maintains a mandatory acknowledgment points
         (Advanced ACK Point) for each subflow and MUST update it when
         the judgment sub-processes determine to advance the cumulative
         ACK point, this means that all data with sequence numbers less
         than the Cumulative ACK Point is regarded as having been ACKed;

      2) When receiving a SACK, the sender side firstly processes the
         SACK as MPTCP does, namely updates the Cumulative ACK Point;

      3) Then the judgment sub-processes SHOULD compare the cumulative
         ACK with Advanced ACK Point. If Advanced ACK Point is less than
         the cumulative ACK, then update Advanced ACK Point to be equal
         to the cumulative ACK;

      4) After processing SACK, the sender SHOULD try to advance the
         Advanced ACK Point for each subflow, if Advanced ACK Point is



Xu, et al             Expires December 20, 2017               [Page 7]


Internet-Draft   MPTCP Partial Reliability Extension         June 2017


         greater than the cumulative ACK, the judgment sub-processes
         SHOULD inform the receiver of updating its local cumulative ACK
         Point by sending a packet with ACK_NOTIFY option;

      5) After sending a packet with ACK_NOTIFY option, the sender MUST
         be sure that at least a RTX timer is running, if the timer
         timeout occurs, the packet with the ACK_NOTIFY option will be
         retransmitted.

   The default policy to send ACK_NOTIFY option in this document is
   bundling the notification of each subflow in one TCP option space as
   long as the total size of the option would not exceed the limitation
   of the TCP option size, in addition, the total size of the packet
   SHOULD NOT exceed the MTU.

   Another situation that is worth highlighting is one of the subflows
   is broken during the transmission. In this case, the packets that
   have been sent on this subflow will be retransmitted on other normal
   ones according to existing MPTCP. In this situation, the sender
   SHOULD update the Advanced ACK of other subflows with the
   information contained in the broken subflows?Advanced ACK.

4.2.2. Receiver Side Implementation

   When receiving a packet with an ACK_NOTIFY option, the receiver
   compares the local Cumulative ACK Point with the notified ACK
   contained in ACK NOTIFY option for the corresponding subflow, and
   releases the forced acknowledged packets from the receiver buffer.

   When the forced acknowledged packets arrive at the receiver side,
   these packets SHOULD be treated as duplicate packets, and the
   receiver processes then as MPTCP does, (i.e. drop).

5. Impact on Congestion Control Algorithm

   When a packet is forcedly acknowledged, it SHOULD be treated as loss
   and trigger the congestion control algorithms. If more than one
   packets are forcedly acknowledged, the congestion window adjustment
   SHOULD be triggered only once in a short specified duration, such as
   a RTT.

6. Some Overhead Consideration

   In order to guarantee the normal work, PRMPTCP defines two flag bits
   and a Threshold parameter when initializing the connection. And it
   also introduces the ACK_NOTIFY option to the MPTCP. These new



Xu, et al             Expires December 20, 2017               [Page 8]


Internet-Draft   MPTCP Partial Reliability Extension         June 2017


   parameters and other judgment sub-processes are the overhead of
   PRMPTCP.

   However, when one or more over-limited packets are considered to be
   useless, the sender will put their information into the ACK_NOTIFY
   option and binding this option to the next packet. By adopting this
   forcedly acknowledged scheme, the sender can avoid retransmitting
   those useless packets, and improve the overall transmission
   efficiency. In a word, the overhead of PRMPTCP is reasonable and
   tolerable.

7. Security Considerations

   This memo develops no new security scheme for MPTCP. PR-MPTCP share
   the same security issues discussed in [RFC6824] with MPTCP.

8. IANA Considerations

  +-------+--------------+----------------------------+---------------+
  | Value |    Symbol    |            Name            |   Reference   |
  +-------+--------------+----------------------------+---------------+
  |  0xa  |  PR_CAPABLE  |      Multipath Partial     |      This     |
  |       |              |     Reliability Capable    |   document,   |
  |       |              |                            | Section 3.1   |
  |  0xb  |  ACK_NOTIFY  |       Acknowledgement      |      This     |
  |       |              |         Notification       |   document,   |
  |       |              |                            | Section 3.2   |
  +-------+--------------+----------------------------+---------------+
                      Table 1: MPTCP Option Subtypes

   The 4-bit MPTCP subtype sub-registry ("MPTCP Option Subtypes" under
   the "Transmission Control Protocol (TCP) Parameters" registry) was
   defined in [RFC6824]. This document defines two additional subtype
   (PR_MPCABLE and ACK_NOTIFY). The updates are listed in the above
   table.

9. References

9.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.







Xu, et al             Expires December 20, 2017               [Page 9]


Internet-Draft   MPTCP Partial Reliability Extension         June 2017


9.2. Informative References

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

10. Acknowledgments

   This Internet Draft is the result of a great deal of constructive
   discussion with several people, notably Man Tang, Jiuren Qin, and
   Peng Wang.

   This document was prepared using 2-Word-v2.0.template.dot.



































Xu, et al             Expires December 20, 2017              [Page 10]


Internet-Draft   MPTCP Partial Reliability Extension         June 2017


Authors' Addresses

   Changqiao Xu
   Beijing University of Posts and Telecommunications
   Institute of Network Technology, No. 10, Xitucheng Road,
   Haidian District, Beijing
   P.R. China

   Email: cqxu@bupt.edu.cn


   Hui Huang
   Beijing University of Posts and Telecommunications
   Institute of Network Technology, No. 10, Xitucheng Road,
   Haidian District, Beijing
   P.R. China

   Email: hh1126@bupt.edu.cn


   Hongke Zhang
   Beijing University of Posts and Telecommunications
   Institute of Network Technology, No. 10, Xitucheng Road,
   Haidian District, Beijing
   P.R. China

   Email: hkzhang@bupt.edu.cn


   Chunshan Xiong
   Huawei Technologies Co., Ltd
   Science and Technology Demonstration Garden, No. 156, Zhongguancun
   North Qing Road,
   Haidian District, Beijing
   P.R. China

   Email: sam.xiongchunshan@huawei.com

   Lei Zhu
   Huawei Technologies Co., Ltd
   Science and Technology Demonstration Garden, No. 156, Zhongguancun
   North Qing Road,
   Haidian District, Beijing
   P.R. China

   Email: lei.zhu@huawei.com



Xu, et al             Expires December 20, 2017              [Page 11]


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