Network Working Group W. Lei Internet-Draft S. Liu Intended status: Experimental W. Zhang Expires: January 28, 2014 Northeastern University July 29, 2013 Multipath Message Transport Protocol Based on Application-level Relay (MPMTP-AR) draft-leiwm-tsvwg-mpmtp-ar-00.txt Abstract Multipath transmission is an important way to improve the quality of service for message transport. This document defines a multipath message transmission protocol under the framework of Multipath Transport System Based on Application-level Relay (MPTS-AR). This protocol follows OpenPath and MPTP Profile defined in MPTS-AR. Apart from behaviors of user agent defined in MPTS-AR, user agent should be also responsible for message reliable transmission,including connective session establishment, sequenced deliver,select acknowledgement, retransmission, recombination and congestion avoidance, etc. This document describes those new or changed behaviors, and expands the MPTP format to meet them.Moreover this document illustrates the details of multipath transmission mechanism reference to the reliable transmission characteristics. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 28, 2014 . Copyright Notice Leiwm, et al. Expires January 28, 2014 [Page 1] Internet-Draft MPMTP-AR July 2013 Copyright (c) 2013 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. Leiwm, et al. Expires January 28, 2014 [Page 2] Internet-Draft MPMTP-AR July 2013 Table of Contents 1. Introduction ................................................ 6 2. Terminology ................................................. 7 3. Definition .................................................. 7 4. Goals ....................................................... 9 5. Overview .................................................... 9 6. Usage Scenarios ............................................. 11 7. MPMTP-AR Agent Behavior ..................................... 11 7.1 Consistent Behaviors ................................... 12 7.1.1 Path management ................................. 12 7.2 Modified Behaviors ..................................... 12 7.2.1 Subflow recombination ........................... 12 7.3 Additional Behaviors ................................... 12 7.3.1 Session management .............................. 12 7.3.2 Flow partitioning and scheduling ................ 13 7.3.3 Subflow packaging ............................... 13 7.3.4 Subflow reporting ............................... 14 7.4 New Behaviors .......................................... 14 7.4.1 Sequenced Delivery .............................. 14 7.4.2 Acknowledgement and Congestion Avoidance ........ 15 8. MPMTP-AR Packet Format: MPTP Format Extension ............... 16 8.1 Overview ............................................... 16 8.2 MPMTP-AR Header ........................................ 16 8.3 MPMTP-AR Data Chunk Definition ......................... 17 8.4 MPMTP-AR Control Chunk Definition ...................... 19 8.4.1 Sender Report (SR) .............................. 20 8.4.2 Receiver Report (RR) ............................ 21 8.4.3 Keep Alive (KA) ................................. 22 8.4.4 Session Initiation (SINIT) ...................... 22 8.4.5 Session Initiation Acknowledgement (SINIT ACK) .. 24 8.4.6 State Cookie (COOKIE ECHO) ...................... 25 8.4.7 Cookie Acknowledgement (COOKIE ACK) ............. 26 8.4.8 Subflow INIT Request (SubINIT) .................. 26 8.4.9 Subflow INIT Acknowledgement (SubINIT ACK) ...... 26 8.4.10 Selective Acknowledgement (SACK) ................ 26 8.4.11 Subflow Shutdown (SubSHUTDOWN) .................. 29 8.4.12 Subflow Shutdown Acknowledgement (SubSHUTDOWN ACK) ............................... 30 8.4.13 Session Shutdown (SSHUTDOWN) .................... 30 8.4.14 Session Shutdown Acknowledgement (SSHUTDOWN ACK). 30 8.4.15 Session Shutdown Complete (SSHUTDOWN COMPLETE) .. 31 8.4.16 Abort (ABORT) ................................... 31 8.4.17 Operation Error (ERROR) ......................... 32 8.4.18 Path Feedback (PATH FEEDBACK) ................... 37 8.4.19 Path Probe (PATH PROBE) ......................... 38 9. MPMTP-AR Session State Diagram .............................. 39 10. Session Initialization ...................................... 42 Leiwm, et al. Expires January 28, 2014 [Page 3] Internet-Draft MPMTP-AR July 2013 10.1 Normal Establishment of a Session ...................... 43 10.1.1 Handle Path Parameters .......................... 44 10.1.2 Generating State Cookie ......................... 44 10.1.3 State Cookie Processing ......................... 45 10.1.4 State Cookie Authentication ..................... 46 10.1.5 Open Subflow .................................... 46 10.2 Handle Duplication or Unexpected Issue ................. 47 10.2.1 Unexpected SINIT in States Other than CLOSED, COOKIE-ECHOED, COOKIE-WAIT, and SSHUTDOWN-ACK-SENT .............................. 47 10.2.2 Unexpected SINIT ACK ............................ 48 10.2.3 Handle a COOKIE ECHO when a TCB Exists .......... 48 10.2.4 Handle Duplicate COOKIE-ACK ..................... 49 10.2.5 Handle Stale COOKIE Error ....................... 49 10.3 Other Initialization Issues ............................ 49 10.3.1 Selection of Tag Value .......................... 49 11. User Data Transfer .......................................... 50 11.1 Transmission of DATA Chunks ............................ 51 11.2 Acknowledge on Reception of DATA Chunks ................ 53 11.2.1 Processing a Received SACK ...................... 55 11.3 Management of Retransmission Timer ..................... 57 11.3.1 RTO Calculation ................................. 57 11.3.2 Retransmission Timer Rules ...................... 58 11.3.3 Handle T3-RTX Expiration ........................ 59 11.4 Stream Identifier and Stream Sequence Number ........... 60 11.5 Ordered and Unordered Delivery ......................... 60 11.6 Report Gaps in Received DATA TSNs ...................... 61 11.7 Fragmentation and Reassembly ........................... 62 12. Congestion Control .......................................... 63 12.1 MPMTP-AR Differences from TCP Congestion Control ....... 63 12.2 MPMTP-AR Slow-Start and Congestion Avoidance ........... 64 12.2.1 Slow-Start ...................................... 65 12.2.2 Congestion Avoidance ............................ 66 12.2.3 Congestion Control .............................. 67 12.2.4 Fast Retransmit on Gap Reports .................. 67 12.3 Path MTU Discovery ..................................... 69 13. Fault Management ............................................ 69 13.1 Endpoint Failure Detection ............................. 69 13.2 Path Failure Detection ................................. 70 13.3 Handle "Out of the Blue" Packets ....................... 70 13.4 Verification Tag ....................................... 71 13.4.1 Exceptions in Verification Tag Rules ............ 72 14. Termination of Session ...................................... 73 14.1 Abort of a Session ..................................... 73 14.2 Shutdown of a Session .................................. 73 15. Security Consideration ...................................... 75 16. Reference ................................................... 75 16.1 Normal Reference ....................................... 75 Leiwm, et al. Expires January 28, 2014 [Page 4] Internet-Draft MPMTP-AR July 2013 16.2 Information Reference .................................. 75 Leiwm, et al. Expires January 28, 2014 [Page 5] Internet-Draft MPMTP-AR July 2013 1. Introduction This document defines the Multipath Message Transport Protocol Based on Application-Level Relay (MPMTP-AR) under the Framework of Multipath Transport System Based on Application-Level Relay [1], which provides end-to-end multipath transmission services with reliable transmission characteristics. As the Internet evolves, demands on Internet resources are ever-increasing, but often these resources (in particular, bandwidth) cannot be fully utilized due to protocol constraints both on the end-systems and network resources. If these resources could be used concurrently, network resource utilization and end user experience could be greatly improved. Although current protocols such as TCP, MPTCP and SCTP support multipath or reliable transmission, a lot of applications show that there are some limitations to them. The limitations that users have wished to bypass include the following: 1) TCP supports both reliable data transfer and strict order-of-transmission delivery of data. But it cannot provide multipath transmission. It also refuses relay transport; otherwise the transmission efficiency is very low. 2) MPTCP [4] provides multipath transmission service. At least one of participates needs to be multi-homed. The transmission uses multiple IP pairs (Source IP, Destination IP) simultaneously to support multipath transmission. Transmission between each IP pair is the same with TCP [6].This multi-homed requirement limits the range of application. 3) SCTP has reliable transmission characteristic. Although SCTP endpoints have several IP pairs, they just use one of them to deliver message, the others are backup. It cannot support multipath transmission. All those limitations motivated the development of MPMTP-AR. MPMTP-AR overcome those limitations by multipath delivery based on application level relay, select acknowledgement and retransmission mechanisms. Parts of mechanisms reference to SCTP [3]. MPMTP-AR aims to realize some of the goals of resource pooling by simultaneously making use of multiple paths and reliable transmission. The three key benefits of multipath transport are the following: 1) To increase the efficiency of the resource usage, and thus increase the network capacity available to agent. Leiwm, et al. Expires January 28, 2014 [Page 6] Internet-Draft MPMTP-AR July 2013 2) Increased Throughput: In some cases, the relay path, which is assigned to a MPMTP-AR association according to the location of participants and the current network status, has better transport capacity than the default path between the endpoints. And cumulative transport capacity of multiple paths may meet the requirements of the high bit-rate message transmission better. 3) To increase the resilience of the connectivity by providing multiple paths, protecting path from the failure of one. 2. Terminology 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 RFC2119 [2]. 3. Definition 1) Cumulative TSN Ack Point: The TSN of the last DATA chunk acknowledged via the Cumulative TSN Ack field of a SACK. 2) Tie Tags: Two 32-bit random numbers that together make a 64-bit nonce, including from tag and to tag. These tags are used to identify a valid session which is unique in the whole network. 3) Message Authentication Code (MAC): An integrity check mechanism based on cryptographic hash functions using a secret key. Typically, message authentication codes are used between two parties that share a secret key in order to validate information transmitted between these parties. In MPMTP-AR, it is used by an agent to validate the State Cookie information that is returned from the peer in the COOKIE ECHO chunk. The term "MAC" has different meanings in different contexts. MPMTP-AR uses this term with the same meaning as in [7]. 4) MPMTP-AR application (MPMTP-AR user): The logical higher-layer application entity which uses the services of MPMTP-AR. 5) Ordered Message: A user message that is delivered in order with respect to all previous user messages sent within the stream on which the message was sent. 6) Outstanding TSN (at an MPMTP-AR agent): A TSN (and the associated DATA chunk) that has been sent by the agent but for which it has not yet received an acknowledgement. 7) Receiver Window (rwnd): An MPMTP-AR variable a data sender uses to store the most recently calculated receiver window of its peer, in Leiwm, et al. Expires January 28, 2014 [Page 7] Internet-Draft MPMTP-AR July 2013 number of bytes. This gives the sender an indication of the space available in the receiver's inbound buffer. 8) Slow-Start Threshold (ssthresh): An MPMTP-AR variable. This is the threshold that the agent will use to determine whether to perform slow start or congestion avoidance on a particular path. Ssthresh is in number of bytes. 9) Stream: A logical channel between one MPMTP-AR agent to another associated MPMTP-AR agent, within which user message is delivered in sequence except for those submitted to the unordered delivery service. 10)Stream Identification: A sequence number used internally by MPMTP-AR to identify the stream to which the user data belongs. 11)Stream Sequence Number: A sequence number used internally by MPMTP-AR to ensure sequenced delivery of the user messages within a given stream. One Stream Sequence Number is attached to each user message. 12)Transmission Control Block (TCB): An internal data structure created by an MPMTP-AR agent for each of its existing MPMTP-AR session to other MPMTP-AR endpoints. TCB contains all the status and operational information for the agent to maintain and manage the corresponding session. 13)Transmission Sequence Number (TSN): A 32-bit sequence number used internally by MPMTP-AR. One TSN is attached to each chunk containing user data to permit the receiving MPMTP-AR agent to acknowledge its receipt and detect duplicate deliveries. 14)Unacknowledged TSN (at an MPMTP-AR agent): A TSN (and the associated DATA chunk) that has been received by the agent but for which an acknowledgement has not yet been sent. Or in the opposite case, for a packet that has been sent but no acknowledgement has been received. 15)Unordered Message: Unordered messages are "unordered" with respect to any other message; this includes both other unordered messages as well as other ordered messages. An unordered message might be delivered prior to or later than ordered messages sent on the same stream. 16)Session Tag: A 32-bit unsigned integer that is randomly generated. The Verification Tag provides a key that allows a receiver to verify that the MPMTP-AR packet belongs to the current session and is not an old or stale packet from a previous session. Leiwm, et al. Expires January 28, 2014 [Page 8] Internet-Draft MPMTP-AR July 2013 4. Goals Using MPTP extension for reliable transmission, original data belonging to a session is divided multiple subflows and carried over multiple paths. This may prove beneficial in case of reliable transmission. 1) Improve Throughput: MPMTP-AR MUST support the concurrent use of multiple paths. To meet the minimum performance incentives for deployment, a MPMTP-AR connection over multiple paths SHOULD achieve no worse throughput than regular default path connection over the best constituent paths. 2) Improve Resilience: MPMTP-AR MUST support the use of multiple paths interchangeably for resilience purposes, by permitting packets to be sent and re-sent on any available path. It follows that, in the worst case, the protocol MUST be no less resilient than regular default path. In order to guarantee reliable and order transmission, MPMTP-AR has the following goals: 1) Load balancing: transmitting a message over multiple paths reduces the bandwidth usage on a single path, which in turn reduces the impact of the message stream on other traffic on that path and then avoids congestion in network hot-spots. From the perspective of the whole network, the network reliable and network utilization can be significantly improved. 2) Acknowledgement and Retransmission: when the receiver receive data chunks, it SHOULD indicate the sender about correctly received data chunks by acknowledgement; if some data chunks with transmission error, the sender MUST retransmit them by retransmission mechanism. 5. Overview Figure 1: Illustrates the structure of the proposed multipath transmission framework based on application-level relay and the relationship between user agent, relay and controller. Application-level relay-based multipath transport framework core defines three logical entities and two protocols which provide interfaces between logical entities. Based on this framework, we define additional MPTP format extension and user agent behaviors to support reliable transmission. Leiwm, et al. Expires January 28, 2014 [Page 9] Internet-Draft MPMTP-AR July 2013 (1)Out-of-band Signaling +-----------------+ (1) +--------------------->| Out-of-band |<------------------+ | | Signaling Server| | | +-----------------+ | | ^ | | |(1)OpenPath | | V | | or (2) OpenPath +------------------+ | | +----------------->| Relay Controller | | | | +------------------+ | | | ^ | | | | | V V | V +------------+ |OpenPath +------------+ | User Agent | | | User Agent | | (Sender) | | | (Receiver) | +------------+ V +------------+ | ................................. ^ | . +-----------------+ . | | . | Relay server | . | | . +-----------------+ | . | | . | Relay server |--+ . | | . +-----------------+ | . | +------------>. | Relay server |--+ .------------+ MPTP . | | . MPTP . +-----------------+ . ................................. Figure 1 : The structure of the proposed multipath transmission framework based on application-level relay. User agent, who is responsible for sending out data chunks, called the sender, needs to collect candidate paths, and establish a connective session before transmitting data. The framework defines two ways to be used for collecting candidate paths by the sender. Before using them, the sender performs connectivity checks on relay paths to ascertain reachability. According to transmission requirements of current session, the sender selects the default path and one or more available relay paths as active paths to transmit data to the receiver. A multiple session may be setup from the beginning, or may be upgraded from a default path. The connective session establishment mechanism uses a four-way-handshake, the middle two legs of which are allowed to carry authentication. Then the sender distributes the original data across the active paths based on a scheduling strategy and encapsulates them as Leiwm, et al. Expires January 28, 2014 [Page 10] Internet-Draft MPMTP-AR July 2013 special structure of MPTP packets before delivery. The receiver combines the received subflows to recreate the original data flow. The receiver sends selective acknowledgement of data chunk to the sender.Then the sender will sends error data chunks immediately and wait for out of stand chunks for a special timer. The retransmission may choose a best performance subflow, or may be different from the sublfow for which the chunk timer expired or eroded. The session provides for graceful close on request from the MPMTP-AR agents, and also allows ungraceful close either on request from the MPMTP-AR agents or as a result of an error condition detected. 6. Usage Scenarios MPMTP-AR can provide end-to-end message transmission application, such as file transfer. Figure 2 illustrates a end-to-end multipath session. There are three paths between the sender and the receiver, including the default path, one relay path via one relay and another relay path via two relays. Applications running at the sender side can choose a data partitioning method according to its particular requirements. Then, each flow is assigned to a path. The receiver reassembles the received data chunks using a re-order buffer to retrieve the reconstructed flow which is delivered to the above application. Relay path(A, Relay-1, B) +-----------+ +-------------------->| Relay-1 |-----------------------+ | +-----------+ | | V +--------+ Default path(A,B) +--------+ | User A |<----------------------------------------------->| User B | +--------+ +--------+ | ^ | Relay path(A, Relay-2, Relay-3, B) | | +-----------+ +-----------+ | +---->| Relay-2 |-------------------->| Relay-3 |-----+ +-----------+ +-----------+ Figure.2. An end-to-end multipath session 7. MPMTP-AR Agent Behavior Based on user agent behavior in MPTS-AR, MPMTP-AR agent behavior needs modification, extension and addition to support message transmission. Those functions include session and path management, Leiwm, et al. Expires January 28, 2014 [Page 11] Internet-Draft MPMTP-AR July 2013 flow partitioning and scheduling, subflow packageing, sequenced delivery within subflow, subflow recombination, subflow reporting, and acknowledgement and congestion avoidance. Compare with the agent behavior in MPTS-AR, MPMTP-AR agent behaviors divided into four types: Consistent Behaviors, Modified Behaviors, Additional Behaviors, and New Behaviors. 7.1 Consistent Behaviors 7.1.1 Path management As illustrated in MPTS-AR, the sender need to manage the path including obtain default path and candidate relay path, periodically path probe, path keep-alive, and monitor quality of active paths. Details refer to section of path management in MPTS-AR. 7.2 Modified Behaviors 7.2.1 Subflow recombination The receiver recombines the original message according to MPTP packers received from multiple subflows. The receiver first collects receiving statistics for per-subflow by using Path-ID and Subflow-Specific sequence number. Then the receiver puts data chunks together and orders them by Transmission Sequence Number. At last, the receiver distinguishes different message by Stream ID and orders by Stream Sequence Number. The receiver delivers original message to application. 7.3 Additional Behaviors 7.3.1 Session management MPMTP-AR is a connection-oriented application-level protocol, so a connective session needs to be established before transporting message on multiple paths. The MPMTP-AR session setup uses a way of out-of-band signaling (OpenPath) to get path information. The session parameters negotiated and authentication should be done during the signaling process. A session with multipath may be setup at the beginning, or may be upgraded from a session with a default path. The connective session establishment uses a four-way-handshake. MPMTP-AR provides for graceful close (i.e., shutdown) of an active session on request from the agent. MPMTP-AR also allows ungraceful close (i.e., abort), either on request from the agent (ABORT primitive) or as a result of an error condition detected. Leiwm, et al. Expires January 28, 2014 [Page 12] Internet-Draft MPMTP-AR July 2013 MPMTP-AR session is a set of multiple paths which are based on connection. The detailed description of session management messages will be specified in section 8.4. 7.3.2 Flow partitioning and scheduling MPTS-AR defines a simple flow partitioning scheme to assign packets to multiple subflows using the round-robin algorithm. In MPMTP-AR, we introduce a path-based algorithm. Due to paths has different transmission quality, we should assign data chunks to subflows according to their capacity to increase transmission quality. Since the sender can monitor active path quality, such as bandwidth information, the path reception statistics (e.g. RTT, loss-rate, delay etc.), so the sender assigned more data chunks to the path which has a better performance. Data chunks distributions adjust dynamically and periodically. The sender should associate a subflow with an active path according to scheduling strategy. MPTS-AR indicates that the scheduling policy should take various factors into consideration, including the estimated path bandwidth information, the path reception statistics (e.g. RTT, loss-rate, delay etc.), and the relative importance of subflow data and so on. The sender orders the available path list according to the path quality descending order. At the same time, the sender maintains active paths. If the path in available path list performs better than an active path for a time, then the path should take over the active path. This behavior is maintained throughout the session. 7.3.3 Subflow packaging In a session, the sender formats data chunks into MPMRP data packets following MPRP core protocol defined in MPTS-AR and the MPTP extension defined in section 8. Then the sender dispatches MPTP data packets along corresponding paths. Apart from two key fields including path identifier and subflow-specific sequence number defined in MPTS-AR, the common header also has two another fields: from-tag, and to-tag. Both from-tag and to-tag are unique. They are generated by the sender and receiver respectively at the establishment of the session. If they have not been generated, they are set to zero. The from-tag and the to-tag represent a globally unique session. Control information and user data are encapsulated into chunks. The chunks contain a common header and chunk value. All chunks put into payload field in MPTP data format. Details of different chunks are Leiwm, et al. Expires January 28, 2014 [Page 13] Internet-Draft MPMTP-AR July 2013 defined in section 8. 7.3.4 Subflow reporting As mentioned in MPTP-AR, both the sender and the receiver need to send subflow report to monitor the transmission quality. MPTP-AR only defines deliver route of Sender Reports (SR) and Receiver Reports (RR). In this document, we define when to generate reports and what reports contain. The suggested constants are to be used for the subflow report interval calculation. Sessions operating under this document may specify a separate parameter for the traffic bandwidth rather than using the default fraction of the session bandwidth. The recommended fraction of the session bandwidth added for reports be fixed at 5%. The recommendation is that 1/4 of the report bandwidth be dedicated to data sender, the recommended default values for these two parameters would be 1.25%and 3.75%, respectively. The reports bandwidth for data senders should be kept non-zero so that sender reports can still be sent for inter-media synchronization. The content of report should be able to reflect the sending and receiving status. They collect statistics, such as sent chunks, and received chunks for per subflow. Details of the report format defined in section 8.4. 7.4 New Behaviors 7.4.1 Sequenced Delivery MPMTP-AR supports reliable and ordered message transmission by sequence, such as Transmission Sequence Number, Subflow-Specific Sequence Number, Stream Identification, Stream Sequence Number, and Path-ID. MPMTP-AR uses two levels of sequence spaces to guarantee reliable and ordered transmission: a session-level sequence number (Transmission Sequence Number) and another suflow-level sequence number (Subflow-Specific Sequence Number) for each DATA chunk. TSN is initialed as a randomly number, and SSSN is a number starting from zero. This permits session-level segmentation reassembly and retransmission of the same part of session-level sequence space on different subflow-level sequence space. The sender must be able to tell the receiver how to reassemble the data. In order to achieve this, the receiver must determine how subflow-level data (carrying stream sequence numbers) maps at the session-level. This is referred to as the "transmission sequence Leiwm, et al. Expires January 28, 2014 [Page 14] Internet-Draft MPMTP-AR July 2013 mapping". This mapping can be represented as a tuple of (transmission sequence number, Subflow-Specific sequence number, length), i.e., for a given number of bytes (the length), the subflow sequence space beginning at the given sequence number maps to the session-level sequence space (beginning at the given data sequence number). MPMTP-AR uses path identity to distinguish multiple paths. One-to-one relationship is between path and subflow. This ensures the path to be unique in the whole network. The sender must be able to tell the relay to choose which path and tell the receiver which subflow the Packet come from by Path-ID. 7.4.2 Acknowledgement and Congestion Avoidance MPMTP-AR supports select acknowledgements at session-level in order to provide an acknowledgement and retransmission service to the application. MPMTP-AR assigns a Transmission Sequence Number (TSN) to each data chunk. The TSN is independent of any Stream Sequence Number (SSN) assigned at the stream level. The receiving SACK acknowledges all TSNs received, even if there are gaps in the sequence. In this way, reliable delivery is kept functionally separate from sequenced stream delivery. MPMTP-AR could use the data sequence mapping and session-level SACKs to decide when a session-level segment was received. A session-level SACKs signal when the receive window moves forward, sum correct receiving transmission sequence number, out of order blocks and retransmission blocks. It would mean that once a segment is SACKed, it can be discarded in the send buffer. Re-transmission send buffer has higher priority. Transmission reports signal the sender detail information of active path, such as correctly receiving ratio and RTT. Sender would send segments in re-transmission buffer over the best transmission quality path according to transmission report. MPMTP-AR agent message from application, and put it into send buffer. At the beginning, the receiver tells the sender size of receive window via MPMTP-AR session establishment. During message transmission, receiver moves forward receive window and signals the sender this change via SACKs. The sender adjusts send buffer according to receive window size. The acknowledgement and congestion avoidance function is responsible for packet retransmission when timely acknowledgement has not been received. Packet retransmission is conditioned by congestion avoidance procedures similar to those used for TCP. Large-scale experiments are therefore required in order to determine the most appropriate retransmission strategy, and recommendations will Leiwm, et al. Expires January 28, 2014 [Page 15] Internet-Draft MPMTP-AR July 2013 be refined once more information is available. 8. MPMTP-AR Packet Format: MPTP Format Extension This section defines MPTP format extension to meet the requirement of behaviors described in section 7. 8.1 Overview As stated in MPTS-AR, although MPTP obtain a simple, unreliable datagram service from the underlying UDP [5], MPTP can meet reliable delivery requirements of upper application programs. MPTP is only a protocol framework that is not complete, reliable delivery requirement of upper application programs can be met in MPTP extension. In order to support agent behavior illustrated in section 7, we define MPMTP-AR packet format, by expanding MPTP header to define several types of chunk which are put into MPTP payload data or control data field. 8.2 MPMTP-AR Header MPMTP-AR header inherits from MPTP header, including eight octet-length header, and add another eight octet-length extension after it. The eight octet-length addition is same for MPMTP-AR data packets and MPMTP-AR control packets. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=1|T|P| AMT | TOS/CT | SSSN/Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | From Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | To Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Chunk / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields have the following meaning: In this document, AMT=2, indicates that this MPMTP-AR packet conforms Leiwm, et al. Expires January 28, 2014 [Page 16] Internet-Draft MPMTP-AR July 2013 to reliable MPTP extension. From Tag/To Tag: 32 bits (unsigned integer) This field is set by the sender/receiver of this chunk. Each agent generates a tag randomly at the session establishment, and keeps the tag during the whole session. When the agent sends packet, it puts its own tag in From Tag, and put the peer's tag in To Tag. If the sender doesn't have the peer's tag, this field is set zero. The combination of the From tag, and To tag completely defines a peer-to-peer session relationship. Chunk: (variable length) This field contains data or control information which is defined in the next sections. 8.3 MPMTP-AR Data Chunk Definition Each MPMTP-AR data packet contains one data chunk. The following format MUST be used for the DATA chunk: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=1|1|P| AMT | TOS | SSSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | From Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | To Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SI |Reserved |U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transmission Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Protocol Identifier | Stream Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / User Data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SI (Stream Identification):8 bits A sequence number identify the stream to which the user data belongs. U bit: 1 bit The (U)nordered bit, if set to '1', indicates that this is an Leiwm, et al. Expires January 28, 2014 [Page 17] Internet-Draft MPMTP-AR July 2013 unordered DATA chunk, and there is no Stream Sequence Number assigned to this DATA chunk. Therefore, the receiver MUST ignore the Stream Sequence Number field. After reassembly (if necessary), unordered DATA chunks MUST be dispatched to the upper layer by the receiver without any attempt to reorder. If an unordered user message is fragmented, each fragment of the message MUST have its U bit set to '1'. B bit: 1 bit The (B)eginning fragment bit, if set, indicates the first fragment of a user message. E bit: 1 bit The (E)nding fragment bit, if set, indicates the last fragment of a user message. An unfragmented user message shall have both the B and E bits set to '1'. Setting both B and E bits to '0' indicates a middle fragment of a multi-fragment user message, as summarized in the following table: When a user message is fragmented into multiple chunks, the TSNs are used by the receiver to reassemble the message. This means that the TSNs for each fragment of a fragmented user message MUST be strictly sequential. Length: 16 bits (unsigned integer) This field indicates the length of the DATA chunk in bytes from the beginning of the type field to the end of the User Data field excluding any padding. A DATA chunk with one byte of user data will have Length set to 17 (indicating 17 bytes). A DATA chunk with a User Data field of length L will have the Length field set to (12 + L) (indicating 12+L bytes) where L MUST be greater than 0. TSN: 32 bits (unsigned integer) This value represents the TSN for this DATA chunk. The valid range of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back to 0 after reaching 4294967295. Payload Protocol Identifier: 16 bits (unsigned integer) This value represents an application specified protocol identifier. This value is passed to MPMTP-AR by its MPMTP-AR user and sent to its peer. This identifier is not used by MPMTP-AR but can be used by certain network entities, as well as by the peer application, to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA Leiwm, et al. Expires January 28, 2014 [Page 18] Internet-Draft MPMTP-AR July 2013 chunks. Note that this field is NOT touched by an MPMTP-AR implementation; therefore, its byte order is NOT necessarily big endian. The MPMTP-AR user is responsible for any byte order conversions to this field. The value 0 indicates that no application identifier is specified by the upper layer for this payload data. Stream Sequence Number: 16 bits (unsigned integer) This value represents the Stream Sequence Number of the following user data within the stream. Valid value range is 0 to 65535. User Data: variable length This is the payload user data. The implementation MUST pad the end of the data to a 4-byte boundary with all-zero bytes. Any padding MUST NOT be included in the Length field. A sender MUST never add more than 3 bytes of padding. 8.4 MPMTP-AR Control Chunk Definition The figure below illustrates the field format for the control packets to be transmitted in the MPMTP-AR packet. Each packet is formatted according to CT field. Control data is packed into chunks. Next sections from 8.4.1 to 8.4.19 describe the format of control chunks. The values of CT are defined as follows: Leiwm, et al. Expires January 28, 2014 [Page 19] Internet-Draft MPMTP-AR July 2013 +---------------+-----------------------------------------------------+ | ID Value | Chunk Type | +---------------+-----------------------------------------------------+ | 1 | Sender Report (SR) | +---------------+-----------------------------------------------------+ | 2 | Receiver Report (RR) | +---------------+-----------------------------------------------------+ | 3 | Keep Alive (KA) | +---------------+-----------------------------------------------------+ | 4 | Session Initiation (SINIT) | +---------------+-----------------------------------------------------+ | 5 | Session Initiation Acknowledgement (SINIT ACK) | +---------------+-----------------------------------------------------+ | 6 | Cookie Echo (COOKIE ECHO) | +---------------+-----------------------------------------------------+ | 7 | Cookie Acknowledgement (COOKIE ACK) | +---------------+-----------------------------------------------------+ | 8 | Subflow INIT Request (SubINIT) | +---------------+-----------------------------------------------------+ | 9 | Subflow INIT Acknowledgement (SubINIT ACK) | +---------------+-----------------------------------------------------+ | 10 | Selective Acknowledgement (SACK) | +---------------+-----------------------------------------------------+ | 11 | Subflow Shutdown (SubSHUTDOWN) | +---------------+-----------------------------------------------------+ | 12 | Subflow Shutdown Acknowledgement (SubSHUTDOWN ACK) | +---------------+-----------------------------------------------------+ | 13 | Session Shutdown (SSHUTDOWN) | +---------------+-----------------------------------------------------+ | 14 | Session Shutdown Acknowledgement (SSHUTDOWN ACK) | +---------------+-----------------------------------------------------+ | 15 | Session Shutdown Complete (SSHUTDOWN COMPLETE) | +---------------+-----------------------------------------------------+ | 16 | Abort (ABORT) | +---------------+-----------------------------------------------------+ | 17 | Operation Error (ERROR) | +---------------+-----------------------------------------------------+ | 18 | Path Feedback (PATH FEEDBACK) | +---------------+-----------------------------------------------------+ | 19 | Path Probe (PATH PROBE) | +---------------+-----------------------------------------------------+ 8.4.1 Sender Report (SR) The sender report packet consists of three sections. Leiwm, et al. Expires January 28, 2014 [Page 20] Internet-Draft MPMTP-AR July 2013 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's octet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields have the following meaning: Timestamp: 32 bits Indicates the time when this report was sent. Sender's packet count: 32 bits The total number of MPMTP-AR data packets transmitted by the sender since starting transmission up until the time this SR packet was generated. The count SHOULD be reset if the sender changes its tag. Sender's octet count: 32 bits The total number of payload octets (i.e., not including header or padding) transmitted in RTP data packets by the sender since starting transmission up until the time this SR packet was generated. The count SHOULD be reset if the sender changes its tag. This field can be used to estimate the average payload data rate. 8.4.2 Receiver Report (RR) The receiver report packet consists of four sections. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cumulative number of packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last RR (LRR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last RR (DLRR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cumulative number of packets: 32 bits The total number of MPMTP-AR data packets from sender that have been received since the beginning of reception. Highest sequence number received: 32 bits The field contains the highest transmission sequence number received in a MPMTP-AR data packet from the sender. Last SR (LSR): 32 bits This field indicates the time of receiving last sender report. If Leiwm, et al. Expires January 28, 2014 [Page 21] Internet-Draft MPMTP-AR July 2013 no SR has received yet, this field is set to zero. Delay since last SR (DLSR): 32 bits The delay, expressed in units of 1/65536 seconds, between receiving the last SR packet from the sender and sending this reception report packet. If no SR packet has been received yet, the DLSR field is set to zero. 8.4.3 Keep Alive (KA) This chunk contains only timestamp. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Timestamp: 32 bits This field indicates the time of sending this Keep Alive packet. 8.4.4 Session Initiation (SINIT) This chunk is used to initiate an MPMTP-AR session between two endpoints. The format of the SINIT chunk is shown below: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Outbound Subflow (N)| MSN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Optional/Variable-Length Parameters / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The SINIT chunk contains the following parameters. Unless otherwise noted, each parameter MUST only be included once in the INIT chunk. --------------------------------------------------------------- | Fixed Parameters | Status | --------------------------------------------------------------- | Number of Outbound Subflow | Mandatory | --------------------------------------------------------------- | Maximum Stream Number (MSN) | Mandatory | --------------------------------------------------------------- | Initial TSN | Mandatory | --------------------------------------------------------------- | Variable Parameters | Optional | --------------------------------------------------------------- IMPLEMENTATION NOTE: If an SINIT chunk is received with known parameters that are not optional parameters of the SINIT chunk, then the receiver SHOULD process the SINIT chunk and send back an SINIT Leiwm, et al. Expires January 28, 2014 [Page 22] Internet-Draft MPMTP-AR July 2013 ACK. Number of Outbound Subflow (NOS): 16 bits (unsigned integer) Defines the maximum number of outbound subflow the sender of this SINIT chunk wishes to create in this session. The value of 0 MUST NOT be used. Note: A receiver of an SINIT with the NOS value set to 0 SHOULD abort the session. MSN (Maximum Stream Number): 8 bits (unsigned integer) Defines the max number of streams the sender of this SINIT chunk allows to use in this session. Note: A receiver of an SINIT with the MSN value set to 0 SHOULD abort the session. Initial TSN (I-TSN): 32 bits (unsigned integer) This value defines the initial TSN that the sender will use. The valid range is from 0 to 2**32-1. This field MAY be set to the value of the Initiate Tag field. 1) Optional/Variable-Length Parameters in INIT The format of optional parameters in the INIT ACK chunk is shown below: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Parameters Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 16 bits (unsigned integer) This field identifies the type of parameters contained in the optional field. Length: 16 bits (unsigned integer) This field indicates the length of the optional parameters in bytes from the beginning of the type field to the end of the parameters field excluding any padding. Optional parameters with one byte parameters will have Length set to 5 (indicating 5 bytes). Details of variable-length parameters would be discussed in the future. Leiwm, et al. Expires January 28, 2014 [Page 23] Internet-Draft MPMTP-AR July 2013 8.4.5 Session Initiation Acknowledgement (SINIT ACK) The SINIT ACK chunk is used to acknowledge the initiation of an MPMTP-AR session. The parameter part of SINIT ACK is formatted similarly to the SINIT chunk. It uses two extra variable parameters: advertised receiver window credit and state cookie. The format of the SINIT ACK chunk is shown below: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Inbound Subflow (N) | MSN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Optional Parameters (State Cookie) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer) This value represents the dedicated buffer space, in number of bytes, the receiver has reserved in session with this window. During the life of the session, this buffer space SHOULD NOT be lessened (i.e., dedicated buffers taken away from this session). Number of Inbound Subflow (NIS): 16 bits (unsigned integer) Defines the maximum number of subflow the receiver allows the sender to create in this session. The value 0 MUST NOT be used. Note: There is no negotiation of the actual number of subflow but instead the two endpoints will use the min (requested, offered). Note: The sender receives SINIT ACK with the MIS value set to 0 SHOULD destroy the session discarding its TCB. MSN (Maximum Stream Number): 8 bits (unsigned integer) This field defines the max number of streams the receiver allows to use in this session. Valid value range is 1 to 31. State Cookie: Type Value: 1 Length: Variable size, depending on size of Cookie. Parameter Value: This parameter value MUST contain all the necessary state and parameter information required to create the session, along Leiwm, et al. Expires January 28, 2014 [Page 24] Internet-Draft MPMTP-AR July 2013 with a Message Authentication Code (MAC). 8.4.6 State Cookie (COOKIE ECHO) This chunk is used only during the initialization of a session. It is sent by the initiator of an session to its peer to complete the initialization process. This chunk MUST precede any DATA chunk sent within the session. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPN (N) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path-ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path-ID #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Cookie / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPN (Init Path Number): 16 bit Chunk Flags in this chunk called IPN indicates the number of initialize path which the sender wants to use at the beginning of the session. Valid value range is 1 to 255. It MUST NOT be bigger than MIS INIT ACK. Length: 16 bits (unsigned integer) Set to the size of the chunk in bytes, including the 4 bytes of the chunk header and the chunk body. Path-ID: 32 bits (unsigned integer) This field indicates the path identification of subflow which the sender will use in the session. Cookie: variable size This field must contain the exact cookie received in the State Cookie parameter from the previous INIT ACK. An implementation SHOULD make the cookie as small as possible to ensure interoperability. Leiwm, et al. Expires January 28, 2014 [Page 25] Internet-Draft MPMTP-AR July 2013 Note: A Cookie Echo does NOT contain a State Cookie parameter; instead, the data within the State Cookie's Parameter Value becomes the data within the Cookie Echo's Chunk Value. This allows an implementation to change only the first 2 bytes of the State Cookie parameter to become a COOKIE ECHO chunk. 8.4.7 Cookie Acknowledgement (COOKIE ACK) This chunk is used to end a session establishment. It acknowledges the receipt of a COOKIE ECHO chunk. This chunk is empty, so the packet just contains packet header. 8.4.8 Subflow INIT Request (SubINIT) The sender should send this chunk to its peer agent to notify the use of a particular relay path negotiated in SINIT and SINIT ACK. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Path-ID: 32 bits (unsigned integer) This field indicates the path identification of subflow which the sender want to use in the session. 8.4.9 Subflow INIT Acknowledgement (SubINIT ACK) The receiver should send this chunk to its peer agent to notify the use of a particular relay path negotiated in SINIT and SINIT ACK. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8.4.10 Selective Acknowledgement (SACK) This chunk is sent to the peer agent via default path to acknowledge received DATA chunks and to inform the peer agent of gaps in the received subsequences of DATA chunks as represented by their TSNs. The SACK MUST contain the Cumulative TSN Ack, Advertised Receiver Window Credit (a_rwnd), Number of Gap Ack Blocks, and Number of Duplicate TSNs fields. By definition, the value of the Cumulative TSN Ack parameter is the Leiwm, et al. Expires January 28, 2014 [Page 26] Internet-Draft MPMTP-AR July 2013 last TSN received before a break in the sequence of received TSNs occurs; the next TSN value following this one has not yet been received at the agent sending the SACK. This parameter therefore acknowledges receipt of all TSNs less than or equal to its value. The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack Block acknowledges a subsequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative TSN Ack. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative TSN Ack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit (a_rwnd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #1 Start | Gap Ack Block #1 End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ ... \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #N Start | Gap Ack Block #N End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ ... \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cumulative TSN Ack: 32 bits (unsigned integer) This parameter contains the TSN of the last DATA chunk received in sequence before a gap. In the case where no DATA chunk has been received, this value is set to the peer's Initial TSN minus one. Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer) This field indicates the updated receive buffer space in bytes of the sender of this SACK. Number of Gap Ack Blocks: 16 bits (unsigned integer) This field indicates the number of Gap Ack Blocks included in this Leiwm, et al. Expires January 28, 2014 [Page 27] Internet-Draft MPMTP-AR July 2013 SACK. Number of Duplicate TSNs: 16 bit This field contains the number of duplicate TSNs the agent has received. Each duplicate TSN is listed following the Gap Ack Block list. Gap Ack Blocks: These fields contain the Gap Ack Blocks. They are repeated for each Gap Ack Block up to the number of Gap Ack Blocks defined in the Number of Gap Ack Blocks field. All DATA chunks with TSNs greater than or equal to (Cumulative TSN Ack + Gap Ack Block Start) and less than or equal to (Cumulative TSN Ack + Gap Ack Block End) of each Gap Ack Block are assumed to have been received correctly. Gap Ack Block Start: 16 bits (unsigned integer) Indicates the Start offset TSN for this Gap Ack Block. To calculate the actual TSN number the Cumulative TSN Ack is added to this offset number. This calculated TSN identifies the first TSN in this Gap Ack Block that has been received. Gap Ack Block End: 16 bits (unsigned integer) Indicates the End offset TSN for this Gap Ack Block. To calculate the actual TSN number, the Cumulative TSN Ack is added to this offset number. This calculated TSN identifies the TSN of the last DATA chunk received in this Gap Ack Block. For example, assume that the receiver has the following DATA chunks newly arrived at the time when it decides to send a Selective ACK. ---------- | TSN=36 | ---------- | | <- still missing ---------- | TSN=34 | ---------- | TSN=33 | ---------- | | <- still missing ---------- | TSN=31 | ---------- | TSN=30 | ---------- | TSN=29 | ---------- Leiwm, et al. Expires January 28, 2014 [Page 28] Internet-Draft MPMTP-AR July 2013 then the parameter part of the SACK MUST be constructed as follows (assuming the new a_rwnd is set to 1500 by the sender): +--------------------------------+ | Cumulative TSN Ack = 31 | +--------------------------------+ | a_rwnd = 1500 | +----------------+---------------+ | num of block=2 | num of dup=0 | +----------------+---------------+ |block #1 strt=2 |block #1 end=3 | +----------------+---------------+ |block #2 strt=5 |block #2 end=5 | +----------------+---------------+ Duplicate TSN: 32 bits (unsigned integer) Indicates the number of times a TSN was received in duplicate since the last SACK was sent. Every time a receiver gets a duplicate TSN (before sending the SACK); it adds it to the list of duplicates. The duplicate count is reinitialized to zero after sending each SACK. For example, if a receiver were to get the TSN 35 three times it would list 35 twice in the outbound SACK. After sending the SACK, if it received yet one more TSN 35 it would list 35 as a duplicate once in the next outgoing SACK. 8.4.11 Subflow Shutdown (SubSHUTDOWN) An agent in a session MUST use this chunk to initiate a graceful close of the session with its peer. Either the sender or the receiver can initialize this chunk. This chunk has the following format. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Number(N) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / ... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Leiwm, et al. Expires January 28, 2014 [Page 29] Internet-Draft MPMTP-AR July 2013 Path Number (N): 32 bits (unsigned integer) This field indicates how many subflows will be closed. Path ID: 32 bits (unsigned integer) This parameter contains the Path ID of the subflow which will be closed. 8.4.12 Subflow Shutdown Acknowledgement (SubSHUTDOWN ACK) This chunk MUST be used to acknowledge the receipt of the SubSHUTDOWN chunk at the completion of the shutdown process. The format is similar with SubSHUTODWN chunk. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Number(N) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / ... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8.4.13 Session Shutdown (SSHUTDOWN) This chunk is used to close a session. The chunk is empty, so the packet just contains header. 8.4.14 Session Shutdown Acknowledgement (SSHUTDOWN ACK) This SSHUTDOWN ACK chunk MUST be used to acknowledge the receipt of the SSHUTDOWN chunk. Leiwm, et al. Expires January 28, 2014 [Page 30] Internet-Draft MPMTP-AR July 2013 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Number(N) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / ... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This chunk indicates the sender which subflow will be closed by Path ID. 8.4.15 Session Shutdown Complete (SSHUTDOWN COMPLETE) This chunk MUST be used to acknowledge the receipt of the SSHUTDOWN ACK chunk and complete the shutdown process. The chunk is empty, so the packet just contains header. 8.4.16 Abort (ABORT) The ABORT chunk is sent to the peer of a session to close the session. The ABORT chunk may contain Cause Parameters to inform the receiver about the reason of the abort. Control chunks (except for SINIT, SINIT ACK, and SSHUTDOWN COMPLETE) MAY be followed with an ABORT, but they MUST be sent before the ABORT packet or they will be ignored by the receiver. If an agent receives an ABORT with a format error or no TCB is found, it MUST silently discard it. Moreover, under any circumstances, an agent that receives an ABORT MUST NOT respond to that ABORT by sending an ABORT of its own. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / zero or more Error Causes / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: 16 bits (unsigned integer) Set to the size of the chunk in bytes, including the chunk header and all the Error Cause fields present. Leiwm, et al. Expires January 28, 2014 [Page 31] Internet-Draft MPMTP-AR July 2013 See section 8.4.17 for Error Cause definitions. 8.4.17 Operation Error (ERROR) An agent sends this chunk to its peer agent to notify it of certain error conditions. It contains one or more error causes. An Operation Error is not considered fatal in and of it, but may be used with an ABORT chunk to report a fatal condition. It has the following parameters: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / one or more Error Causes / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Number: 8 bits (unsigned integer) This field indicates the number of errors listed in next Error Causes field. Length: 16 bits (unsigned integer) Set to the size of the parameter in bytes, including the Number, Reserved, Length, and Error Cause fields. Error causes are defined as variable-length parameters using the format described as below: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Cause-Specific Information / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cause Code: 16 bits (unsigned integer) This value defines the type of error conditions being reported. Leiwm, et al. Expires January 28, 2014 [Page 32] Internet-Draft MPMTP-AR July 2013 Cause Code Value Cause Code --------- ---------------- 1 Invalid Path-ID 2 Missing Mandatory Parameter 3 Stale Cookie Error 4 Out of Resource 5 Unrecognized Chunk Type 7 Invalid Mandatory Parameter 7 Unrecognized Parameters 8 No User Data 9 Cookie Received While Shutting Down 10 User Initiated Abort 11 Protocol Violation Cause Length: 16 bits (unsigned integer) Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields. Cause-Specific Information: variable length This field carries the details of the error condition. The following section 1) - 11) define error causes for MPMTP-AR. 1) Invalid Path-ID Cause of error: Invalid Path ID indicates Relay received a DATA chunk sent to a nonexistent subflow. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=1 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Path ID: 16 bits (unsigned integer) This field contains the Stream Identifier of the DATA chunk received in error. Reserved: 16 bits This field is reserved. It is set to all 0 on transmit and ignored on receipt. 2) Missing Mandatory Parameter Leiwm, et al. Expires January 28, 2014 [Page 33] Internet-Draft MPMTP-AR July 2013 Cause of error: Missing Mandatory Parameter: indicates that one or more mandatory parameters are missing in a received INIT or INIT ACK. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=2 | Cause Length=8+N*2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of missing params=N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Missing Param Type #1 | Missing Param Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Missing Param Type / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Missing Param Type #N-1 | Missing Param Type #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Number of Missing params: 32 bits (unsigned integer) This field contains the number of parameters contained in the Cause-Specific Information field. Missing Param Type: 16 bits (unsigned integer) Each field will contain the missing mandatory parameter number. 3) Stale Cookie Error Cause of error: Stale Cookie Error indicates the receipt of a valid State Cookie that has expired. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=3 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Measure of Staleness (usec.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Measure of Staleness: 32 bits (unsigned integer) This field contains the difference, in microseconds, between the current time and the time the State Cookie expired. The sender of this error cause MAY choose to report how long past expiration the State Cookie is by including a non-zero value in the Measure of Staleness field. If the sender does not wish to provide this information, it should set the Measure of Staleness field to the value of zero. Leiwm, et al. Expires January 28, 2014 [Page 34] Internet-Draft MPMTP-AR July 2013 4) Out of Resource Cause of error: Out of Resource: Indicates that the sender is out of resource. This is usually sent in combination with or within an ABORT. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=4 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5) Unrecognized Chunk Type Cause of error: Unrecognized Chunk Type: This error cause is returned to the originator of the chunk if the receiver does not understand the chunk. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=5 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Unrecognized Chunk / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unrecognized Chunk: variable length The Unrecognized Chunk field contains the unrecognized chunk from the MPMTP-AR packet complete with Chunk Type, Chunk Flags, and Chunk Length. 6) Invalid Mandatory Parameter Cause of error: Invalid Mandatory Parameter: This error cause is returned to the originator of an SINIT or SINIT ACK chunk when one of the mandatory parameters is set to an invalid value. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=6 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7) Unrecognized Parameters Cause of error: Unrecognized Parameters: This error cause is returned Leiwm, et al. Expires January 28, 2014 [Page 35] Internet-Draft MPMTP-AR July 2013 to the originator of the SINIT ACK chunk if the receiver does not recognize one or more Optional parameters in the SINIT ACK chunk. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=7 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Unrecognized Parameters / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unrecognized Parameters: variable length The Unrecognized Parameters field contains the unrecognized parameters copied from the SINIT ACK chunk. This error cause packet is normally contained in an ERROR chunk followed with the COOKIE ECHO packet when responding to the INIT ACK, when the sender of the COOKIE ECHO chunk wishes to report unrecognized parameters. 8) No User Data Cause of error: No User Data: This error cause is returned to the originator of a DATA chunk if a received DATA chunk has no user data. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=8 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / TSN Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TSN value: 32 bits (unsigned integer) The TSN value field contains the TSN of the DATA chunk received with no user data field. 9) Cookie Received While Shutting Down Cause of error: Cookie Received While Shutting Down: A COOKIE ECHO was received while the agent was in the session-level SSHUTDOWN-ACK- SENT state. This error is usually returned in an ERROR chunk followed with the retransmitted SSHUTDOWN ACK. Leiwm, et al. Expires January 28, 2014 [Page 36] Internet-Draft MPMTP-AR July 2013 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=9 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10) User-Initiated Abort Cause of error: This error cause MAY be included in ABORT chunks that are sent because of an MPMTP-AR user request. The MPMTP-AR user can specify an Abort Reason that is transported by MPMTP-AR transparently and MAY be delivered to the MPMTP-AR user at the peer. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=10 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Upper Layer Abort Reason / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11) Protocol Violation Cause of error: This error cause MAY be included in ABORT chunks that are sent because an MPMTP-AR agent detects a protocol violation of the peer that is not covered by the error causes described in above section 1) to section 10). An implementation MAY provide additional information specifying what kind of protocol violation has been detected. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=11 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Additional Information / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8.4.18 Path Feedback (PATH FEEDBACK) This chunk is used to indicate the sender about path feedback information. The chunk includes time interval, subflow identification, max received transmission sequence number and correctly received data chunk number. Leiwm, et al. Expires January 28, 2014 [Page 37] Internet-Draft MPMTP-AR July 2013 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Feedback Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Current Feedback Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Received Max TSN #1 | Received Data Chunks Number #1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / ... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Received Max TSN #N | Received Data Chunks Number #N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Last Feedback Time: 32 bits (unsigned integer) This field marks the time at which the receiver seed last PATH FEEDBACK. Current Feedback Time: 32 bits (unsigned integer) This field marks the time at which the receiver seeds this PATH FEEDBACK. Received Max TSN: 16 bits (unsigned integer) This field indicates the max TSN of data chunk received from the path mark at Path ID field. Received Data Chunks Number: 16 bits (unsigned integer) This field indicates the number of data chunk received from the path mark at Path ID between the Last Feedback Time and the Current Feedback Time. 8.4.19 Path Probe (PATH PROBE) An agent should send this chunk to its peer agent to probe the path reachability and RTT. This chunk contains send time. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Leiwm, et al. Expires January 28, 2014 [Page 38] Internet-Draft MPMTP-AR July 2013 Timestamp: 32 bits This field record the send time of this chunk form the initiator of this chunk. The receiver delivers this chunk to the sender via default path as soon as received and do not do any change to it. The initiator can calculate the RTT by send time and receive time. 9. MPMTP-AR Session State Diagram During the life time of an MPMTP-AR session, the MPMTP-AR agent's session progresses from one state to another in response to various events. The state diagram in the figures below illustrates state changes, together with the causing events and resulting actions. Note that some of the error conditions are not shown in the state diagram. Full descriptions of all special cases are found in the text. Note: Chunk names are given in all capital letters, while parameter names have the first letter capitalized, e.g., COOKIE ECHO chunk type vs. State Cookie parameter. If more than one event/message can occur that causes a state transition, it is labeled (A), (B), etc. Leiwm, et al. Expires January 28, 2014 [Page 39] Internet-Draft MPMTP-AR July 2013 ----- -------- (from any state) / \ / rcv ABORT [ABORT] rcv SINIT | | | ---------- or ---------- --------------- | v v delete TCB snd ABORT generate Cookie \ +---------+ delete TCB snd SINIT ACK ---| CLOSED | +---------+ / \ [Session] / \ --------------- | | create TCB | | snd SINIT | | strt init timer rcv valid | | COOKIE ECHO | v (1) ---------------- | +------------+ create TCB | | COOKIE-WAIT| (2) snd COOKIE ACK | +------------+ | | | | rcv SINIT ACK | | ----------------- | | snd COOKIE ECHO | | stop sinit timer | | strt cookie timer | v | +--------------+ | | COOKIE-ECHOED| (3) | +--------------+ | | | | rcv COOKIE ACK | | ----------------- | | stop cookie timer v v +---------------+ | ESTABLISHED | +---------------+ Leiwm, et al. Expires January 28, 2014 [Page 40] Internet-Draft MPMTP-AR July 2013 (from the ESTABLISHED state only) | | /--------+--------\ [SSHUTDOWN] / \ -------------------| | check outstanding | | DATA chunks | | v | +---------+ | |SSHUTDOWN| | rcv SSHUTDOWN |PENDING | |------------------ +---------+ | check outstanding | | DATA chunks No more outstanding | | ---------------------| | snd SSHUTDOWN | | strt shutdown timer | | v v +---------+ +-----------+ (4) |SSHUTDOWN| | SSHUTDOWN | (5,6) |SENT | | RECEIVED | +---------+ +-----------+ | | rcv SSHUTDOWN ACK | |No more outstanding -----------------------| |------------------- stop shutdown timer | |send SSHUTDOWN ACK send SSHUTDOWN COMPLETE| |strt shutdown timer delete TCB | | | | | | | | | +-----------+ | | SSHUTDOWN | (7) | | ACK-SENT | | +-----------+ | | rcv SSHUTDOWN COMPLETE | |----------------------- | | stop shutdown timer | | delete TCB | | | | \ +---------+ / \-->| CLOSED |<--/ +---------+ Notes: 1) If the State Cookie in the received COOKIE ECHO is invalid Leiwm, et al. Expires January 28, 2014 [Page 41] Internet-Draft MPMTP-AR July 2013 (i.e., failed to pass the integrity check), the receiver MUST silently discard the packet. Or, if the received State Cookie is expired (see section 10.1.4), the receiver MUST send back an ERROR chunk. In either case, the receiver stays in the CLOSED state. 2) If the T1-init timer expires, the agent MUST retransmit SINIT and restart the T1-init timer without changing state. This MUST be repeated up to 'Max.Init.Retransmits' times. After that, the agent MUST abort the initialization process and report the error to the MPMTP-AR user. 3) If the T1-cookie timer expires, the agent MUST retransmit COOKIE ECHO and restart the T1-cookie timer without changing state. This MUST be repeated up to MAX Init Retransmits times. After that, the agent MUST abort the initialization process and report the error to the MPMTP-AR user. After that, the agent MUST abort the initialization process and report the error to the MPMTP-AR user. 4) In the SSHUTDOWN-SENT state, the agent MUST response any received control chunks without delay. 5) In the SSHUTDOWN-RECEIVED state, the agent MUST leave this state when all data in queue is ordered. The CLOSED state is used to indicate that a subflow is not created (i.e., doesn't exist). 10. Session Initialization Before the first data transmission can take place from one MPMTP-AR agent ("A") to another MPMTP-AR agent ("Z"), the two endpoints must complete a session process in order to set up an MPMTP-AR session between them. The MPMTP-AR user at an agent should use the SESSION primitive to initialize an MPMTP-AR session to another MPMTP-AR agent. IMPLEMENTATION NOTE: From an MPMTP-AR user's point of view, a session may be implicitly opened, without a SESSION primitive being invoked, by the initiating agent's sending of the first user data to the destination agent. The initiating MPMTP-AR will assume default values for all mandatory and optional parameters for the SINIT/SINIT ACK. Once the session is established, unidirectional path is open for data transfer (see section 10.1.1). Then according to the parameters Leiwm, et al. Expires January 28, 2014 [Page 42] Internet-Draft MPMTP-AR July 2013 negotiated at session, MPMTP-AR agent A can use subflow after notifying agent Z. 10.1 Normal Establishment of a Session The initialization process consists of the following steps (assuming that MPMTP-AR agent "A" tries to set up a session with MPMTP-AR agent "Z" and "Z" accepts the new session): A) "A" first sends an SINIT chunk to "Z". In the SINIT, "A" must provide its Tag (Tag-A) in the from-tag field. From-tag SHOULD be a random number in the range of 1 to 4294967295 (see section 10.3.1 for Tag value selection). After sending the SINIT, "A" starts the T1-init timer and enters the COOKIE-WAIT state. B) "Z" shall respond immediately with an SINIT ACK chunk. In the response, besides filling in other parameters, "Z" must set the to-tag field to Tag_A, and also provide its own Tag (Tag_Z) in the from-tag field. Moreover, "Z" MUST generate and send along with the SINIT ACK a State Cookie. See section 10.1.3 for State Cookie generation. Note: After sending out SINIT ACK with the State Cookie parameter, "Z" MUST NOT allocate any resources or keep any states for the new session. Otherwise, "Z" will be vulnerable to resource attacks. C) Upon reception of the SINIT ACK from "Z", "A" shall stop the T1- init timer and leave the COOKIE-WAIT state. "A" shall then send the State Cookie received in the SINIT ACK chunk. D) Upon reception of the COOKIE ECHO chunk, agent "Z" will reply with a COOKIE ACK chunk after building a TCB and moving to the ESTABLISHED state. IMPLEMENTATION NOTE: An implementation may choose to send the Communication Up notification to the MPMTP-AR user upon reception of a valid COOKIE ECHO chunk. Leiwm, et al. Expires January 28, 2014 [Page 43] Internet-Draft MPMTP-AR July 2013 E) Upon reception of the COOKIE ACK, agent "A" will move from the COOKIE-ECHOED state to the ESTABLISHED state, stopping the T1-cookie timer. An agent MUST send the INIT ACK to the agent from which it received the INIT. Note: T1-init timer and T1-cookie timer shall follow the same rules given in section 11.3. If an agent receives an SINIT, SINIT ACK, or COOKIE ECHO chunk but decides not to establish the new session due to missing mandatory parameters in the received SINIT or SINIT ACK, invalid parameter values, or lack of local resources, it SHOULD respond with an ABORT chunk. It SHOULD also specify the cause of abort, such as the type of the missing mandatory parameters, etc., by including the error cause parameters with the ABORT chunk. Note that a COOKIE ECHO chunk that does NOT pass the integrity check is NOT considered an 'invalid parameter' and requires special handling; see section 10.1.4. After the reception of the first DATA chunk in a session the agent MUST immediately respond with a SACK to acknowledge the DATA chunk. Subsequent acknowledgements should be done as described in section 11.2. When the TCB is created, each agent MUST set its internal Cumulative TSN Ack Point to the value of its transmitted Initial TSN minus one. 10.1.1 Handle Path Parameters In the SINIT and SINIT ACK chunks, the sender of the chunk MUST indicate the number of outbound subflow (NOS) it wishes to have in the session, as well as the maximum stream number (MSN) it will use in the seesion. After receiving the session configuration information from the other side, MPMTP-AR agent MUST perform the following check: If the peer's number outbound subflow (NOS) is less than the agent's maximum number inbound subflow (MIS), meaning that the peer is incapable of supporting all the outbound subflow the agent wants to configure, the agent MUST use MIS outbound subflows and MAY report any shortage to the MPMTP-AR user. The MPMTP-AR user can then choose to abort the session if the resource shortage is unacceptable. After the session is initialized, the valid outbound subflow identifier range for either agent shall be 0 to min (local MIS, remote NOS)-1. 10.1.2 Generating State Cookie When sending an SINIT ACK as a response to an SINIT chunk, the sender of SINIT ACK creates a State Cookie and sends it in the State Cookie parameter of the SINIT ACK. Inside this State Cookie, the sender should include a MAC (see [RFC2104] for an example), a timestamp on when the State Cookie is created, and the lifespan of the State Cookie, along with all the information necessary for it to establish Leiwm, et al. Expires January 28, 2014 [Page 44] Internet-Draft MPMTP-AR July 2013 the session. The following steps SHOULD be taken to generate the State Cookie: 1) Create session TCB using information from both the received INIT and the outgoing INIT ACK chunk. 2) In the TCB, set the creation time to the current time of day, and the lifespan to the protocol parameter 'Valid.Cookie.Life'. 3) From the TCB, identify and collect the minimal subset of information needed to re-create the TCB, and generate a MAC using this subset of information and a secret key (see [RFC2104] for an example of generating a MAC). 4) Generate the State Cookie by combining this subset of information and the resultant MAC. After sending the INIT ACK with the State Cookie parameter, the sender SHOULD delete the TCB and any other local resource related to the new session, so as to prevent resource attacks. The hashing method used to generate the MAC is strictly a private matter for the receiver of the INIT chunk. The use of a MAC is mandatory to prevent denial-of-service attacks. The secret key SHOULD be random ([RFC4086] provides some information on randomness guidelines); it SHOULD be changed reasonably frequently, and the timestamp in the State Cookie MAY be used to determine which key should be used to verify the MAC. An implementation SHOULD make the cookie as small as possible to ensure interoperability. 10.1.3 State Cookie Processing When an agent (in the COOKIE-WAIT state) receives an SINIT ACK chunk with a State Cookie parameter, it MUST immediately send a COOKIE ECHO chunk to its peer with the received State Cookie.The sender MAY also add any pending DATA chunks to the packet after the COOKIE ECHO chunk. The agent shall also start the T1-cookie timer after sending out the COOKIE ECHO chunk. If the timer expires, the agent shall retransmit the COOKIE ECHO chunk and restart the T1-cookie timer. This is repeated until either a COOKIE ACK is received or 'Max.Init. Retransmits' is reached causing the peer agent to be marked unreachable (and thus the session enters the CLOSED state). Leiwm, et al. Expires January 28, 2014 [Page 45] Internet-Draft MPMTP-AR July 2013 10.1.4 State Cookie Authentication When an agent receives a COOKIE ECHO chunk from another agent with which it has no session, it shall take the following actions: 1) Compute a MAC using the TCB data carried in the State Cookie and the secret key (note the timestamp in the State Cookie MAY be used to determine which secret key to use). [RFC2104] can be used as a guideline for generating the MAC, 2) Authenticate the State Cookie as one that it previously generated by comparing the computed MAC against the one carried in the State Cookie. If this comparison fails, the MPMTP-AR packet, including the COOKIE ECHO and any DATA chunks, should be silently discarded. 3) Compare the Verification Tag contained within the COOKIE ECHO chunk to the Verification Tag within the MPMTP-AR common header of the received packet. If these values do not match, the packet MUST be silently discarded. 4) Compare the creation timestamp in the State Cookie to the current local time. If the elapsed time is longer than the lifespan carried in the State Cookie, then the packet, including the COOKIE ECHO and any attached DATA chunks, SHOULD be discarded, and the agent MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer agent. 5) If the State Cookie is valid, create an session to the sender of the COOKIE ECHO chunk with the information in the TCB data carried in the COOKIE ECHO and enter the ESTABLISHED state. 6) Send a COOKIE ACK chunk to the peer acknowledging receipt of the COOKIE ECHO. If a COOKIE ECHO is received from an agent with which the receiver of the COOKIE ECHO has an existing session, the procedures in section 10.2 should be followed. 10.1.5 Open Subflow When an agent wants to use a new subflow, before data transmission it needs to tell relay path information to the peer. When an agent receives a SUBFLOW INIT from another agent with which it has an session, it shall take the following actions: 1) Check subflow parameter and session information; Leiwm, et al. Expires January 28, 2014 [Page 46] Internet-Draft MPMTP-AR July 2013 2) Send response. If it is valid, the receiver sends SUBFLOW INIT ACK to the sender; otherwise, the receiver MUST transmit an ERROR chunk with an error cause to the peer agent. If the sender receives a SUBFLOW INIT ACK response, it can use this sublfow to transmit data; otherwise it SHOULD terminal this subflow request. 10.2 Handle Duplication or Unexpected Issue During the life time of a session (in one of the possible states), an agent may receive from its peer agent one of the setup chunks (SINIT, SINIT ACK, COOKIE ECHO, and COOKIE ACK). The receiver shall treat such a setup chunk as a duplicate and process it as described in this section Note: An agent will not receive the chunk unless the chunk was from an MPMTP-AR agent associated with this agent. Therefore, the agent processes such a chunk as part of its current session. The following scenarios can cause duplicated or unexpected chunks: A) The peer has crashed without being detected, restarted itself, and sent out a new SINIT chunk trying to restore the session, B) The chunk is from a stale packet that was used to establish the present session or a past session that is no longer in existence, C) The chunk is a false packet generated by an attacker, or D) The peer never received the COOKIE ACK and is retransmitting its COOKIE ECHO. The rules in the following sections shall be applied in order to identify and correctly handle these cases. 10.2.1 Unexpected SINIT in States Other than CLOSED, COOKIE-ECHOED, COOKIE-WAIT, and SSHUTDOWN-ACK-SENT Unless otherwise stated, upon receipt of an unexpected SINIT for this session, the agent shall generate an SINIT ACK with a State Cookie. Before responding, the agent MUST check to see if the unexpected SINIT adds new parameters to the session. If new parameters are added to the session, the agent MUST respond with an ABORT, copying the 'From Tag' of the unexpected INIT into the 'To Tag' of the outbound packet carrying the ABORT. If no new parameters are added, when responding to the SINIT in the outbound SINIT ACK. The outbound MPMTP-AR packet containing this SINIT ACK MUST carry a Tag value Leiwm, et al. Expires January 28, 2014 [Page 47] Internet-Draft MPMTP-AR July 2013 equal to the Initiate Tag found in the unexpected SINIT. And the SINIT ACK MUST contain a new Tag (randomly generated; see section 10.3.1). Other parameters for the agent SHOULD be copied from the existing parameters of the session (e.g., number of outbound streams) into the SINIT ACK and cookie. After sending out the SINIT ACK or ABORT, the agent shall take no further actions; i.e., the existing session, including its current state; and the corresponding TCB MUST NOT be changed. Note: Only when a TCB exists and the session is not in a COOKIE WAIT or SSHUTDOWN ACK SENT state are from or to Tags populated with a value other than 0. For a normal session INIT (i.e., the agent is in the CLOSED state), the To Tags MUST be set to 0 (indicating that no previous TCB existed). 10.2.2 Unexpected SINIT ACK If an SINIT ACK is received by an agent in any state other than the COOKIE-WAIT state, the agent should discard the SINIT ACK chunk. An unexpected SINIT ACK usually indicates the processing of an old or duplicated SINIT chunk. 10.2.3 Handle a COOKIE ECHO when a TCB Exists When a COOKIE ECHO chunk is received by an agent in any state for an existing session (i.e., not in the CLOSED state) the following rules shall be applied: 1) Compute a MAC as described in step 1 of section 10.1.4, 2) Authenticate the State Cookie as described in step 2 of section 10.1.4, 3) Compare the timestamp in the State Cookie to the current time. If the State Cookie is older than the lifespan carried in the State Cookie and the Tags contained in the State Cookie do not match the current session's Tags, the packet, including the COOKIE ECHO and any DATA chunks, should be discarded. The agent also MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer agent. If both Tags in the State Cookie match the Tags of the current session, consider the State Cookie valid even if the lifespan is exceeded. 4) If the State Cookie proves to be valid, unpack the TCB into a temporary TCB. Leiwm, et al. Expires January 28, 2014 [Page 48] Internet-Draft MPMTP-AR July 2013 10.2.4 Handle Duplicate COOKIE-ACK At any state other than COOKIE-ECHOED, an agent should silently discard a received COOKIE ACK chunk. 10.2.5. Handle Stale COOKIE Error Receipt of an ERROR chunk with a "Stale Cookie" error cause indicates one of a number of possible events: A) The session failed to completely setup before the State Cookie issued by the sender was processed. B) An old State Cookie was processed after setup completed. C) An old State Cookie is received from someone that the receiver is not interested in having a session with and the ABORT chunk was lost. When processing an ERROR chunk with a "Stale Cookie" error cause an agent should first examine if a session is in the process of being set up, i.e., the session is in the COOKIE-ECHOED state. In all cases, if the session is not in the COOKIE-ECHOED state, the ERROR chunk should be silently discarded. If the session is in the COOKIE-ECHOED state, the agent may elect one of the following three alternatives. 1) Send a new INIT chunk to the agent to generate a new State Cookie and reattempt the setup procedure. 2) Discard the TCB and report to the MPMTP-AR user the inability to set up the session. 3) Send a new INIT chunk to the agent, adding a Cookie Preservative parameter requesting an extension to the life time of the State Cookie. When calculating the time extension, an implementation SHOULD use the RTT information measured based on the previous COOKIE ECHO/ERROR exchange, and should add no more than 1 second beyond the measured RTT, due to long State Cookie life time making the agent more subject to a replay attack. 10.3 Other Initialization Issues 10.3.1 Selection of Tag Value Tag values should be selected from the range of 1 to 2**32 -1. It is very important that the initiate tag value be randomized to help Leiwm, et al. Expires January 28, 2014 [Page 49] Internet-Draft MPMTP-AR July 2013 protect against "man in the middle" and "sequence number" attacks. The methods described in [RFC4086] can be used for the Initiate Tag randomization. Careful selection of Initiate Tags is also necessary to prevent old duplicate packets from previous sessions being mistakenly processed as belonging to the current session. Moreover, the Tag value used by either agent in a given session MUST NOT change during the life time of a session. A new Verification Tag value MUST be used each time the agent tears down and then reestablishes a session to the same peer. 11. User Data Transfer Data transmission MUST only happen in the ESTABLISHED, SHUTDOWNPENDING states. DATA chunks MUST only be received according to the rules below in ESTABLISHED, SSHUTDOWN-PENDING, and SSHUTDOWN-SENT. A DATA chunk received in any other state SHOULD be discarded. A SACK MUST be processed in ESTABLISHED, and SSHUTDOWN-PENDING. A SACK in the CLOSED state is out of the blue and SHOULD be processed according to the rules in section 13.3. A SACK chunk received in any other state SHOULD be discarded. An MPMTP-AR receiver MUST be able to receive a minimum of 1500 bytes in one MPMTP-AR packet. This means that an MPMTP-AR agent MUST NOT indicate less than 1500 bytes in its initial a_rwnd sent in the SINIT ACK. For transmission efficiency, MPMTP-AR defines mechanisms for bundling of small user messages and fragmentation of large user messages. The following diagram depicts the flow of user messages through MPMTP-AR. Leiwm, et al. Expires January 28, 2014 [Page 50] Internet-Draft MPMTP-AR July 2013 +--------------------------+ | User Messages | +--------------------------+ MPMTP-AR user ^ | ==================|==|==================================== | v (1) +---------------------+ +-----------------------+ | MPMTP-AR DATA Chunks| |MPMTP-AR Control Chunks| +---------------------+ +-----------------------+ ^ | ^ | | v (2) | v (2) +--------------------------+ | MPMTP-AR packets | +--------------------------+ MPMTP-AR ^ | ===========================|==|=========================== | v Packet Transfer Service (e.g., UDP) Notes: When converting user messages into DATA chunks, an agent will fragment user messages larger than the current session path MTU into multiple DATA chunks. The data receiver will normally reassemble the fragmented message from DATA chunks before delivery to the user (see section 11.7 for details). 11.1 Transmission of DATA Chunks This document is specified as if there is a single retransmission timer per subflow, but implementations MAY have a retransmission timer for each DATA packet. The following general rules MUST be applied by the sender for transmission and/or retransmission of outbound DATA chunks: A) At any given time, the data sender MUST NOT transmit new data if its peer's rwnd indicates that the peer has no buffer space (i.e., rwnd is 0; see section 11.2.1). However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by congestion window (cwnd). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK's having been lost in transit from the data receiver to the data sender. When the receiver's advertised window is zero, this probe is called a zero window probe. Note that a zero window probe SHOULD only be sent when all outstanding DATA chunks have been cumulatively acknowledged and no DATA chunks are in flight. Zero window probing MUST be supported. Leiwm, et al. Expires January 28, 2014 [Page 51] Internet-Draft MPMTP-AR July 2013 Refer to section 11.2 on the receiver behavior when it advertises a zero window. The sender SHOULD send the first zero window to probe after 1 RTO when it detects that the receiver has closed its window and SHOULD increase the probe interval exponentially afterwards. Also note that the cwnd SHOULD be adjusted according to section 12.2.1. Zero window probing does not affect the calculation of cwnd. The sender MUST also have an algorithm for sending new DATA chunks to avoid silly window syndrome (SWS) as described in [RFC0813]. The algorithm can be similar to the one described in section 4.2.3.4 of [RFC1122]. However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd. This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK having been lost in transit from the data receiver to the data sender. B) At any given time, the sender MUST NOT transmit new data to the receiver if it has cwnd or more bytes of data outstanding to the receiver. C) When the time comes for the sender to transmit, before sending new DATA chunks, the sender MUST first transmit any outstanding DATA chunks that are marked for retransmission (limited by the current cwnd). D) When the time comes for the sender to transmit new DATA chunks, the protocol parameter Max.Burst SHOULD be used to limit the number of packets sent. The limit MAY be applied by adjusting cwnd as follows: if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize +Max.Burst*MTU Or it MAY be applied by strictly limiting the number of packets emitted by the output routine. E) Then, the sender can send out as many new DATA chunks as rule A and rule B allow. IMPLEMENTATION NOTE: When the window is full, the sender MAY still accept send requests from its user, but MUST transmit no more DATA chunks until some or all of the outstanding DATA chunks are acknowledged and transmission is allowed by rule A and rule B again. Whenever a transmission or retransmission is made, the sender MUST Leiwm, et al. Expires January 28, 2014 [Page 52] Internet-Draft MPMTP-AR July 2013 start T3-rtx timer. If the timer is already running, the sender MUST restart the timer if the earliest (i.e., lowest TSN) outstanding DATA chunk is being retransmitted. Otherwise, the data sender MUST NOT restart the timer. When starting or restarting the T3-rtx timer, the timer value must be adjusted according to the timer rules defined in Sections 11.3.2 and 11.3.3. Note: The data sender SHOULD NOT use a TSN that is more than 2**31-1 above the beginning TSN of the current send window. 11.2 Acknowledge on Reception of DATA Chunks The MPMTP-AR agent MUST always acknowledge the reception of each valid DATA chunk when the DATA chunk received is inside its receive window. When the receiver's advertised window is 0, the receiver MUST drop any new incoming DATA chunk with a TSN larger than the largest TSN received so far. If the new incoming DATA chunk holds a TSN value less than the largest TSN received so far, then the receiver SHOULD drop the largest TSN held for reordering and accept the new incoming DATA chunk. In either case, if such a DATA chunk is dropped, the receiver MUST immediately send back a SACK with the current receive window showing only DATA chunks received and accepted so far. The dropped DATA chunk(s) MUST NOT be included in the SACK, as they were not accepted. The receiver MUST also have an algorithm for advertising its receive window to avoid receiver silly window syndrome (SWS), as described in [RFC0813]. The algorithm can be similar to the one described in section 4.2.3.3 of [RFC1122]. The guidelines on delayed acknowledgement algorithm specified in section 4.2 of [RFC2581] SHOULD be followed. Specifically, an acknowledgement SHOULD be generated for at least every second packet (not every second DATA chunk) received, and SHOULD be generated within 200 ms of the arrival of any unacknowledged DATA chunk. In some situations, it may be beneficial for an MPMTP-AR transmitter to be more conservative than the algorithms detailed in this document allow. However, an MPMTP-AR transmitter MUST NOT be more aggressive than the following algorithms allow. An MPMTP-AR receiver MUST NOT generate more than one SACK for every incoming packet, other than to update the offered window as the receiving application consumes new data. IMPLEMENTATION NOTE: The maximum delay for generating an acknowledgement may be configured by the MPMTP-AR administrator, Leiwm, et al. Expires January 28, 2014 [Page 53] Internet-Draft MPMTP-AR July 2013 either statically or dynamically, in order to meet the specific timing requirement of the protocol being carried. An implementation MUST NOT allow the maximum delay to be configured to be more than 500 ms. In other words, an implementation MAY lower this value below 500 ms but MUST NOT raise it above 500 ms. Acknowledgements MUST be sent in SACK chunks unless session-level shutdown was requested by user, in which case an agent MAY send an acknowledgement in the session-level SSHUTDOWN chunk. A SACK chunk can acknowledge the reception of multiple DATA chunks.See section 8.3.10 for SACK chunk format. In particular, the MPMTP-AR agent MUST fill in the Cumulative TSN Ack field to indicate the latest sequential TSN (of a valid DATA chunk) it has received. Any received DATA chunks with TSN greater than the value in the Cumulative TSN Ack field are reported in the Gap Ack Block fields. The MPMTP-AR agent MUST report as many Gap Ack Blocks as can fit in a single SACK chunk limited by the current path MTU. When a packet arrives with duplicate DATA chunk, the agent MUST immediately send a SACK with no delay. The duplicate TSN number(s) SHOULD be reported in the SACK as duplicate. When an agent receives a SACK, it MAY use the duplicate TSN information to determine if SACK loss is occurring. Further use of this data is for future study. The data receiver is responsible for maintaining its receive buffers. The data receiver SHOULD notify the data sender in a timely manner of changes in its ability to receive data. How an implementation manages its receive buffers is dependent on many factors (e.g., operating system, memory management system, amount of memory, etc.). However, the data sender strategy defined in section 11.2.1 is based on the assumption of receiver operation similar to the following: A) At initialization of the session, the agent tell the peer how much receive buffer space it has allocated to the session in the SINIT ACK. The agent sets a_rwnd to this value. B) As DATA chunks are received and buffered, decrement a_rwnd by the number of bytes received and buffered. This is, in effect, closing rwnd at the data sender and restricting the amount of data it can transmit. C) As DATA chunks are delivered to the MPMTP-AR user and released from the receive buffers, increment a_rwnd by the number of bytes. This is, in effect, opening up rwnd on the data sender and allowing it to send more data. The data receiver SHOULD NOT Leiwm, et al. Expires January 28, 2014 [Page 54] Internet-Draft MPMTP-AR July 2013 increment a_rwnd unless it has released bytes from its receive buffer. For example, if the receiver is holding fragmented DATA chunks in a reassembly queue,it should not increment a_rwnd. D) When sending a SACK, the data receiver SHOULD place the current value of a_rwnd into the a_rwnd field. The data receiver SHOULD take into account that the data sender will not retransmit DATA chunks that are acked via the Cumulative TSN Ack (i.e., will drop from its retransmit queue). Under certain circumstances, the data receiver may need to drop DATA chunks that it has received but hasn't released from its receive buffers (i.e., delivered to the MPMTP-AR user). These DATA chunks may have been acked in Gap Ack Blocks. For example, the data receiver may be holding data in its receive buffers while reassembling a fragmented user message from its peer when it runs out of receive buffer space. It may drop these DATA chunks even though it has acknowledged them in Gap Ack Blocks. If a data receiver drops DATA chunks, it MUST NOT include them in Gap Ack Blocks in subsequent SACKs until they are received again via retransmission. In addition, the agent should take into account the dropped data when calculating its a_rwnd. An agent SHOULD NOT revoke a SACK and discard data. Only in extreme circumstances should an agent use this procedure (such as out of buffer space). The data receiver should take into account that dropping data that has been acked in Gap Ack Blocks can result in suboptimal retransmission strategies in the data sender and thus in suboptimal performance. If an agent receives a DATA chunk with no user data (i.e., the Length field is set to 16), it MUST send an ABORT with error cause set to "No User Data". An agent SHOULD NOT send a DATA packet with no user data. 11.2.1 Processing a Received SACK Each SACK an agent receives contains an a_rwnd value. This value represents the amount of buffer space the data receiver, at the time of transmitting the SACK, has left of its total receive buffer space (as specified in the SINIT/SINIT ACK). Using a_rwnd, Cumulative TSN Ack, and Gap Ack Blocks, the data sender can develop a representation of the peer's receive buffer space. One of the problems the data sender must take into account when processing a SACK is that a SACK can be received out of order. That is, a SACK sent by the data receiver can pass an earlier SACK and be Leiwm, et al. Expires January 28, 2014 [Page 55] Internet-Draft MPMTP-AR July 2013 received first by the data sender. If a SACK is received out of order, the data sender can develop an incorrect view of the peer's receive buffer space. Since there is no explicit identifier that can be used to detect out-of-order SACKs, the data sender must use heuristics to determine if a SACK is new. An agent SHOULD use the following rules to calculate the rwnd, using the a_rwnd value, the Cumulative TSN Ack, and Gap Ack Blocks in a received SACK. A) At the establishment of the session, the agent initializes the rwnd to the Advertised Receiver Window Credit (a_rwnd) the peer specified in the SINIT or SINIT ACK. B) Any time a DATA chunk is transmitted (or retransmitted) to a peer, the agent subtracts the data size of the chunk from the rwnd of that peer. C) Any time a DATA chunk is marked for retransmission, either via T3-rtx timer expiration (section 11.3.3) or via Fast Retransmit (section 12.2.4); add the data size of those chunks to the rwnd. Note: If the implementation is maintaining a timer on each DATA chunk , then only DATA chunks whose timer expired would be marked for retransmission. D) Any time a SACK arrives, the agent performs the following: i) If Cumulative TSN Ack is less than the Cumulative TSN Ack Point, then drop the SACK. Since Cumulative TSN Ack is monotonically increasing, a SACK whose Cumulative TSN Ack is less than the Cumulative TSN Ack Point indicates an out-oforder SACK. ii) Set rwnd equal to the newly received a_rwnd minus the number of bytes still outstanding after processing the Cumulative TSN Ack and the Gap Ack Blocks. iii) If the SACK is missing a TSN that was previously acknowledged via a Gap Ack Block (e.g., the data receiver reneged on the data), then consider the corresponding DATA that might be possibly missing.Count one miss indication towards Fast Retransmit as described in section 12.2.4, and if no retransmit timer is running for the subflow to which the DATA chunk was originally transmitted, then T3-rtx is started for that destination address. Leiwm, et al. Expires January 28, 2014 [Page 56] Internet-Draft MPMTP-AR July 2013 iv) If the Cumulative TSN Ack matches or exceeds the Fast Recovery exitpoint (section 12.2.4), Fast Recovery is exited. 11.3 Management of Retransmission Timer An MPMTP-AR agent uses a retransmission timer T3-rtx to ensure data delivery in the absence of any feedback from its peer. The duration of this timer is referred to as RTO (retransmission timeout). When an session is multi-path, the agent will calculate a separate RTO for each different path. The computation and management of RTO in MPMTP-AR follow closely how TCP manages its retransmission timer. To compute the current RTO, an agent maintains two state variables per subflow: SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation). 11.3.1 RTO Calculation The rules governing the computation of SRTT, RTTVAR, and RTO are as follows: C1)Until an RTT measurement has been made for a packet sent to the given destination transport address, set RTO to the protocol arameter 'RTO.Initial'. C2)When the first RTT measurement R is made, set SRTT <- R, RTTVAR <- R/2, and RTO <- SRTT + 4 * RTTVAR. C3) When a new RTT measurement R' is made, set RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| and SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R' Note: The value of SRTT used in the update to RTTVAR is its value before updating SRTT itself using the second assignment. After the computation, update RTO <- SRTT + 4 * RTTVAR. C4)When data is in flight and when allowed by rule C5 below, a new Leiwm, et al. Expires January 28, 2014 [Page 57] Internet-Draft MPMTP-AR July 2013 RTT measurement MUST be made each round trip. Furthermore, new RTT measurements SHOULD be made no more than once per round trip for a given subflow. There are two reasons for this recommendation: First, it appears that measuring more frequently often does not in practice yield any significant benefit [ALLMAN99]; second, if measurements are made more often, then the values of RTO.Alpha and RTO.Beta in rule C3 above should be adjusted so that SRTT and RTTVAR still adjust to changes at roughly the same rate (in terms of how many round trips it takes them to reflect new values) as they would if making only one measurement per round-trip and using RTO.Alpha and RTO.Beta as given in rule C3. However, the exact nature of these adjustments remains a research issue. C5)Karn's algorithm: RTT measurements MUST NOT be made using packets that were retransmitted (and thus for which it is ambiguous whether the reply was for the first instance of the chunk or for a later instance) IMPLEMENTATION NOTE: RTT measurements should only be made using a chunk with TSN r if no chunk with TSN less than or equal to r is retransmitted since r is first sent. C6)Whenever RTO is computed, if it is less than RTO.Min seconds then it is rounded up to RTO.Min seconds. The reason for this rule is that RTOs that do not have a high minimum value are susceptible to unnecessary timeouts [ALLMAN99]. C7) A maximum value may be placed on RTO provided it is at least RTO.max seconds. There is no requirement for the clock granularity G used for computing RTT measurements and the different state variables, other than: G1) Whenever RTTVAR is computed, if RTTVAR = 0, then adjust RTTVAR <-G. Experience [ALLMAN99] has shown that finer clock granularities (<=100 msec) perform somewhat better than more coarse granularities. 11.3.2 Retransmission Timer Rules The rules for managing the retransmission timer are as follows: R1)Every time a DATA chunk is sent to subflow (including a retransmission), if the T3-rtx timer of that subflow is not running, start it running so that it will expire after the RTO of that subflow. The RTO used here is that obtained after any Leiwm, et al. Expires January 28, 2014 [Page 58] Internet-Draft MPMTP-AR July 2013 doubling due to revious T3-rtx timer expirations on the corresponding subflow as discussed in rule E2 below. R2)Whenever all outstanding data sent to subflow have been acknowledged, turn off the T3-rtx timer of that subflow. R3)Whenever a SACK is received that acknowledges the DATA chunk with the earliest outstanding TSN for that subflow, restart the T3-rtx timer for that subflow with its current RTO (if there is still outstanding data on that subflows). R4)Whenever a SACK is received missing a TSN that was previously acknowledged via a Gap Ack Block, start the T3-rtx for the subflow to which the DATA chunk was originally transmitted if it is not already running. 11.3.3 Handle T3-RTX Expiration Whenever the retransmission timer T3-rtx expires for a subflow, do the following: E1)For the subflow for which the timer expires, adjust its ssthresh with rules defined in section 12.2.3 and set the cwnd <- MTU. E2)For the subflow for which the timer expires, set RTO<- RTO * 2 ("back off the timer"). The maximum value discussed in rule C7 above (RTO.max) may be used to provide an upper bound to this doubling operation. E3)Determine how many of the earliest (i.e., lowest TSN) outstanding DATA chunks for the subflow for which the T3-rtx has expired will fit into a single packet, subject to the MTU constraint for the path corresponding to the subflow to which the retransmission is being sent (this may be different from the subflow for which the timer expires; see section 11.4). Call this value K. Bundle and retransmit those K DATA chunks in a single packet to the destination agent. E4)Start the retransmission timer T3-rtx on the subflow to which the retransmission is sent, if rule R1 above indicates to do so. The\ RTO to be used for starting T3-rtx should be the one for the subflow to which the retransmission is sent, may be different from the subflow for which the timer expired (see section 11.4 below). After retransmitting, once a new RTT measurement is obtained (which can happen only when new data has been sent and acknowledged, per rule C5, or for a measurement made from a HEARTBEAT; see section 11.3), the computation in rule C3 is Leiwm, et al. Expires January 28, 2014 [Page 59] Internet-Draft MPMTP-AR July 2013 performed, including the computation of RTO, which may result in "collapsing" RTO back down after it has been subject to doubling (rule E2). Note: Any DATA chunks that were sent to the subflow for which the T3-rtx timer expired but did not fit in one MTU (rule E3 above) should be marked for retransmission and sent as soon as cwnd allows (normally, when a SACK arrives). F1)Whenever an agent switches from the current subflow to a different one, the current retransmission timers are left running. As soon as the agent transmits a packet containing DATA chunk(s) to the new subflow, start the timer on that subflow, using the RTO value of the destination address to which the data is being sent, if rule R1 indicates to do so. 11.4 Stream Identifier and Stream Sequence Number Every DATA chunk MUST carry a valid stream identifier. If an agent receives a DATA chunk with an invalid stream identifier, it shall acknowledge the reception of the DATA chunk following the normal procedure, immediately send an ERROR chunk with cause set to "Invalid Stream Identifier", and discard the DATA chunk. The Stream Sequence Number in all the streams MUST start from 0 when the session is established. Also, when the Stream Sequence Number reaches the value 65535 the next Stream Sequence Number MUST be set to 0. 11.5 Ordered and Unordered Delivery Within a stream, an agent MUST deliver DATA chunks received with the U flag set to 0 to the user according to the order of their Transmission Sequence Number. If DATA chunks arrive out of order of their Transmission Sequence Number, the agent MUST hold the received DATA chunks from delivery to the user until they are reordered. However, an MPMTP-AR agent can indicate that no ordered delivery is required for a particular DATA chunk transmitted within the stream by setting the U flag of the DATA chunk to 1. When an agent receives a DATA chunk with the U flag set to 1, it must bypass the ordering mechanism and immediately deliver the data to the user (after reassembly if the user data is fragmented by the data sender). This provides an effective way of transmitting "out-of-band" data in a given subflow. Also, a message can be used as an "unordered" stream Leiwm, et al. Expires January 28, 2014 [Page 60] Internet-Draft MPMTP-AR July 2013 by simply setting the U flag to 1 in all DATA chunks sent through that stream. IMPLEMENTATION NOTE: When sending an unordered DATA chunk, an implementation may choose to place the DATA chunk in an outbound packet that is at the head of the outbound transmission queue if possible. The 'Transmission Sequence Number' field in a DATA chunk with U flag set to 1 has no significance. The sender can fill it with arbitrary value, but the receiver MUST ignore the field. Note: When transmitting ordered and unordered data, an agent does not increment its Transmission Sequence Number when transmitting a DATA chunk with U flag set to 1. 11.6 Report Gaps in Received DATA TSNs Upon the reception of a new DATA chunk, an agent shall examine the continuity of the TSNs received. If the agent detects a gap in the received DATA chunk sequence, it SHOULD send a SACK with Gap Ack Blocks immediately. The data receiver continues sending a SACK after receipt of each MPMTP-AR packet that doesn't fill the gap. Based on the Gap Ack Block from the received SACK, the agent can calculate the missing DATA chunks and make decisions on whether to retransmit them (see section 11.2.1 for details). Multiple gaps can be reported in one single SACK. When this session is multipath, the MPMTP-AR agent SHOULD always try to send the SACK to the sender from default path. Upon the reception of a SACK, the agent MUST remove all DATA chunks that have been acknowledged by the SACK's Cumulative TSN Ack from its transmit queue. The agent MUST also treat all the DATA chunks with TSNs not included in the Gap Ack Blocks reported by the SACK as "missing". The number of "missing" reports for each outstanding DATA chunk MUST be recorded by the data sender in order to make retransmission decisions. See section 12.2.4 for details. The maximum number of Gap Ack Blocks that can be reported within a single SACK chunk is limited by the current path MTU. When a single SACK cannot cover all the Gap Ack Blocks needed to be reported due to the MTU limitation, the agent MUST send only one SACK, reporting the Gap Ack Blocks from the lowest to highest TSNs, within the size limit Leiwm, et al. Expires January 28, 2014 [Page 61] Internet-Draft MPMTP-AR July 2013 set by the MTU, and leave the remaining highest TSN numbers unacknowledged. 11.7 Fragmentation and Reassembly An agent MAY support fragmentation when sending DATA chunks, but it MUST support reassembly when receiving DATA chunks. If an agent supports fragmentation, it MUST fragment a user message if the size of the user message to be sent causes the outbound MPMTP-AR packet size to exceed the current MTU. If an implementation does not support fragmentation of outbound user messages, the agent MUST return an error to its user and not attempt to send the user message. Note: If an implementation that supports fragmentation makes available to its user a mechanism to turn off fragmentation, it may do so. However, in so doing, it MUST react just like an implementation that does NOT support fragmentation, i.e., it MUST reject sends that exceed the current Path MTU (P-MTU). If its session uses multipath, the agent shall choose a size no larger than the session Path MTU. The session Path MTU is the smallest Path MTU of all subflow. Note: Once a message is fragmented, it cannot be re-fragmented. Instead, if the PMTU has been reduced, then IP fragmentation must be used. Please see section 12.3 for details of PMTU discovery. When determining when to fragment, the MPMTP-AR implementation MUST take into account the MPMTP-AR packet header as well as the DATA chunk header(s). The implementation MUST also take into account the space required for a SACK chunk if bundling a SACK chunk with the DATA chunk. Fragmentation takes the following steps: 1) The data sender MUST break the user message into a series of DATA chunks such that each chunk plus MPMTP-AR overhead and UDP header fits into an IP datagram smaller than or equal to the session Path MTU. 2) The transmitter MUST then assign, in sequence, a separate TSN to each of the DATA chunks in the series. If the user indicates that the user message is to be delivered using unordered delivery, then the U flag of each DATA chunk of the user message MUST be set to 1. 3) The transmitter MUST also set the B/E bits of the first DATA chunk in the series to '10', the B/E bits of the last DATA chunk in the Leiwm, et al. Expires January 28, 2014 [Page 62] Internet-Draft MPMTP-AR July 2013 series to '01', and the B/E bits of all other DATA chunks in the series to '00'. An agent MUST recognize fragmented DATA chunks by examining the B/E bits in each of the received DATA chunks, and queue the fragmented DATA chunks for reassembly. Note: If the data receiver runs out of buffer space while still waiting for more fragments to complete the reassembly of the message, it should dispatch part of its inbound message through a partial delivery API, freeing some of its receive buffer space so that the rest of the message may be received. 12. Congestion Control Congestion control is one of the basic functions in MPMTP-AR. For some applications, it may be likely that adequate resources will be allocated to MPMTP-AR traffic to ensure prompt delivery of time-critical data -- thus, it would appear to be unlikely, during normal operations, that transmissions encounter severe congestion conditions. However, MPMTP-AR must operate under adverse operational conditions, which can develop upon partial network failures or unexpected traffic surges. In such situations, MPMTP-AR must follow correct congestion control steps to recover from congestion quickly in order to get data delivered as soon as possible. In the absence of network congestion, these preventive congestion control algorithms should show no impact on the protocol performance. IMPLEMENTATION NOTE: As far as its specific performance requirements are met, an implementation is always allowed to adopt a more conservative congestion control algorithm than the one defined below. The congestion control algorithms used by MPMTP-AR are based on [RFC2581]. This section describes how the algorithms defined in [RFC2581] are adapted for use in MPMTP-AR. We first list differences in protocol designs between TCP and MPMTP-AR, and then describe MPMTP-AR's congestion control scheme. The description will use the same terminology as in TCP congestion control whenever appropriate. MPMTP-AR congestion control is always applied to both the entire session and individual subflow. 12.1 MPMTP-AR Differences from TCP Congestion Control Gap Ack Blocks in the MPMTP-AR SACK carry the same semantic meaning as the TCP SACK. TCP considers the information carried in the SACK as advisory information only. MPMTP-AR considers the information carried in the Gap Ack Blocks in the SACK chunk as advisory. In MPMTP-AR, any DATA chunk that has been acknowledged by SACK, including DATA that Leiwm, et al. Expires January 28, 2014 [Page 63] Internet-Draft MPMTP-AR July 2013 arrived at the receiving end out of order, is not considered fully delivered until the Cumulative TSN Ack Point passes the TSN of the DATA chunk (i.e., the DATA chunk has been acknowledged by the Cumulative TSN Ack field in the SACK). Consequently, the value of cwnd controls the amount of outstanding data, rather than (as in the case of non-SACK TCP) the upper bound between the highest acknowledged sequence number and the latest DATA chunk that can be sent within the congestion window. MPMTP-AR SACK leads to different implementations of Fast Retransmit and Fast Recovery than non-SACK TCP. As an example, see [FALL96]. The biggest difference between MPMTP-AR and TCP, however, is multipath. MPMTP-AR is designed to establish robust communication sessuib between two endpoints more than one path. The treatment here of congestion control for multihpath receivers is new with MPMTP-AR and may require refinement in the future. The current algorithms make the following assumptions: 1) The sender usually uses the same subflows until being instructed by the user to switch to other subflows; however, MPMTP-AR may switch load to other subflows in the event a path is marked inactive (see section 13.2). 2) The sender keeps a separate congestion control parameter set for each subflow it use. The parameters should decay if the subflow is not used for a long enough time period. The sender SHOULD adjust the entire session congestion control parameter according to all subflows' congestion control parameter; the specific rules will be refined in the future. 3) For each subflow, an agent does slow start upon the first transmission to that address. 12.2 MPMTP-AR Slow-Start and Congestion Avoidance The slow-start and congestion avoidance algorithms MUST be used by an agent to control the amount of data being injected into the network. The congestion control in MPMTP-AR is employed in regard not only to the session, but also to an individual subflow. In some situations, it may be beneficial for an MPMTP-AR sender to be more conservative than the algorithms allow; however, an MPMTP-AR sender MUST NOT be more aggressive than the following algorithms allow. Like TCP, an MPMTP-AR agent uses the following three control variables to regulate its transmission rate. 1) Receiver advertised window size (rwnd, in bytes), which is set by the receiver based on its available buffer space for incoming Leiwm, et al. Expires January 28, 2014 [Page 64] Internet-Draft MPMTP-AR July 2013 packets. Note: This variable is kept on the entire session. 2) Congestion control window (cwnd, in bytes), which is adjusted by the sender based on observed network conditions. Note: This variable is maintained on a per-subflow basis. 3) Slow-start threshold (ssthresh, in bytes), which is used by the sender to distinguish slow-start and congestion avoidance phases. Note: This variable is maintained on a per-subflow basis. MPMTP-AR also requires one additional control variable, partial_bytes_acked, which is used during congestion avoidance phase to facilitate cwnd adjustment. Unlike TCP, an MPMTP-AR sender MUST keep a set of these control variables cwnd, ssthresh, and partial_bytes_acked for EACH subflow. Only one rwnd is kept for the whole session. 12.2.1 Slow-Start Beginning data transmission into a network with unknown conditions or after a sufficiently long idle period requires MPMTP-AR to probe the network to determine the available capacity. The slow-start algorithm is used for this purpose at the beginning of a transfer, or after repairing loss detected by the retransmission timer. 1) The initial cwnd before DATA transmission or after a sufficiently long idle period MUST be set to min(4*MTU, max (2*MTU, 4488 bytes)). 2) The initial cwnd after a retransmission timeout MUST be no more than 1*MTU. 3) The initial value of ssthresh MAY be arbitrarily high (for example, implementations MAY use the size of the receiver advertised window). 4) Whenever cwnd is greater than zero, the agent is allowed to have cwnd bytes of data outstanding on that subflow. 5) When cwnd is less than or equal to ssthresh, an MPMTP-AR agent MUST use the slow-start algorithm to increase cwnd only if the current congestion window is being fully utilized, an incoming SACK advances the Cumulative TSN Ack Point, and the data sender is Leiwm, et al. Expires January 28, 2014 [Page 65] Internet-Draft MPMTP-AR July 2013 not in Fast Recovery. Only when these three conditions are met can the cwnd be increased; otherwise, the cwnd MUST not be increased. If these conditions are met, then cwnd MUST be increased by, atmost, the lesser of 1) the total size of the previously outstanding DATA chunk(s) acknowledged, and 2) the destination's path MTU. This upper bound protects against the ACK-Splitting attack outlined in [SAVAGE99]. In instances where its session is multipath, if an agent receives a SACK that advances its Cumulative TSN Ack Point, then it should update its cwnd (or cwnds). However, if the received SACK does not advance the Cumulative TSN Ack Point, the agent MUST NOT adjust the cwnd of any subflow. Because an agent's cwnd is not tied to its Cumulative TSN Ack Point, as duplicate SACKs come in, even though they may not advance the Cumulative TSN Ack Point an agent can still use them to clock out new data. That is, the data newly acknowledged by the SACK diminishes the amount of data now in flight to less than cwnd, and so the current, unchanged value of cwnd now allows new data to be sent. On the other hand, the increase of cwnd must be tied to the Cumulative TSN Ack Point advancement as specified above. Otherwise, the duplicate SACKs will not only clock out new data, but also will adversely clock out more new data than what has just left the network, during a time of possible congestion. 6) When the agent does not transmit data on a given subflow, the cwnd of the subflow should be adjusted to max(cwnd/2, 4*MTU) per RTO. 12.2.2 Congestion Avoidance When cwnd is greater than ssthresh, cwnd should be incremented by 1*MTU per RTT if the sender has cwnd or more bytes of data outstanding for the corresponding subflow. In practice, an implementation can achieve this goal in the following way: 1) partial_bytes_acked is initialized to 0. 2) Whenever cwnd is greater than ssthresh, upon each SACK arrival that advances the Cumulative TSN Ack Point, increase partial_bytes_acked by the total number of bytes of all new chunks in this subflow acknowledged in that SACK including chunks acknowledged by the new Cumulative TSN Ack and by Gap Ack Blocks. 3) When partial_bytes_acked is equal to or greater than cwnd and before the arrival of the SACK the sender had cwnd or more bytes Leiwm, et al. Expires January 28, 2014 [Page 66] Internet-Draft MPMTP-AR July 2013 of data outstanding (i.e., before arrival of the SACK, flightsize was greater than or equal to cwnd), increase cwnd by MTU, and reset partial_bytes_acked to (partial_bytes_acked - cwnd). 4) Same as in the slow start, when the sender does not transmit DATA on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd / 2, 4*MTU) per RTO. 5) When all of the data transmitted by the sender has been acknowledged by the receiver, partial_bytes_acked is initialized to 0. 12.2.3 Congestion Control Upon detection of packet losses from SACK (see section 12.2.4), an agent should do the following: ssthresh = max(cwnd/2, 4*MTU) cwnd = ssthresh partial_bytes_acked = 0 Basically, a packet loss causes cwnd to be cut in half. When the T3-rtx timer expires on a subflow, MPMTP-AR should perform slow start by: ssthresh = max(cwnd/2, 4*MTU) cwnd = 1*MTU and ensure that no more than one MPMTP-AR packet will be in flight for that subflow until the agent receives acknowledgement for successful delivery of data to that subflow. 12.2.4 Fast Retransmit on Gap Reports In the absence of data loss, an agent performs delayed acknowledgement. However, whenever an agent notices a hole in the arriving TSN sequence, it SHOULD start sending a SACK back every time a packet arrival carrying data until the hole is filled. Whenever an agent receives a SACK that indicates that some TSNs are missing, it SHOULD wait for two further miss indications (via subsequent SACKs for a total of three missing reports) on the same TSNs before taking action with regard to Fast Retransmit. Leiwm, et al. Expires January 28, 2014 [Page 67] Internet-Draft MPMTP-AR July 2013 Miss indications SHOULD follow the HTNA (Highest TSN Newly Acknowledged) algorithm. For each incoming SACK, miss indications are incremented only for missing TSNs prior to the highest TSN newly acknowledged in the SACK. A newly acknowledged DATA chunk is one not previously acknowledged in a SACK. If an agent is in Fast Recovery and a SACK arrives that advances the Cumulative TSN Ack Point, the miss indications are incremented for all TSNs reported missing in the SACK. When the third consecutive miss indication is received for a TSN(s), the data sender shall do the following: 1) Mark the DATA chunk(s) with three miss indications for retransmission. 2) If not in Fast Recovery, adjust the ssthresh and cwnd of the subflow(es) to which the missing DATA chunks were last sent, according to the formula described in section 12.2.3. 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks marked for retransmission will fit into a single packet, subject to constraint of the path MTU of the subflow to which the packet is being sent. Call this value K. Retransmit those K DATA chunks in a single packet. When a Fast Retransmit is being performed, the sender SHOULD ignore the value of cwnd and SHOULD NOT delay retransmission for this single packet. 4) Restart the T3-rtx timer only if the last SACK acknowledged the lowest outstanding TSN number sent to that subflow, or the agent is retransmitting the first outstanding DATA chunk sent to that subflow. 5) Mark the DATA chunk(s) as being fast retransmitted and thus ineligible for a subsequent Fast Retransmit. Those TSNs marked for retransmission due to the Fast-Retransmit algorithm that did not fit in the sent datagram carrying K other TSNs are also marked as ineligible for a subsequent Fast Retransmit. However, as they are marked for retransmission they will be retransmitted later on as soon as cwnd allows. 6) If not in Fast Recovery, enter Fast Recovery and mark the highest outstanding TSN as the Fast Recovery exit point. When a SACK acknowledges all TSNs up to and including this exit point, Fast Recovery is exited. While in Fast Recovery, the ssthresh and cwnd SHOULD NOT change for any path due to a subsequent Fast Recovery event (i.e., one SHOULD NOT reduce the cwnd further due to a subsequent Fast Retransmit). Leiwm, et al. Expires January 28, 2014 [Page 68] Internet-Draft MPMTP-AR July 2013 Note: Before the above adjustments, if the received SACK also acknowledges new DATA chunks and advances the Cumulative TSN Ack Point, the cwnd adjustment rules defined in section 12.2.1 and section 12.2.2 must be applied first. A straightforward implementation of the above keeps a counter for each TSN hole reported by a SACK. The counter increases for each consecutive SACK reporting the TSN hole. After reaching 3 and starting the Fast-Retransmit procedure, the counter resets to 0. Because cwnd in MPMTP-AR indirectly bounds the number of outstanding TSN's, the effect of TCP Fast Recovery is achieved automatically with no adjustment to the congestion control window size. 12.3 Path MTU Discovery [RFC4821], [RFC1981], and [RFC1191] specify "Packetization Layer Path MTU Discovery", whereby an agent maintains an estimate of the maximum transmission unit (MTU) along a given Internet path and refrains from sending packets along that path that exceed the MTU, other than occasional attempts to probe for a change in the Path MTU (PMTU). [RFC4821] is thorough in its discussion of the MTU discovery mechanism and strategies for determining the current end-to-end MTU setting as well as detecting changes in this value. An agent SHOULD apply these techniques, and SHOULD do so on a per-path basis. There are two important MPMTP-AR-specific points regarding Path MTU discovery: 1) MPMTP-AR session can span multiple paths. An agent MUST maintain separate MTU estimates for each path. 2) The sender should track an session PMTU that will be the smallest PMTU discovered for all paths. When fragmenting messages into multiple parts this session PMTU should be used to calculate the size of each fragment. This will allow retransmissions to be seamlessly sent to an alternate path without encountering IP fragmentation. 13. Fault Management 13.1 Endpoint Failure Detection An agent shall keep a counter on the total number of consecutive retransmissions to its peer (this includes retransmissions to all paths). If the value of this counter exceeds the limit indicated in the protocol parameter 'Session.Max.Retrans', the agent shall Leiwm, et al. Expires January 28, 2014 [Page 69] Internet-Draft MPMTP-AR July 2013 consider the peer agent unreachable and shall stop transmitting any more data to it (and thus the session enters the CLOSED state). In addition, the agent MAY report the failure to the MPMTP-AR user and optionally report back all outstanding user data remaining in its outbound queue. The session is automatically closed when the peer agent becomes unreachable. The counter shall be reset each time a DATA chunk sent to that peer agent is acknowledged (by the reception of a SACK) from the peer agent. 13.2 Path Failure Detection When the session is multipath, an agent should keep an error counter for each path. Each time the T3-rtx timer expires on any path, the error counter of that path will be incremented. When the value in the error counter exceeds the protocol parameter 'Path.Max.Retrans' of that path, the agent should mark the destination transport address as inactive, and a notification SHOULD be sent to the MPMTP-AR user. When an outstanding TSN is acknowledged, the agent shall clear the error counter of the path to which the DATA chunk was last sent. When the session is multipath and the last chunk sent to it was a retransmission to an alternate path, there exists an ambiguity as to whether or not the acknowledgement should be credited to the address of the last chunk sent. However, this ambiguity does not seem to bear any significant consequence to MPMTP-AR behavior. If this ambiguity is undesirable, the transmitter may choose not to clear the error counter if the last chunk sent was a retransmission. Note: When configuring the MPMTP-AR agent, the user should avoid having the value of 'Session.Max.Retrans' larger than the summation of the 'Path.Max.Retrans' of all paths for the remote agent. Otherwise, all paths may become inactive while the agent still considers the peer agent reachable. When this condition occurs, how MPMTP-AR chooses to function is implementation specific. When the primary path is marked inactive (due to excessive retransmissions, for instance), the sender MAY automatically transmit new packets to alternate paths if they exist and are active. If more than one alternate path is active when the primary path is marked inactive, the sender may switch the load allocated to the inactive path to one or more active path. 13.3 Handle "Out of the Blue" Packets Leiwm, et al. Expires January 28, 2014 [Page 70] Internet-Draft MPMTP-AR July 2013 An MPMTP-AR packet is called an "out of the blue" (OOTB) packet if it is correctly formed, but the receiver is not able to identify the session to which this packet belongs. The receiver of an OOTB packet MUST do the following: 1) If the OOTB packet is to or from a non-unicast address, a receiver SHOULD silently discard the packet. Otherwise, 2) If the OOTB packet contains an ABORT chunk, the receiver MUST silently discard the OOTB packet and take no further action. Otherwise, 3) If the packet contains an SINIT chunk with a To Tag set to '0', process it as described in section 10.1. 4) If the packet contains a COOKIE ECHO chunk, process it as described in section 10.1. 5) If the packet contains a SSHUTDOWN ACK chunk, the receiver should respond to the sender of the OOTB packet with a SSHUTDOWN COMPLETE. 6) If the packet contains a SSHUTDOWN COMPLETE chunk, the receiver should silently discard the packet and take no further action. Otherwise, 7) If the packet contains a "Stale Cookie" ERROR or a COOKIE ACK, the MPMTP-AR packet should be silently discarded. Otherwise, 8) The receiver should respond to the sender of the OOTB packet with an ABORT. When sending the ABORT, the receiver of the OOTB packet MUST fill in the To Tag field of the outbound packet with the value found in the From Tag field of the OOTB packet. After sending this ABORT, the receiver of the OOTB packet shall discard the OOTB packet and take no further action. 13.4 Verification Tag The Tag rules defined in this section apply when sending or receiving MPMTP-AR packets The rules for sending and receiving MPMTP-AR packets containing one of these chunk types are discussed separately in section 13.4.1. When sending an MPMTP-AR packet, the agent MUST fill in the Tag fields of the outbound packet with the tag value in the Initiate Tag parameter of the SINIT or SINIT ACK received from its peer. Leiwm, et al. Expires January 28, 2014 [Page 71] Internet-Draft MPMTP-AR July 2013 When receiving an MPMTP-AR packet, the agent MUST ensure that the value in the To Tag field of the received MPMTP-AR packet matches its own tag. If the received Verification Tag value does not match the receiver's own tag value, the receiver shall silently discard the packet and shall not process it any further except for those cases listed in section 13.4.1 below. 13.4.1 Exceptions in Verification Tag Rules A) Rules for packet carrying SINIT: The sender MUST set the To Tag of the packet to 0. When an agent receives an MPMTP-AR packet with the To Tag set to 0, it should verify that the packet contains an INIT chunk. Otherwise, the receiver MUST silently discard the packet. B) Rules for packet carrying ABORT: The agent MUST always fill in the To Tag field of the outbound packet with the destination agent's tag value, if it is known. If the ABORT is sent in response to an OOTB packet, the agent MUST follow the procedure described in section 13.3. The receiver of an ABORT MUST accept the packet if the To Tag field of the packet matches its own tag. Otherwise, the receiver MUST silently discard the packet and take no further action. C) Rules for packet carrying SSHUTDOWN COMPLETE: When sending a SSHUTDOWN COMPLETE, if the receiver of the SSHUTDOWN ACK has a TCB, then the To tag MUST be used. Only where no TCB exists should the sender use the From Tag from the SSHUTDOWN ACK. The receiver of a SSHUTDOWN COMPLETE shall accept the packet if the To Tag field of the packet matches its own tag. Otherwise, the receiver MUST silently discard the packet and take no further action. An agent MUST ignore the SSHUTDOWN COMPLETE if it is not in the SSHUTDOWN ACK SENT state. D) Rules for packet carrying a COOKIE ECHO When sending a COOKIE ECHO, the agent MUST use the value of the From Tag received in theSINIT ACK. The receiver of a COOKIE ECHO follows the procedures in section 10. E) Rules for packet carrying a SSHUTDOWN ACK If the receiver is in COOKIE ECHOED or COOKIE WAIT state the procedures in section 13.3 SHOULD be followed; in other words, it Leiwm, et al. Expires January 28, 2014 [Page 72] Internet-Draft MPMTP-AR July 2013 should be treated as an Out Of The Blue packet. 14. Termination of Session An agent should terminate its session when it exits from service. A session can be terminated by either abort or session-level shutdown. An abort of a session is abortive by definition in that any data pending of the session is discarded and not delivered to the peer. A session-level shutdown is considered a graceful close where all data in queue by all subflow is delivered to the respective peers. When agent performs a session-level shutdown, the agent will stop accepting new data from its MPMTP-AR user; if the agent is a sender, it only delivers data in all subflow queues at the time of sending the SHUTDOWN chunk. 14.1 Abort of a Session When one agent decides to abort an existing session, it MUST send an ABORT chunk to its peer agent. The sender MUST fill in the peer's Tag in the outbound packet. An agent MUST NOT respond to any ABORT chunk (also see section 13.3). An agent receiving an ABORT MUST apply the special Tag check rules described in section 13.4.1. After checking the Tag, the receiving agent MUST remove the session from its record and SHOULD report the termination to MPMTP-AR user. If a User-Initiated Abort error cause is present in the ABORT chunk, the Abort Reason SHOULD be made available to the MPMTP-AR user. 14.2 Shutdown of a Session Using the session-level SSHUTDOWN, the MPMTP-AR user in a session can gracefully close a session. This will allow all outstanding DATA chunks to be delivered before the subflows terminate. According to the initiator, it includes sender-initialized and receiver-initialized. Upon receipt of the SSHUTDOWN primitive from MPMTP-AR user: For sender-initialized: The agent enters the SSHUTDOWN-PENDING state and remains there until all outstanding data has been acknowledged by its peer. The agent accepts no new data from user, but retransmits data to the peer agent if necessary to fill gaps. Once all its outstanding data has been acknowledged, the agent shall send a SSHUTDOWN chunk. It shall then start the T2-shutdown timer and enter the SSHUTDOWN-SENT state. If the timer expires, the agent must resend Leiwm, et al. Expires January 28, 2014 [Page 73] Internet-Draft MPMTP-AR July 2013 the SSHUTDOWN. For receiver-initialized: Upon receipt of the SSHUTDOWN primitive from MPMTP-AR user, the agent enters the SSHUTDOWN-PENDING state and remains there until all data has been received correctly. Once all data has been received correctly, the agent shall send a SSHUTDOWN chunk. It shall then start the T2-shutdown timer and enter the SSHUTDOWN-SENT state. If the timer expires, the agent must resend the SSHUTDOWN. The rules in section 11.3 MUST be followed to determine the proper timer value for T2-shutdown. An agent should limit the number of retransmissions of the SHUTDOWN chunk to the protocol parameter 'Session.Max.Retrans'. If this threshold is exceeded, the agent should destroy the TCB and MUST report the peer agent unreachable to the MPMTP-AR user (and thus the session enters the CLOSED state). Upon reception of the SSHUTDOWN, the agent shall enter the SSHUTDOWN-RECEIVED state. Once an agent has reached the SSHUTDOWN-RECEIVED state, it should discard subsequent SSHUTDOWN chunks. The sender of the SSHUTDOWN MAY also start an overall guard timer 'T5-shutdown-guard' to bound the overall time for the shutdown sequence. At the expiration of this timer, the sender SHOULD abort the session by sending an ABORT chunk. If the 'T5-shutdown-guard' timer is used, it SHOULD be set to the recommended value of 5 times 'RTO.Max'. The SSHUTDOWN receiver MUST send a SSHUTDOWN ACK and start a T2- shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If the timer expires, the agent must resend the SSHUTDOWN ACK. The sender of the SSHUTDOWN ACK should limit the number of retransmissions of the SSHUTDOWN ACK chunk to the protocol parameter 'Session.Max.Retrans'. If this threshold is exceeded, the agent should destroy the TCB and may report the peer agent unreachable to the MPMTP-AR user (and thus the session enters the CLOSED state). Upon the receipt of the SSHUTDOWN ACK, the SSHUTDOWN sender shall stop the T2-shutdown timer, send a SSHUTDOWN COMPLETE chunk to its peer, and remove all record of the session. Upon reception of the SSHUTDOWN COMPLETE chunk, the agent will verify that it is in the SSHUTDOWN-ACK-SENT state; if it is not, the chunk Leiwm, et al. Expires January 28, 2014 [Page 74] Internet-Draft MPMTP-AR July 2013 should be discarded. If the agent is in the SSHUTDOWN-ACK-SENT state, the agent should stop the T2-shutdown timer and remove all acknowledge of the session (and thus the session enters the CLOSED state). An agent SHOULD ensure that all its outstanding DATA chunks have been sent or received correctly before initiating the shutdown procedure. Note: Receipt of an SINIT with the same source assigned to an agent but with a different Tag indicates the initialization of a separate session. The sender of the SINIT or COOKIE ECHO should respond to the receipt of a SSHUTDOWN ACK with a stand-alone SSHUTDOWN COMPLETE in an MPMTP-AR packet with the Tag field of its common header set to the same tag that was received in the SSHUTDOWN ACK packet. This is considered an Out of the Blue packet as defined in section 13.3. The sender of the SINIT lets T1-init continue running and remains in the COOKIE-WAIT or COOKIE-ECHOED state. Normal T1-init timer expiration will cause the SINIT or COOKIE chunk to be retransmitted and thus start a new session. If a SSHUTDOWN is received in the COOKIE-WAIT or COOKIE ECHOED state, the SSHUTDOWN chunk SHOULD be silently discarded. In sender-initialized scenario: An agent should reject any new data request from its user if it is in the SSHUTDOWN-PENDING, SSHUTDOWN-SENT state. If an agent is in the SSHUTDOWN-ACK-SENT state and receives an SINIT chunk (e.g., if the SHUTDOWN COMPLETE was lost) with Validation Tag that belong to this session, it should discard the SINIT chunk and retransmit the SSHUTDOWN ACK chunk. 15. Security Consideration All drafts are required to have a security considerations section. See RFC 3552 [8] for a guide. 16. Reference 16.1 Normal Reference [1] W. Lei, W. Zhang, S. Liu, "A Framework of Multipath Transport System Based on Application-Level Relay ", Internet draft, IETF, July 2013. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 16.2 Information Reference Leiwm, et al. Expires January 28, 2014 [Page 75] Internet-Draft MPMTP-AR July 2013 [3] Randall R. Stewart, "Stream Control Transmission Protocol", RFC4960, September 2007. [4] A. Ford, C. Raiciu, M. Handley, S. Barre, J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC6182, March 2011. [5] J. Postel, "User Datagram Protocol", Augest 1980. [6] M. Allman, V. Paxson, W. Stevens,"TCP Congestion Control", April 1999. [7] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [8] E. Rescorla, B. Korver, "Guidelines for Writing RFC Text on Security Considerations", RFC3552, July 2003. Authors' Addresses Weimin Lei Northeastern University Institute of Communication and Information System College of Information Science and Engineering Shenyang, China, 110819 P. R. China Phone: +86-24-8368-3048 Email: leiweimin@ise.neu.edu.cn Shaowei Liu Northeastern University Institute of Communication and Information System College of Information Science and Engineering Shenyang, China, 110819 P. R. China Email: liushaowei.ise.neu@gmail.com liu_nongfu@163.com Wei Zhang Northeastern University Institute of Communication and Information System College of Information Science and Engineering Shenyang, China, 110819 P. R. China Email: zhangwei1@ise.neu.edu.cn Leiwm, et al. Expires January 28, 2014 [Page 76]