Network Working Group Hong-ke. Zhang Internet Draft Bo. Wang Dong.Yang Fei.Song Huan.Yan Beijing Jiaotong University Expires: March 2009 September 16, 2008 Wireless Multi-path Transmission Using SCTP draft-zhang-wcmt-sctp-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. 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 This Internet-Draft will expire on March 16, 2009. Abstract In this draft, WCMT-SCTP(WCMT:Wireless Concurrent Multi-path Transfer)is proposed to allow a host to improve the transmission throughput in wireless multi-hop networks using simultaneous multi- path transmission of Stream Control Transmission Protocol. Relevant Zhang Expires March 16, 2009 [Page 1] Internet-Draft September 2008 issues of WCMT-SCTP included are: (1) data transmission mode and path selection, (2) path management and, (3) multi-path handover mechanism. Transmission modes of WCMT-SCTP, and the path handover mechanism, are designed to enhance the transmission throughput and solve the receive buffer blocking problem of different wireless link status. Since the transmission paths used for WCMT-SCTP may differ when an WCMT-SCTP host moves, the multi-path handover problem is defined, and a handover mechanism is proposed. Conventions used in this document 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 . Table of Contents 1. Introduction................................................3 1.1.Wireless mobile sctp..................................3 1.2. SCTP multi-path transmission.........................3 1.3. Wireless mobile Multi-path transmission using SCTP....3 2. Head-of-line blocking and receive buffer blocking: Problem Description....................................................4 2.1. Example Description..................................4 2.2. Discussion..........................................5 3. Transmission mechanism and path selection of WCMT-SCTP.....5 3.1.Transmission mechanism of WCMT-SCTP...................5 3.2.The retransmission mechanism of WCMT-SCTP protocol.....6 3.2.1 Distinguish different types of packet loss........6 3.2.2 Retransimission Mechanism of WCMT-SCTP...........7 3.3.Path selection........................................8 3.3.1 The trigger of path selection....................8 3.3.2 Path selection mechanism.........................8 4. Modifications to SCTP.....................................9 4.1.Chunks format modifications...........................9 4.2.Congestion control mechanism changed in WCMT-SCTP.....10 4.3.Path handover notification changed in WCMT-SCTP.......11 4.4.Other modifications have to be taken in WCMT-SCTP.....12 5. Further considerations...................................12 6. Security considerations..................................12 7. IANA considerations......................................12 8. References..............................................12 Intellectual Property Statement................................14 Disclaimer of Validity........................................14 Copyright Statement...........................................14 Acknowledgment................................................15 Zhang Expires March 16, 2009 [Page 2] Internet-Draft September 2008 1. Introduction 1.1.Wireless mobile sctp Stream Control Transmission Protocol (SCTP)[1]is a transport layer protocol that supports multihoming in nature. The SCTP ADDIP Extention[2] enables an SCTP endpoint to dynamically add a new IP address and delete an unnecessary IP address, and change the primary IP address used for the association without terminating the correspongding association. A new SCTP chunk type that the SCTP Address Reconfiguration introduces is the SCTP ASCONF(Address Configuration Change)chunk type. The SCTP ASCONF chunk is used to notify the corresponding event to the remote endpoint when one of the events such as ADD (to add a new IP address), DELETE (to delete anunnecessary IP address), or CHANGE (to change the primary path) occurs in an ongoing association. With the functions provided by SCTP ADDIP Extension, SCTP becomes more powerful when it is adopted in wireless mobile networks. The changed sctp protocol which is enabled the address reconfiguration is called mobile sctp(msctp). Some researches of mSCTP, which is based on the SCTP ADDIP Extension, are also proposed to enable the mobility support of SCTP [3][4]. 1.2. SCTP multi-path transmission Currently, some researchers are proposed to enable SCTP to transmit data through multiple paths to improve transmission throughput, e.g., IPCC-SCTP, LS-SCTP, Westwood SCTP, cmpSCTP, and mmpSCTP. 1.3. Wireless mobile Multi-path transmission using SCTP The main scope of this draft is to investigate relevant issues of multi-path transmission using SCTP in wireless multi-hop mobile networks, and try to propose a protocol extension of SCTP, namely, WCMT-SCTP. In this draft, a concurrent multi-path transmission mechanism is proposed to improve the throughput under different wireless network status. Furthermore, a possible path selection policy that is used to select the paths used by WCMT-SCTP is also proposed in this draft. The scope of this draft also includes the path handover managements of WCMT-SCTP. i.e., the substitute paths selection of WCMT-SCTP. Zhang Expires March 16, 2009 [Page 3] Internet-Draft September 2008 2. Head-of-line blocking and receive buffer blocking: Problem Description 2.1. Example Description We present a specific example which illustrates the head-of-line blocking and receive buffer blocking problem in the concurrent multi- path transfer. Consider the architecture shown below: ------- _________ _____ | | / \ | | | |A1 <============== Path 1 ============> B1| | | |<------------->| |<------------>| | | Host | | Wireless | | Host | | A | | Network | | B | | | | | | | | |<------------->| |<------------>| | | |A2 <============== Path 2 ============> B2| | | | \_________/ | | ------ ------ Figure 1: Example Architecure SCTP endpoints A and B have an association between them. Both endpoints are multihomed, A posses network interfaces A1 and A2,and B posses interfaces B1 and B2. More precisely, A1, A2, B1 and B2 are associated with link layer interfaces. A1 and B1, A2 and B2 are bound to one SCTP association. in this example, We assume that the data traffic are transmitted through these four interfaces simultaneously. Thus it forms two paths: path1 is the data traffic from A to B1 which is routed through A1, and path2 is the data traffic from A to B2 which is routed through A2. Both path1 and path2 have a certain packet loss rate. Each host has one transport receive buffer. Now, consider the following sequence of events: Zhang Expires March 16, 2009 [Page 4] Internet-Draft September 2008 1) The sender (host A) initially sends data to the receiver (host B) using both destination address B1 and B2. 2) Because there is only one receive buffer, if there is a path failure or packet error occurred on the path1, the receiver has to wait for retransmissions to come through, and is unable to deliver subsequent TSNs to the application (some of which were sent over path1). These subsequent TSNs (time sequence number) are held in the transport layer receive buffer and the peer-rwnd(receive window) is reduced sharply, so the path2 gets into congestion. Thus path2 causes blocking of the receive buffer, preventing data from being sent on either path and reduce over all throughput. 3) If there are multiple data streams exist in one SCTP association, consecutive TSN number may be assigned to different streams. For example, stream1 is assigned TSN number 1, 3, 5, 7, 9, and stream2 is assigned TSN number 2, 4, 6, 8, 10. If receiver receives data packets with TSN number 1, 2, 3, 4, 5, 7, 9, 10, it can deliver the data of the stream 1 to application absolutely, because data stream is SCTP protocol is completely logic independently. But in real transfer process in traditional transport protocol, the receiver has to wait data packet with TSN number 6 and 8. This instance causes the head-of-line blocking problem. 2.2. Discussion The receive buffer blocking and head-of-line blocking problems are existed in all traditional CMT transfer. The essential of this problem is that all paths using a shared buffer and global variable TSN is used to calculate the receive order of each path. 3. Transmission mechanism and path selection of WCMT-SCTP 3.1.Transmission mechanism of WCMT-SCTP WCMT-SCTP protocol has the following characters: 1) WCMT-SCTP has multi send buffers and multi receive buffers. 2) WCMT-SCTP has a per-path congestion control mechanism. The original SCTP only allows for CWND adjustments when the association cumulative TSN Ack point is updated by an incoming SACK. This is correct when at most one path is used at any given time and consecutive packets arrive in order at the receiver, but in the CMT situation, the assumption of ordered reception does not hold anymore, and SACKs, may acknowledge one or more chunks that were received in order on different paths, which do not update the association Zhang Expires March 16, 2009 [Page 5] Internet-Draft September 2008 cumulative TSN Ack point. This problem can be easily solved by introducing a per-path Ack point and updating it after processing a meaningful SACK. 3) In order to solve the receive buffer blocking and head-of-line blocking problems in the CMT situation, it proposed to bind one of multiple data streams with one of the multi-path. The sender can transfer multiple data streams in the same time, but if there is no path failure packet loss is reported, the certain data stream can only be transferred on the certain path. 4) In WCMT-SCTP, the protocol uses stream identifier (SID) and path sequence number (PSN) instead of TSN as the adjustment of CWND. Because the data stream is bind with the path, so using these two parameters can uniquely identify per-path CWND. 5) The retransmission mechanism of WCMT-SCTP protocol is different as used in original SCTP protocol. It depends on types of packet loss. 3.2.The retransmission mechanism of WCMT-SCTP protocol 3.2.1 Distinguish different types of packet loss In wireless network, packet losses can be categorized as three major types. Congestion loss: It occurs in the transmit nodes in wireless networks because of bandwidth and buffer limitations that result in buffer over-flows. In wireless network, it could not be the main reason of packet loss. Error Loss: It occurs at random over a wireless channel due to transmission errors, caused mainly by impairments such as noise, interference and multi-path fading. Path failure loss: It occurs in the situation that the original path is inexistence and packets are re-routed to the new path. Consecutive packets may be lost due to futile transmissions over old path. Path failure loss is also one of the main sources of packet losses in wireless communication. The difference between path failure loss and congestion loss as well as error loss is that path failure loss is usually detected by a time out, while error loss and congestion loss are detected by a sender receiving duplicate SACKs. Zhang Expires March 16, 2009 [Page 6] Internet-Draft September 2008 3.2.2 Retransimission Mechanism of WCMT-SCTP When the packet loss is detected by receiving duplicate SACKs, a WCMT-SCTP sender uses a failure detection threshold called DMR (data max retransmission). When a sender experiences more than DMR consecutive retransmission of the same loss packets and no one is succeed, it will try to reach other active destination, the original destination is marked as failed. Only heartbeats are sent to the failed destination. The original destination returns to the active state when the sender receives a heartbeat ack from the destination again. The default DMR value of WCMT-SCTP is 3. The finite state machine is shown below: ----------------------- | Path is "Active" |<----- | Send Data | | ----------------------- | | | | | \|/ | ---------------------- No | | Adjust Received the |------>| | same Duplicate-SACK? | | ---------------------- | | | | Yes | \|/ | ---------------------- No | | Adjust Consecutive |------> | Retransmit Time> DMR? | ---------------------- | | Yes \|/ ------------------------ / Path is "Failure" \ | Change to a New Path | \ / ------------------------ When the path is failure, the packet loss is detected by timeout. In this situation, if twice consecutive timeout is happened, the original destination is marked as failed immediately, and the sender will try to reach a new active destination. The status of failed destination turns into active is as same as that of error loss process. The finite state machine is shown below: Zhang Expires March 16, 2009 [Page 7] Internet-Draft September 2008 ----------------------- | Path is "Active" |<----- | Send Data | | ----------------------- | | | | | \|/ | ---------------------- No | | Adjust Consecutive |------ | Timeout Time> 2? | ---------------------- | | Yes \|/ ------------------------ / Path is "Failure" \ | Change to a New Path | \ / ------------------------ 3.3.Path selection 3.3.1 The trigger of path selection When the total number of available transmission paths is more than the number of paths that needs to be used for WCMT-SCTP, i.e., the path number is larger than the number of data streams. a path selection mechanism is needed to select which paths should be used. The path selection mechanism can be triggered in the following conditions: 1. Association initiation: the initial setup of an association in a multihomed host to start the data transmission. 2. New path added: a new path is discovered as available and added into the association. 3. Path inactive: A path that is used by WCMT-SCTP is determined as "inactive" by the association. 3.3.2 Path selection mechanism In condition "Association Initiation", when the multihomed host is going to setup an association, the multihomed host connects to its peer endpoint using one of its available addresses. Then the multihomed host exchanges the information of all available IP addresses with its peer endpoint in initialization. When the Zhang Expires March 16, 2009 [Page 8] Internet-Draft September 2008 initialization is complete, WCMT-SCTP triggers the path selection mechanism to select the paths which has the minimum RTT time to use for the following transmission. If the number of data streams is smaller than or equal to the path number, one path will bind with one data streams. If the number of data streams is less than the path number, some of the largest bandwidth paths will bind with more than one data streams. Condition "New path added" occurs when the multihomed host added a new IP and found a new path between source and receiver. The path selection mechanism can be triggered to determine whether the newly added transmission path is better than the one that is currently used. Condition "Path inactive" occurs when one of the transmit paths repeatlly fails and determined as "inactive" by the association. Thus, WCMT-SCTP will trigger the path selection mechanism to select another transmission path to replace the failed path. 4. Modifications to SCTP On the basis of the aforementioned issues and design, some modifications must be made to SCTP to solve the problems and support the new features of WCMT-SCTP. 4.1.Chunks format modifications A new parameter path sequence number (PSN) is used to substitute transmit sequence number (TSN). PSN represents sequence of SCTP data chunk transmitted through a path, it has similar function as TSN in standard SCTP. The data chunk format of WCMT-SCTP is defined as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+ | Type=0x00 |Reserved| Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+ | Path Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+ | Stream Identifier | Stream Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+ | Payload Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+ | Variable Length User Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+ Zhang Expires March 16, 2009 [Page 9] Internet-Draft September 2008 The SACK chunk format of WCMT-SCTP is defined as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3 | Flags=0 | Length=variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative PSN ACK | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Stamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID #1 | rwnd 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID #N | rwnd N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num of Fragments=M | Num of Dup=k | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap ACK #1 start | Gap ACK #1 end | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap ACK #M start | Gap ACK #M end | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate PSN #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate PSN #K | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The time stamp is used to determine the order of the SACKs, the receiver of the old SACK does not update its view of the rwnd of the peer. 4.2.Congestion control mechanism changed in WCMT-SCTP PSN is used in WCMT-SCTP for congestion control. The sender keeps a mapping relationship table between stream identifiers (SID) and the corresponding paths. So the protocol can use PSN and SID instead of TSN to achieve the congestion control mechanism on each path. The CWND updating mechanism and gap report process of WCMT-SCTP is as follows : Sender Side Behavior: (1)CWND updating on SACKs On receipt of a SACK for each destination di for each PSN being acked by the SACK and yet not been acked do Zhang Expires March 16, 2009 [Page 10] Internet-Draft September 2008 if PSN.dst=di then di.num_acked_PSN_old=di.num_acked_PSN increment di.num_acked_PSN by1; if(SIDi_PSNn_outstanding=TRUE) then Decrement di.num_out_SIDi by 1; end end end increment di.CWND by min(di.num_acked_PSN-di.num_acked_PSN_old,PMTU); end (2)GAP Report Process On receipt of a SACK with GAP reports: for each SIDi_PSNm that are reported as missing do if(SIDi_PSNn_outstanding=TRUE&&di_num_out_SIDi!=0) then increment the missing report count for SIDi_SSNm; else do not increment the missing report count for SIDi_PSNm; end end 4.3.Path handover notification changed in WCMT-SCTP The SCTP ADDIP Extention allows an SCTP host to dynamically add, delete, and change the primary address of ongoing association without interrupting it. But the ADDIP Extention function is only used for the situation of one primary path used. In multiple primary paths situation,new chunk type to announce which primary path has to be Zhang Expires March 16, 2009 [Page 11] Internet-Draft September 2008 replaced.(this need a new chunk type, we can discuss the format of the new chunk) 4.4.Other modifications have to be taken in WCMT-SCTP In order to avoid spurious retransmission, SACKs must be sent to the new destination address after the path handover occurs at the sender. The CWND of the sender should not grow when receiving the acknowledgments of the PSNs that are transmitted through the old path after the path handover occurs at the sender. 5. Further considerations For the practical implementation of WCMT-SCTP, path selection should be performed for each type of the wireless access technology. But the WCMT-SCTP can not know which access technology the host use, so the probability solution is using cross layer design. For example, in the process of association established, the initial transport packet can take some information of routing layer or PHY/MAC layer. Thus the path selection mechanism can be successful performed. 6. Security considerations Security considerations are not discussed in this memo. 7. IANA Considerations This document has no actions for IANA. 8. References [1]R. Stewart, "Stream Control Transmission Protocol," RFC 4960, IETF, September 2007. [2]R. Stewart, Q. Xie et. al., "Stream Control Transmission Protocol(SCTP)Dynamic Address Reconfiguration, " RFC 5061, IETF, September 2007. [3]S. J. Koh, et al., "Architecture of Mobile SCTP for IP Mobility Support," draft-sjkoh-sctp-mobility-02.txt, June 2003 [4]M. Riegel, M. Tuexen, "Mobile SCTP," draft-riegel-tuexen-mobile-sctp- 06.txt, October 2004. Authors' Addresses: Hong-ke Zhang Next generation Internet research center Zhang Expires March 16, 2009 [Page 12] Internet-Draft September 2008 School of electronic and information engineering Beijing Jiaotong University Beijing, China Email:hkzhang@bjtu.edu.cn Bo Wang Next generation Internet research center School of electronic and information engineering Beijing Jiaotong University Beijing, China Email:wangbolulu@163.com Dong Yang Next generation Internet research center School of electronic and information engineering Beijing Jiaotong University Beijing, China Email:youngmanyd@163.com Fei Song Next generation Internet research center School of electronic and information engineering Beijing Jiaotong University Beijing, China Email:song2000fei@gmail.com Huan Yan Next generation Internet research center Zhang Expires March 16, 2009 [Page 13] Internet-Draft September 2008 School of electronic and information engineering Beijing Jiaotong University Beijing, China Email:fanfan_821@163.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2008). Zhang Expires March 16, 2009 [Page 14] Internet-Draft September 2008 This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zhang Expires March 16, 2009 [Page 15]