idnits 2.17.1 draft-xu-mptcp-momp-03.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 (December 23, 2016) is 2678 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: June 2017 BUPT 5 Hongke Zhang 6 BUPT 7 Chunshan Xiong 8 Huawei Technologies Co., Ltd 9 Lei Zhu 10 Huawei Technologies Co., Ltd 11 December 23, 2016 13 A Message-Oriented Extension to 14 Multipath Transmission Control Protocol (MPTCP) 15 draft-xu-mptcp-momp-03.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 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on December 3, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with 60 respect to this document. Code Components extracted from this 61 document must include Simplified BSD License text as described in 62 Section 4.e of the Trust Legal Provisions and are provided without 63 warranty as described in the Simplified BSD License. 65 Abstract 67 This memo specifies a message-oriented extension for Multipath TCP 68 (MPTCP) which aims to serve high-bandwidth and real-time 69 applications. By introducing a message mapping to MPTCP, Message- 70 Oriented MPTCP (MO-MPTCP) attaches some message features like 71 boundaries, priority and dependency to bytestream. With such 72 message-oriented information, MPTCP senders can optimize their 73 transfers. 75 Table of Contents 77 1. Introduction .............................................. 3 78 2. Conventions ............................................... 3 79 3. New Functionalities provided by MO-MPTCP .................. 3 80 4. Message Mapping ........................................... 4 81 5.1. Boundary-Based Packet Scheduling ..................... 6 82 5.2. Message-Oriented Transmission Optimization ........... 8 83 6. Interface Considerations .................................. 8 84 7. Security Considerations ................................... 9 85 8. IANA Considerations ....................................... 9 86 9. References ................................................ 9 87 9.1. Normative References ................................. 9 88 9.2. Informative References ............................... 9 89 10. Acknowledgments .......................................... 9 91 1. Introduction 93 With the increasingly demands for bandwidth-intensive services, e.g., 94 high-definition (HD) video, the streaming media data which is 95 massive, ordered and delay-sensitive is becoming the main traffic of 96 transport layer. Usually, the streaming media data is transferred by 97 UDP (User Datagram Protocol) which performs better than TCP 98 (Transmission Control Protocol) in improving throughput and reducing 99 latency. However, UDP does not have congestion control mechanism and 100 may result in network collapses. 102 MPTCP which has been standardized in [RFC6824] can greatly improve 103 the throughput of one association by concurrently transferring data 104 on several TCP subflows. Furthermore, the congestion control 105 mechanism provided by MPTCP can make it work without starving TCP. 106 With these advantages, MPTCP has the potential to serve the high- 107 bandwidth and real-time applications. 109 This memo introduces a Message-Oriented MPTCP (MO-MPTCP) which is a 110 suitable for streaming media transfer. MO-MPTCP specifies a message 111 mapping to record the information about message boundaries, priority 112 and dependency in the connection level. Based on this mapping, MO- 113 MPTCP offers Boundary-Based Packet Scheduling Mechanism which can 114 avoid unnecessary transmission and Message-Oriented Transmission 115 Optimization which can preferentially ensure the transmission of 116 important data. 118 2. Conventions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC-2119 [RFC2119]. 124 3. New Functionalities provided by MO-MPTCP 126 Making the transmission of stream media as an example, the new 127 functionalities provided by Message-Oriented MPTCP are as follows: 129 o Boundary-Based Packet Scheduling 131 In the process of stream media transmission, application layer 132 usually delivers the data to the transport layer frame by frame. 133 Each frame can be seen as an individual message. However, in the 134 transport layer, limited by Maximum Segment Size (MSS) MPTCP tends 135 to segment the big messages and splice the small messages. Then, all 136 data are transferred in the size of MSS. The segmentation and 137 splicing operation of transport layer leads to lose the original 138 message boundaries. MO-MPTCP provides a message mapping that can 139 record the features of application messages including boundaries, 140 priority and dependency, etc.. This mapping can help the sender to 141 avoid unnecessary transmissions. For example, stream media can 142 usually tolerate the loss of partial packets, which means the sender 143 can give transmission up and notify the receiver when a packet is 144 can refer to [PRMP]. In this situation, if a packet which contains 145 partial data of a frame data is abandoned by the sender, as a result, 146 this frame cannot be decoded correctly at receiver side with the 147 absence of partial information. Current MPTCP which is based on 148 bytestream fails to perceive this situation, and still transmits the 149 remaining data of this frame which is a waste of transmission 150 resources. In Message-Oriented MPTCP, thanks to the recording of 151 message boundary, senders can abandon the remaining data 152 simultaneously and avoid unnecessary transmission. 154 o Message-Oriented Transmission Optimization 156 Traditional transmission ignores the priority and dependency of 157 messages and treats them equally as a bytestream, which makes the 158 transport blindly. Using an IPMH-like [IPMH] interface, MO-MPTCP can 159 get the priority of each message, and record the dependency between 160 them. For instance, in the standard MPEG coding, "I" frames are 161 essential to the recovery of the whole images and can be decoded 162 independently, so they have the "HIGH" priority and Dependency is 163 "NULL". Similarly, "P" frames which are decoded based on a previous 164 frame have "MEDIUM" priority and Dependency is "PRE". "B" frames 165 which are decoded based on both a previous frame and a latter frame 166 have "LOW" priority and Dependency is "PRE&LAR". Through some rules, 167 TCP packets can determine their own priorities from the messages 168 priorities. The reliability and timeliness of high-priority packets 169 will be guaranteed first when congestion occurs. When a duplicate 170 acknowledgement is received in the subflow level, the sender will 171 execute judgment for the missing packet upon their priorities and 172 duplicate ACK numbers. The send then will retransmit the packet if 173 needed. 175 4. Message Mapping 177 MO-MPTCP sets up a Message Mapping in the connection level. The 178 Message Mapping which is similar to the Data Sequence Mapping can 179 associates message features such as boundary and priority with 180 stream features such as DSN. This mapping which is the foundation of 181 MO-MPTCP can provide useful information for data scheduling in 182 transmission. 184 The Message Mapping consists of a lot of records, and each record 185 corresponds to an application message. Its structure sketch is show 186 in Figure 1. 188 +----------------------+ 189 | Message Mapping | 190 +----------------------+ 191 | Message Type 1 | 192 | DSN 1 | 193 | Length 1 | 194 | Priority 1 | 195 | Dependency 1 | 196 +----------------------+ 197 | Message Type 2 | 198 | DSN 2 | 199 | Length 2 | 200 | Priority 2 | 201 | Dependency 2 | 202 +----------------------+ 203 \ . / 204 / . \ 205 +----------------------+ 206 | Message Type N | 207 | DSN N | 208 | Length N | 209 | Priority N | 210 | Dependency N | 211 +----------------------+ 212 Figure 1 Message Mapping 214 o Message Type is used to distinguish the classes of message. It 215 can change its meaning depending on the application. For example, 216 in the streaming media transmission, it represents which kind of 217 frame this message is. 219 o DSN=Data Sequence Number. DSN shows the Data Sequence Number of 220 the first byte in an application message. 222 o Length shows the number of bytes that this message contains. This 223 parameter is usually used with DSN, and can identify the message 224 boundaries. 226 o Priority shows the importance of this message which usually be 227 divided into three priority HIGH, MEDIUM, LOW. 229 o Dependency shows the dependencies between adjacent messages. For 230 example, "NULL" means this message is independent; "PRE" means 231 this message depends on the previous message to be decoded; "LAT" 232 means this message depends on the later message to be decoded. 233 "PRE&LAT"means this message depends on both the previous and 234 later messages to be decoded. 236 The DSN and Length are used to identify the boundary of an 237 application message. And, the rest of the parameters which are 238 unique nature of messages are used to provide information for the 239 transmission optimization. 241 MO-MPTCP also provides rules for mapping establishment and removal 242 as follows: 244 o On receiving an application message, the sender SHOULD add a new 245 record containing all necessary parameters to the Message Mapping. 246 However these parameters may have different meaning for different 247 applications. 249 o When receiving an ACK in the MPTCP connection level, the sender 250 SHOULD judge whether need to remove some records from the Message 251 Mapping. Some messages are larger than the MSS, and may be partly 252 acknowledged. MO-MPTCP provisions that the record for a message 253 SHOULD be retained until all segments of this message are 254 acknowledged. 256 5. Operations of MO-MPTCP 258 5.1. Boundary-Based Packet Scheduling 260 Boundary-Based Packet Scheduling is used in the situations where the 261 applications can tolerate the loss of some packages to meet its 262 requirements for timeliness. [PRMP] proposed a partially reliable 263 extension to MPTCP called PR-MPTCP, which is designed to deal with 264 above situations. However, PR-MPTCP is based on the bytestream and 265 can perform better with the help of MO-MPTCP. For instance, if a TCP 266 packet containing partial data of a message is determined to be 267 discarded, MO-MPTCP can find and discard the remaining data that 268 belongs to or relies on this message. The detailed operating steps 269 are as follows: 271 a) MO-MPTCP offers a function to the sender. When determining to 272 discard a packet, the sender SHOULD call thi s function and send 273 the starting DSN and length of this packet as parameters to MO- 274 MPTCP. 276 b) Every time receiving calling from the sender, MO-MPTCP SHOULD 277 search the Message Mapping and record all the messages involved in 278 this packet. 280 c) Based on the messages selected by step b) MO-MPTCP then refers 281 to the Dependency recorded in Message Mapping and extracts some 282 other messages which rely on them to be decoded. 284 d) MO-MPTCP combines all the messages selected by step b) and c) 285 and connects them as one or more bigger messages according to 286 their DSNs and Length. Then the new boundaries of these messages 287 are obtained. 289 e) MO-MPTCP SHOULD return the starting DSN and Length of these new 290 messages. Then, the sender can continue its original operations 291 and discard the expanded messages according to the new boundaries. 293 Step b) can be classified into the following situations: 295 o Only one message is involved in the packet, which means this 296 packet is just a segment of the original message. In this case, 297 MO-MPTCP SHOULD search the Message Mapping and record this 298 message. 300 o Two or more messages are involved in the packet, which means this 301 packet contains data comes from different messages. In this case, 302 MO-MPTCP SHOULD search the Message Mapping and record all related 303 messages. 305 When executing step c) there are some notes: 307 o Before starting to search the Message Mapping, MO-MPTCP 308 preferably checks the priorities of the messages provided by step 309 b) and skips the messages which have LOW priority. Because 310 there is usually no message relies on them. 312 o Although the parameter of Dependency in Message Mapping only 313 reflects the relationship between adjacent messages, the lost a 314 message with HIGH priority can influence several messages with 315 lower priority. For example, if an "I" frame is decided to be 316 discarded, the following several frames will be influenced. So, 317 the implementation should pay attention to a chain reaction. 319 5.2. Message-Oriented Transmission Optimization 321 The Message Mapping records the priorities of the messages. Based on 322 these priorities, each TCP packet can determine its own priority. 323 The basic rules are as follows: 325 o If the data of a packet comes from only one message, the packet 326 priority is the same with the message priority. 328 o If the data of a packet comes from several messages, the packet 329 priority is the same with the highest message priority. 331 Following the above rules, senders can obtain the packet priority, 332 which is an important reference for the transmission optimization. 333 The main operations of the optimization are as follows: 335 a) Once the sender receives duplicate acknowledgement, it SHOULD 336 obtain the priority of those corresponding TCP packets by 337 searching the Message Mapping. 339 b) MO-MPTCP determines whether these packets need being 340 retransmitted immediately based on their priorities and the number 341 of duplicate acknowledgments. The packets with HIGH priority 342 will not be easily discarded;The packets with LOW priority will be 343 discarded first when congestion occurs. 345 c) If a TCP packet is judged to need retransmission by step b) the 346 senders SHOULD retransmit it immediately. Meanwhile, it SHOULD 347 also reset retransmission timer and clear the number of duplicate 348 acknowledgment. 350 d) If a TCP packet does not need to be transmitted after step b) 351 the senders can continue their original works until event in step 352 a) happens. 354 6. Implementation Consideration 356 In order to achieve message-oriented control and byte-oriented 357 transport, MO-MPTCP records the message information in the Message 358 Mapping. In the implementations of MO-MPTCP, hosts have to reserve 359 some memory for Message Mapping, which brings additional cost. 360 However, with the help of Message Mapping, more intelligent and 361 efficient transmission can be achieved. And the additional cost is 362 reasonable and tolerable. 364 7. Interface Considerations 366 MO-MPTCP offers an interface to the upper layer, through which the 367 applications can call MO-MPTCP and assign the parameters like 368 priority and dependency. The ways in which application obtain these 369 parameters can refer to [IPMH]. 371 8. Security Considerations 373 This memo develops no new security scheme for MPTCP. MO-MPTCP share 374 the same security issues discussed in [RFC6824] with MPTCP. 376 9. IANA Considerations 378 There is no IANA consideration for this memo. 380 10. References 382 10.1. Normative References 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, March 1997. 387 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 388 "TCP Extensions for Multipath Operation with Multiple 389 Addresses", RFC 6824, January 2013. 391 10.2. Informative References 393 [PRMP] Changqiao Xu, H. Huang, H. Zhang, C. Xiong, L. Zhu 394 "Multipath Transmission Control Protocol (MPTCP) Partial 395 Reliability Extension? draft-xu-mptcp-prmp-02, September 396 2015. 398 [IPMH] E, Gineste M, Dairaine L, et al. Building self-optimized 399 communication systems based on applicative cross-layer 400 information. Computer Standards & Interfaces, 2009, 401 31(2): 354-361. 403 11. Acknowledgments 405 This Internet Draft is the result of a great deal of constructive 406 discussion with several people, notably Man Tang, Hui Huang, and 407 Peng Wang. 409 This document was prepared using 2-Word-v2.0.template.dot. 411 Authors' Addresses 413 Changqiao Xu 414 Beijing University of Posts and Telecommunications 415 Institute of Network Technology, No. 10, Xitucheng Road, 416 Haidian District, Beijing 417 P.R. China 419 Email: cqxu@bupt.edu.cn 421 Jiuren Qin 422 Beijing University of Posts and Telecommunications 423 Institute of Network Technology, No. 10, Xitucheng Road, 424 Haidian District, Beijing 425 P.R. China 427 Email: jrqin@bupt.edu.cn 429 Hongke Zhang 430 Beijing University of Posts and Telecommunications 431 Institute of Network Technology, No. 10, Xitucheng Road, 432 Haidian District, Beijing 433 P.R. China 435 Email: hkzhang@bupt.edu.cn 437 Chunshan Xiong 438 Huawei Technologies Co., Ltd 439 Science and Technology Demonstration Garden, No. 156, Zhongguancun 440 North Qing Road, 441 Haidian District, Beijing 442 P.R. China 444 Email: sam.xiongchunshan@huawei.com 446 Lei Zhu 447 Huawei Technologies Co., Ltd 448 Science and Technology Demonstration Garden, No. 156, Zhongguancun 449 North Qing Road, 450 Haidian District, Beijing 451 P.R. China 453 Email: lei.zhu@huawei.com