idnits 2.17.1 draft-xu-mptcp-momp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 21, 2017) is 2500 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) == Outdated reference: A later version (-04) exists of draft-xu-mptcp-prmp-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Changqiao Xu 2 Internet Draft BUPT 3 Intended status: Experimental Jiuren Qin 4 Expires: December 2017 BUPT 5 Hongke Zhang 6 BUPT 7 Chunshan Xiong 8 Huawei Technologies Co., Ltd 9 Lei Zhu 10 Huawei Technologies Co., Ltd 11 June 21, 2017 13 A Message-Oriented Extension to 14 Multipath Transmission Control Protocol (MPTCP) 15 draft-xu-mptcp-momp-04.txt 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 This document may contain material from IETF Documents or IETF 23 Contributions published or made publicly available before November 24 10, 2008. The person(s) controlling the copyright in some of this 25 material may not have granted the IETF Trust the right to allow 26 modifications of such material outside the IETF Standards Process. 27 Without obtaining an adequate license from the person(s) controlling 28 the copyright in such materials, this document may not be modified 29 outside the IETF Standards Process, and derivative works of it may 30 not be created outside the IETF Standards Process, except to format 31 it for publication as an RFC or to translate it into languages other 32 than English. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other documents 41 at any time. It is inappropriate to use Internet-Drafts as 42 reference material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 51 This Internet-Draft will expire on December 3, 2016. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with 63 respect to this document. Code Components extracted from this 64 document must include Simplified BSD License text as described in 65 Section 4.e of the Trust Legal Provisions and are provided without 66 warranty as described in the Simplified BSD License. 68 Abstract 70 This memo specifies a message-oriented extension for Multipath TCP 71 (MPTCP) which aims to serve high-bandwidth and real-time 72 applications. By introducing a message mapping to MPTCP, Message- 73 Oriented MPTCP (MO-MPTCP) attaches some message features like 74 boundaries, priority and dependency to bytestream. With such 75 message-oriented information, MPTCP senders can avoid the waste of 76 transmission resources and improve the transmission efficiency. 78 Table of Contents 80 1. Introduction .............................................. 3 81 2. Conventions ............................................... 3 82 3. New Functionalities provided by MO-MPTCP .................. 3 83 4. Message Mapping ........................................... 4 84 5.1. Boundary-Based Packet Scheduling ..................... 6 85 5.2. Message-Oriented Transmission Optimization ........... 8 86 6. Interface Considerations .................................. 8 87 7. Security Considerations ................................... 9 88 8. IANA Considerations ....................................... 9 89 9. References ................................................ 9 90 9.1. Normative References ................................. 9 91 9.2. Informative References ............................... 9 92 10. Acknowledgments .......................................... 9 94 1. Introduction 96 With the increasingly demands for bandwidth-intensive services, e.g., 97 high-definition (HD) video, the streaming media data which is 98 massive, ordered and delay-sensitive is becoming the main traffic of 99 transport layer. Usually, the streaming media data is transferred by 100 UDP (User Datagram Protocol) which performs better than TCP 101 (Transmission Control Protocol) in improving throughput and reducing 102 latency. However, UDP does not have congestion control mechanism and 103 may result in network collapses. 105 MPTCP which has been standardized in [RFC6824] can greatly improve 106 the throughput of one association by concurrently transferring data 107 on several TCP subflows. Furthermore, the congestion control 108 mechanism provided by MPTCP can make it work without starving TCP. 109 With these advantages, MPTCP has the potential to serve the high- 110 bandwidth and real-time applications. 112 This memo introduces a Message-Oriented MPTCP (MO-MPTCP) which is a 113 suitable for streaming media transfer. MO-MPTCP specifies a message 114 mapping to record the information about message boundaries, priority 115 and dependency in the connection level. Based on this mapping, MO- 116 MPTCP offers Boundary-Based Packet Scheduling Mechanism which can 117 avoid unnecessary transmission and Message-Oriented Transmission 118 Optimization which can preferentially ensure the transmission of 119 important data. 121 2. Conventions 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC-2119 [RFC2119]. 127 3. New Functionalities provided by MO-MPTCP 129 Making the transmission of stream media as an example, the new 130 functionalities provided by Message-Oriented MPTCP are as follows: 132 o Boundary-Based Packet Scheduling 134 In the process of stream media transmission, application layer 135 usually delivers the data to the transport layer frame by frame. 136 Each frame can be seen as an individual message. However, in the 137 transport layer, limited by Maximum Segment Size (MSS) MPTCP tends 138 to segment the big messages and splice the small messages. And it 139 also splice the small messages into one data packets to reduce 140 transmission overhead. In general, all data are transferred in the 141 size of MSS. The segmentation and splicing operation of transport 142 layer leads to lose the original message boundaries. MO-MPTCP 143 provides a message mapping that can record the features of 144 application messages including boundaries, priority and dependency, 145 etc.. This mapping can help the sender to avoid unnecessary 146 transmissions. For example, stream media can usually tolerate the 147 loss of partial packets, which means the sender can give 148 as time out. This kind of partially reliable mechanism can refer to 149 [PRMP]. In this situation, if a packet which contains partial data 150 of a frame data is abandoned by the sender, as a result, this frame 151 cannot be decoded correctly at receiver side with the absence of 152 partial information. Current MPTCP which is based on bytestream 153 fails to perceive this situation, and still transmits the remaining 154 data of this frame which is a waste of transmission resources. In 155 Message-Oriented MPTCP, thanks to the recording of message boundary, 156 senders can abandon the remaining data simultaneously and avoid 157 unnecessary transmission. 159 o Message-Oriented Transmission Optimization 161 Traditional transmission ignores the priority and dependency of 162 messages and treats them equally as a bytestream, which makes the 163 transport blindly. Using an IPMH-like [IPMH] interface, MO-MPTCP can 164 get the priority of each message, and record the dependency between 165 them. For instance, in the standard MPEG coding, "I" frames are 166 essential to the recovery of the whole images and can be decoded 167 independently, so they have the "HIGH" priority and Dependency is 168 "NULL". Similarly, "P" frames which are decoded based on a previous 169 frame have "MEDIUM" priority and Dependency is "PRE". "B" frames 170 which are decoded based on both a previous frame and a latter frame 171 have "LOW" priority and Dependency is "PRE&LAR". Through some rules, 172 TCP packets can determine their own priorities from the messages 173 priorities. The reliability and timeliness of high-priority packets 174 will be guaranteed first when congestion occurs. When a duplicate 175 acknowledgement is received in the subflow level, the sender will 176 execute judgment for the missing packet upon their priorities and 177 duplicate ACK numbers. The send then will retransmit the packet if 178 needed. 180 4. Message Mapping 182 MO-MPTCP sets up a Message Mapping in the connection level. The 183 Message Mapping which is similar to the Data Sequence Mapping can 184 associates message features such as boundary and priority with 185 stream features such as DSN. This mapping which is the foundation of 186 MO-MPTCP can provide useful information for data scheduling in 187 transmission. 189 The Message Mapping consists of a lot of records, and each record 190 corresponds to an application message. Its structure sketch is show 191 in Figure 1. 193 +----------------------+ 194 | Message Mapping | 195 +----------------------+ 196 | Message Type 1 | 197 | DSN 1 | 198 | Length 1 | 199 | Priority 1 | 200 | Dependency 1 | 201 +----------------------+ 202 | Message Type 2 | 203 | DSN 2 | 204 | Length 2 | 205 | Priority 2 | 206 | Dependency 2 | 207 +----------------------+ 208 \ . / 209 / . \ 210 +----------------------+ 211 | Message Type N | 212 | DSN N | 213 | Length N | 214 | Priority N | 215 | Dependency N | 216 +----------------------+ 217 Figure 1 Message Mapping 219 o Message Type is used to distinguish the classes of message. It 220 can change its meaning depending on the application. For example, 221 in the streaming media transmission, it represents which kind of 222 frame this message is. 224 o DSN=Data Sequence Number. DSN shows the Data Sequence Number of 225 the first byte in an application message. 227 o Length shows the number of bytes that this message contains. This 228 parameter is usually used with DSN, and can identify the message 229 boundaries. 231 o Priority shows the importance of this message which usually be 232 divided into three priority HIGH, MEDIUM, LOW. 234 o Dependency shows the dependencies between adjacent messages. For 235 example, "NULL" means this message is independent; "PRE" means 236 this message depends on the previous message to be decoded; "LAT" 237 means this message depends on the later message to be decoded. 238 "PRE&LAT"means this message depends on both the previous and 239 later messages to be decoded. 241 The DSN and Length are used to identify the boundary of an 242 application message. And, the rest of the parameters which are 243 unique nature of messages are used to provide information for the 244 transmission optimization. 246 MO-MPTCP also provides rules for mapping establishment and removal 247 as follows: 249 o On receiving an application message, the sender SHOULD add a new 250 record containing all necessary parameters to the Message Mapping. 251 However these parameters may have different meaning for different 252 applications. 254 o When receiving an ACK in the MPTCP connection level, the sender 255 SHOULD judge whether need to remove some records from the Message 256 Mapping. Some messages are larger than the MSS, and may be partly 257 acknowledged. MO-MPTCP provisions that the record for a message 258 SHOULD be retained until all segments of this message are 259 acknowledged. 261 5. Operations of MO-MPTCP 263 5.1. Boundary-Based Packet Scheduling 265 Boundary-Based Packet Scheduling is used in the situations where the 266 applications can tolerate the loss of some packages to meet its 267 requirements for timeliness. [PRMP] proposed a partially reliable 268 extension to MPTCP called PR-MPTCP, which is designed to deal with 269 above situations. However, PR-MPTCP is based on the bytestream and 270 can perform better with the help of MO-MPTCP. For instance, if a TCP 271 packet containing partial data of a message is determined to be 272 discarded, MO-MPTCP can find and discard the remaining data that 273 belongs to or relies on this message. The detailed operating steps 274 are as follows: 276 a) MO-MPTCP offers a function to the sender. When determining to 277 discard a packet, the sender SHOULD call thi s function and send 278 the starting DSN and length of this packet as parameters to MO- 279 MPTCP. 281 b) Every time receiving calling from the sender, MO-MPTCP SHOULD 282 search the Message Mapping and record all the messages involved in 283 this packet. 285 c) Based on the messages selected by step b) MO-MPTCP then refers 286 to the Dependency recorded in Message Mapping and extracts some 287 other messages which rely on them to be decoded. 289 d) MO-MPTCP combines all the messages selected by step b) and c) 290 and connects them as one or more bigger messages according to 291 their DSNs and Length. Then the new boundaries of these messages 292 are obtained. 294 e) MO-MPTCP SHOULD return the starting DSN and Length of these new 295 messages. Then, the sender can continue its original operations 296 and discard the expanded messages according to the new boundaries. 298 Step b) can be classified into the following situations: 300 o Only one message is involved in the packet, which means this 301 packet is just a segment of the original message. In this case, 302 MO-MPTCP SHOULD search the Message Mapping and record this 303 message. 305 o Two or more messages are involved in the packet, which means this 306 packet contains data comes from different messages. In this case, 307 MO-MPTCP SHOULD search the Message Mapping and record all related 308 messages. 310 When executing step c) there are some notes: 312 o Before starting to search the Message Mapping, MO-MPTCP 313 preferably checks the priorities of the messages provided by step 314 b) and skips the messages which have LOW priority. Because 315 there is usually no message relies on them. 317 o Although the parameter of Dependency in Message Mapping only 318 reflects the relationship between adjacent messages, the lost a 319 message with HIGH priority can influence several messages with 320 lower priority. For example, if an "I" frame is decided to be 321 discarded, the following several frames will be influenced. So, 322 the implementation should pay attention to a chain reaction. 324 5.2. Message-Oriented Transmission Optimization 326 The Message Mapping records the priorities of the messages. Based on 327 these priorities, each TCP packet can determine its own priority. 328 The basic rules are as follows: 330 o If the data of a packet comes from only one message, the packet 331 priority is the same with the message priority. 333 o If the data of a packet comes from several messages, the packet 334 priority is the same with the highest message priority. 336 Following the above rules, senders can obtain the packet priority, 337 which is an important reference for the transmission optimization. 338 The main operations of the optimization are as follows: 340 a) Once the sender receives duplicate acknowledgement, it SHOULD 341 obtain the priority of those corresponding TCP packets by 342 searching the Message Mapping. 344 b) MO-MPTCP determines whether these packets need being 345 retransmitted immediately based on their priorities and the number 346 of duplicate acknowledgments. The packets with HIGH priority 347 will not be easily discarded;The packets with LOW priority will be 348 discarded first when congestion occurs. 350 c) If a TCP packet is judged to need retransmission by step b) the 351 senders SHOULD retransmit it immediately. Meanwhile, it SHOULD 352 also reset retransmission timer and clear the number of duplicate 353 acknowledgment. 355 d) If a TCP packet does not need to be transmitted after step b) 356 the senders can continue their original works until event in step 357 a) happens. 359 6. Implementation Consideration 361 In order to achieve message-oriented control and byte-oriented 362 transport, MO-MPTCP records the message information in the Message 363 Mapping. In the implementations of MO-MPTCP, hosts have to reserve 364 some memory for Message Mapping, which brings additional cost. 365 However, with the help of Message Mapping, more intelligent and 366 efficient transmission can be achieved. And the additional cost is 367 reasonable and tolerable. 369 7. Interface Considerations 371 MO-MPTCP offers an interface to the upper layer, through which the 372 applications can call MO-MPTCP and assign the parameters like 373 priority and dependency. The ways in which application obtain these 374 parameters can refer to [IPMH]. 376 8. Security Considerations 378 This memo develops no new security scheme for MPTCP. MO-MPTCP share 379 the same security issues discussed in [RFC6824] with MPTCP. 381 9. IANA Considerations 383 There is no IANA consideration for this memo. 385 10. References 387 10.1. Normative References 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, March 1997. 392 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 393 "TCP Extensions for Multipath Operation with Multiple 394 Addresses", RFC 6824, January 2013. 396 10.2. Informative References 398 [PRMP] Changqiao Xu, H. Huang, H. Zhang, C. Xiong, L. Zhu 399 "Multipath Transmission Control Protocol (MPTCP) Partial 400 Reliability Extension? draft-xu-mptcp-prmp-02, September 401 2015. 403 [IPMH] E, Gineste M, Dairaine L, et al. Building self-optimized 404 communication systems based on applicative cross-layer 405 information. Computer Standards & Interfaces, 2009, 406 31(2): 354-361. 408 11. Acknowledgments 410 This Internet Draft is the result of a great deal of constructive 411 discussion with several people, notably Man Tang, Hui Huang, and 412 Peng Wang. 414 This document was prepared using 2-Word-v2.0.template.dot. 416 Authors' Addresses 418 Changqiao Xu 419 Beijing University of Posts and Telecommunications 420 Institute of Network Technology, No. 10, Xitucheng Road, 421 Haidian District, Beijing 422 P.R. China 424 Email: cqxu@bupt.edu.cn 426 Jiuren Qin 427 Beijing University of Posts and Telecommunications 428 Institute of Network Technology, No. 10, Xitucheng Road, 429 Haidian District, Beijing 430 P.R. China 432 Email: jrqin@bupt.edu.cn 434 Hongke Zhang 435 Beijing University of Posts and Telecommunications 436 Institute of Network Technology, No. 10, Xitucheng Road, 437 Haidian District, Beijing 438 P.R. China 440 Email: hkzhang@bupt.edu.cn 442 Chunshan Xiong 443 Huawei Technologies Co., Ltd 444 Science and Technology Demonstration Garden, No. 156, Zhongguancun 445 North Qing Road, 446 Haidian District, Beijing 447 P.R. China 449 Email: sam.xiongchunshan@huawei.com 451 Lei Zhu 452 Huawei Technologies Co., Ltd 453 Science and Technology Demonstration Garden, No. 156, Zhongguancun 454 North Qing Road, 455 Haidian District, Beijing 456 P.R. China 458 Email: lei.zhu@huawei.com