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]