Multipath Transmission Control Protocol (MPTCP) Partial Reliability Extension
draft-xu-mptcp-prmp-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Changqiao Xu , Hui Huang , Hongke Zhang , Chunshan Xiong , Lei Zhu | ||
| Last updated | 2015-04-03 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xu-mptcp-prmp-00
Network Working Group Changqiao Xu
Internet Draft BUPT
Intended status: Experimental Hui Huang
Expires: October 2015 BUPT
Hongke Zhang
BUPT
Chunshan Xiong
Huawei Technologies Co., Ltd
Lei Zhu
Huawei Technologies Co., Ltd
April 3, 2015
Multipath Transmission Control Protocol (MPTCP)
Partial Reliability Extension
draft-xu-mptcp-prmp-00.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 October 3, 2015 [Page 1]
Internet-Draft MPTCP Partial Reliability Extension April 2015
This Internet-Draft will expire on October 3, 2015.
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.
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 ..................................... 8
Xu, et al Expires October 3, 2015 [Page 2]
Internet-Draft MPTCP Partial Reliability Extension April 2015
7. IANA Considerations ......................................... 8
8. References .................................................. 9
8.1. Normative References ................................... 9
8.2. Informative References ................................. 9
9. Acknowledgments ............................................. 9
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. It can 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
options. Two new subtype MPTCP options are introduced, named
"PR_CAPABLE" and "ACK_NOTIFY", which are described next.
Xu, et al Expires October 3, 2015 [Page 3]
Internet-Draft MPTCP Partial Reliability Extension April 2015
3.1. PR_CAPABLE Option
Before transmitting any data, the communicating endpoints exchange
information to negotiate supported functions, including the partial
reliability function. This function can 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 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 receiver
performs no action and classic MPTCP transmission takes place by
default.
T: 1 bit
Xu, et al Expires October 3, 2015 [Page 4]
Internet-Draft MPTCP Partial Reliability Extension April 2015
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, classic MPTCP transmission
takes place by default.
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.
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 exceeding its maximum number of
retransmission attempts or its delay limit as set by the Threshold,
the packet is not transmitted anymore. The sender has to inform the
receiver of the not-transmitted packet's sequence number, so it will
not wait for its arrival anymore. This is performed by sending a
forced 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.
Xu, et al Expires October 3, 2015 [Page 5]
Internet-Draft MPTCP Partial Reliability Extension April 2015
Num of Subflows: 8 bits
This field indicates that how many subflows need to send advanced
ACK notifications.
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 this field.
Subflow # ID: 8 bits
The address ID of 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, you 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.
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
Xu, et al Expires October 3, 2015 [Page 6]
Internet-Draft MPTCP Partial Reliability Extension April 2015
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
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
Xu, et al Expires October 3, 2015 [Page 7]
Internet-Draft MPTCP Partial Reliability Extension April 2015
of the TCP option size, in addition, the total size of the packet
SHOULD NOT exceed the MTU.
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. Security Considerations
This memo develops no new security scheme for MPTCP. PR-MPTCP share
the same security issues discussed in [RFC6824] with MPTCP.
7. 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.
Xu, et al Expires October 3, 2015 [Page 8]
Internet-Draft MPTCP Partial Reliability Extension April 2015
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.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.
9. 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 October 3, 2015 [Page 9]
Internet-Draft MPTCP Partial Reliability Extension April 2015
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
Xu, et al Expires October 3, 2015 [Page 10]
Internet-Draft MPTCP Partial Reliability Extension April 2015
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 October 3, 2015 [Page 11]