Skip to main content

A Message-Oriented Extension to Multipath Transmission Control Protocol (MPTCP)
draft-xu-mptcp-momp-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 , Jiuren Qin , Hongke Zhang , Chunshan Xiong , Lei Zhu
Last updated 2015-06-05
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-momp-00
Network Working Group                                     Changqiao Xu 
Internet Draft                                                    BUPT 
Intended status: Experimental                              Jiuren Qin 
Expires: December 2015                                            BUPT 
                                                          Hongke Zhang 
                                                                  BUPT 
                                                        Chunshan Xiong 
                                          Huawei Technologies Co., Ltd 
                                                               Lei Zhu 
                                          Huawei Technologies Co., Ltd 
                                                          June 5, 2015 
     
                                          
                      A Message-Oriented Extension to  
              Multipath Transmission Control Protocol (MPTCP)  
                        draft-xu-mptcp-momp-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 

    

     

     
     
Xu, et al             Expires December 5, 2015                [Page 1] 
 

Internet-Draft          Message-Oriented MPTCP               June 2015 

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

   This Internet-Draft will expire on December 5, 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 specifies a message-oriented extension for Multipath TCP 
   (MPTCP) which aims to serve high-bandwidth and real-time 
   applications. By introducing a message mapping to MPTCP, Message-
   Oriented MPTCP (MO-MPTCP) attaches some message features like 
   boundaries, priority and dependency to bytestream. With such 
   information, MPTCP senders can optimize their transmission. 

Table of Contents 

   1. Introduction .................................................3 
   2. Conventions ..................................................3 
   3. New Functionalities provided by MO-MPTCP .....................3 
   4. Message Mapping ..............................................4 

  5. Operations of MO-MPTCP........................................6 
      5.1. Boundary-Based Packet Scheduling ........................6 
      5.2. Message-Oriented Transmission Optimization ..............8 
   6. Interface Considerations......................................8 
   7. Security Considerations.......................................8 
   8. IANA Considerations ..........................................9 
   9. References ...................................................9 
      9.1. Normative References.....................................9 
      9.2. Informative References ..................................9 
   10. Acknowledgments .............................................9 

 
 
Xu, et al             Expires December 5, 2015                [Page 2] 

Internet-Draft          Message-Oriented MPTCP               June 2015 
        

1. Introduction 

   With the increasingly demands for bandwidth-intensive services, e.g., 
   high-definition (HD) video, the streaming media data which is 
   massive and delay-sensitive is becoming the main traffic of the 
   network. MPTCP which has been standardized in [RFC6824] greatly 
   improves the throughput of one association by concurrently 
   transferring data on several TCP subflows. Furthermore, the 
   congestion control mechanism provided by MPTCP can enhance its 
   friendliness to other TCP flows. With these advantages, MPTCP has 
   the potential to serve the high-bandwidth and real-time applications. 
   However, as an extension to TCP, MPTCP still has some drawbacks. 
   Notable example is that MPTCP is a bytestream-oriented protocol. The 
   bytestream ignores the boundaries and differences among application 
   messages, which usually makes the transmission blind and inefficient. 

   This memo introduces a Message-Oriented MPTCP that allows managing 
   the bytestream in the message ways. MO-MPTCP specifies a message 
   mapping to record the information about message boundaries, priority 

  and dependency in the connection level. Based on this mapping, MO-
   MPTCP offers Boundary-Based Packet Scheduling Mechanism which can 
   avoid unnecessary transmission and Message-Oriented Transmission 
   Optimization which can preferentially ensure the transmission of 
   important data.  

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 Functionalities provided by MO-MPTCP 

   Making the transmission of stream media as an example, the new 
   functionalities provided by Message-Oriented MPTCP are as follows: 

   o Boundary-Based Packet Scheduling 

   In the process of stream media transmission, application layer 
   usually delivers the data to the transport layer frame by frame. 
   Each frame can be seen as an individual message. However, in the 
   transport layer, limited by Maximum Segment Size (MSS) MPTCP tends 
   to segment the big messages and transfer them in TCP packets, which 
   leads to lose the original message boundaries. MO-MPTCP provides a 
   message mapping that can record the features of application messages 
   including boundaries, priority and dependency, etc. This mapping can 
   help the sender to avoid unnecessary transmissions. For example, 
 
 
Xu, et al             Expires December 5, 2015                [Page 3] 

Internet-Draft          Message-Oriented MPTCP               June 2015 

   stream media can usually tolerate the loss of partial packets, which 
   means the sender can give transmission up and notify the receiver 
   when a packet is considered as time out. This kind of partially 
   reliable mechanism can refer to [PRMP]. In this situation, if a 
   packet which contains partial data of a frame is abandoned by the 
   sender, as a result, this frame cannot be decoded correctly at 
   receiver side with the absence of partial information. Current MPTCP 

  which is based on bytestream fails to perceive this situation, and 
   still transmits the remaining data of this frame which is a waste of 
   transmission resources. In Message-Oriented MPTCP, thanks to the 
   recording of message boundary, senders can abandon the remaining 
   data simultaneously and avoid unnecessary transmission. 

   o Message-Oriented Transmission Optimization 

   Traditional transmission ignores the priority and dependency of 
   messages and treats them equally as a bytestream, which makes the 
   transport blindly. Using an IPMH-like [IPMH] interface, MO-MPTCP can 
   get the priority of each message, and record the dependency between 
   them. For instance, in the standard MPEG coding, "I" frames are 
   essential to the recovery of the whole images and can be decoded 
   independently, so they have the "HIGH" priority and Dependency is 
   "NULL". Similarly, "P" frames which are decoded based on a previous 
   frame have "MEDIUM" priority and Dependency is "PRE"; "B" frames 
   which are decoded based on both a previous frame and a latter frame 
   have "LOW" priority and Dependency is "PRE&LAT". Through some rules, 
   TCP packets can determine their own priorities from the messages 
   priorities. The reliability and timeliness of high-priority packets 
   will be guaranteed first when congestion occurs. When a duplicate 
   acknowledgement is received in the subflow level, the sender will 
   execute judgment for the missing packet upon their priorities and 
   duplicate ACK numbers. The sender then will retransmit the packet if 
   needed. 

4. Message Mapping 

   MO-MPTCP sets up a Message Mapping in the connection level. The 
   Message Mapping which is similar to the Data Sequence Mapping can 
   associates message features such as boundary and priority with 
   stream features such as DSN. This mapping which is the foundation of 
   MO-MPTCP can provide useful information for data scheduling in 
   transmission. 

   The Message Mapping consists of a lot of records, and each record 
   corresponds to an application message. Its structure sketch is show 
   in Figure 1.  

 
 
Xu, et al             Expires December 5, 2015                [Page 4] 


Internet-Draft          Message-Oriented MPTCP               June 2015 
        

                         +----------------------+ 
                         |   Message Mapping    | 
                         +----------------------+ 
                         |    Message Type 1    | 
                         |        DSN 1         | 
                         |       Length 1       | 
                         |      Priority 1      | 
                         |    Dependency 1      | 
                         +----------------------+ 
                         |    Message Type 2    | 
                         |        DSN 2         | 
                         |       Length 2       | 
                         |      Priority 2      | 
                         |    Dependency 2      | 
                         +----------------------+ 
                         \          .           / 
                         /          .           \ 
                         +----------------------+ 
                         |    Message Type N    | 
                         |        DSN N         | 
                         |       Length N       | 
                         |      Priority N      | 
                         |    Dependency N      | 
                         +----------------------+ 
                         Figure 1 Message Mapping 

   o Message Type is used to distinguish the classes of message. It 
      can change its meaning depending on the application. For example, 
      in the streaming media transmission, it represents which kind of 
      frame this message is. 

   o DSN=Data Sequence Number. DSN shows the starting number of this 
      message in the data level. 

   o Length shows the number of bytes that this message contains. 

   o Priority shows the importance of this message which usually be 
      divided into three priority: HIGH, MEDIUM and LOW. 

 
 
Xu, et al             Expires December 5, 2015                [Page 5] 


Internet-Draft          Message-Oriented MPTCP               June 2015 

   o Dependency shows the dependencies between adjacent messages. For 
      example, "NULL" means this message is independent; "PRE" means 
      this message depends on the previous message to be decoded; "LAT" 
      means this message depends on the later message to be decoded. 
      "PRE&LAT" means this message depends on both the previous and 
      later messages to be decoded. 

   The DSN and Length are used to identify the boundary of an 
   application message. And the rest of the parameters which are unique 
   nature of messages are used to provide information for the 
   transmission optimization. 

   MO-MPTCP also provides rules for mapping establishment and removal 
   as follows: 

   o When receiving an application message, the sender SHOULD add a 
      new record containing all necessary parameters to the Message 
      Mapping. However these parameters may have different meaning for 
      different applications. 

   o A message which is larger than the MSS will be segmented in the 
      transport layer. The record for this message in the Message 
      Mapping SHOULD be retained until all segments of this message are 
      acknowledged. 

5. Operations of MO-MPTCP 

5.1. Boundary-Based Packet Scheduling 

   Boundary-Based Packet Scheduling is used in the situations where the 
   applications can tolerate the loss of some packages to meet its 
   requirements for timeliness. [PRMP] proposed a partially reliable 
   extension to MPTCP called PR-MPTCP, which is designed to deal with 
   above situations. However, PR-MPTCP is based on the bytestream and 
   can perform better with the help of MO-MPTCP. For instance, if a 
   packet containing partial data of a message is determined to be 
   discarded, MO-MPTCP can find and discard the remaining data that 
   belongs to or relies on this message. The detailed operating steps 
   are as follows: 

   a) MO-MPTCP offers a function to the sender. When determining to 
      discard a packet, the sender SHOULD call this function and send 
      the starting DSN and length of this packet as parameters to MO-
      MPTCP. 

 
     
Xu, et al             Expires December 5, 2015                [Page 6] 


Internet-Draft          Message-Oriented MPTCP               June 2015 

   b) Every time receiving calling from the sender, MO-MPTCP SHOULD 
      search the Message Mapping and record all the messages involved in 
      this packet. 

   c) Based on the messages selected by step "b", MO-MPTCP then refers 
      to the Dependency recorded in Message Mapping and extracts some 
      other messages which rely on them to be decoded. 

   d) MO-MPTCP combines all the messages selected by step "b" and "c", 
      and connects them as one or more bigger messages according to 
      their DSNs and Length. Then the new boundaries of these messages 
      are obtained. 

   e) MO-MPTCP SHOULD return the starting DSN and Length of these new 
      messages. Then, the sender can continue its original operations 
      and discard the expanded messages according to the new boundaries. 

    Step "b" can be classified into the following situations: 

   o Only one message is involved in the packet, which means this 
      packet is just a segment of the original message. In this case, 
      MO-MPTCP SHOULD search the Message Mapping and record this 
      message. 

   o Two or more messages are involved in the packet, which means this 
      packet contains data comes from different messages. In this case, 
      MO-MPTCP SHOULD search the Message Mapping and record all related 
      messages. 

  When executing step "c", there are some notes: 

   o Before starting to search the Message Mapping, MO-MPTCP 
      preferably checks the priorities of the messages provided by step 
      "b", and skips the messages which have LOW priority. Because 
      there is usually no message relies on them. 

   o Although the parameter of Dependency in Message Mapping only 
      reflects the relationship between adjacent messages, the lost a 
      message with HIGH priority can influence several messages with 
      lower priority. For example, if an "I" frame is decided to be 
      discarded, the following several frames will be influenced. So, 
      the implementation should pay attention to a chain reaction. 

 
 
Xu, et al             Expires December 5, 2015                [Page 7] 


Internet-Draft          Message-Oriented MPTCP               June 2015 
        

5.2. Message-Oriented Transmission Optimization 

   The Message Mapping records the priorities of the messages. Based on 
   these priorities, each TCP packet can determine its own priority. 
   The basic rules are as follows: 

   o If the data of a packet comes from only one message, the packet 
      priority is the same with the message priority. 

   o If the data of a packet comes from several messages, the packet 
      priority is the same with the highest message priority. 

   Following the above rules, senders can obtain the packet priority, 
   which is an important reference for the transmission optimization. 
   The main operations of the optimization are as follows: 

   a) Once the sender receives duplicate acknowledgement, it SHOULD 
      obtain the priority of those corresponding TCP packets by 
      searching the Message Mapping. 

   b) MO-MPTCP determines whether these packets need being 
      retransmitted immediately based on their priorities and the number 
      of duplicate acknowledgments. The higher the priority is and the 
      more duplicate acknowledgments sender receives, the more easily 
      immediate retransmission is triggered. 

   c) If a TCP packet is judged to need retransmission by step "b", the 
      senders SHOULD retransmit it immediately. Meanwhile, it SHOULD 
      also reset retransmission timer and clear the number of duplicate 
      acknowledgment. 

   d) If a TCP packet does not need to be transmitted after step "b", 
      the senders can continue their original works until event in step 
      "a" happens. 

6. Interface Considerations 

   MO-MPTCP offers an interface to the upper layer, through which the 
   applications can call MO-MPTCP and assign the parameters like 
   priority and dependency. The ways in which application obtain these 
   parameters can refer to [IPMH]. 

7. Security Considerations 

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

 
 
Xu, et al             Expires December 5, 2015                [Page 8] 


Internet-Draft          Message-Oriented MPTCP               June 2015 

8. IANA Considerations 

   There is no IANA consideration for this memo. 

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. 

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

9.2. Informative References 

   [PRMP]    Xu, C., Huang, H., Zhang, H., Xiong, C., and L. Zhu, 
             "Multipath Transmission Control Protocol (MPTCP) Partial 
             Reliability Extension", draft-xu-mptcp-prmp-00. 

   [IPMH]    Exposito, E., Gineste, M., Dairaine, L., and C. Chassot, 
             "Building self-optimized communication systems based on 
             applicative cross-layer information", Computer Standards & 
             Interfaces, 31(2): 354-361, Feb. 2009. 

10. Acknowledgments 

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

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

 
 
Xu, et al             Expires December 5, 2015                [Page 9] 


Internet-Draft          Message-Oriented MPTCP               June 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 

   Jiuren Qin 
   Beijing University of Posts and Telecommunications 
   Institute of Network Technology, No. 10, Xitucheng Road, 
   Haidian District, Beijing 
   P.R. China 
  
   Email: jrqin@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 5, 2015               [Page 10]