idnits 2.17.1 draft-ietf-tsvwg-sctp-prpolicies-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 22, 2014) is 3747 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tuexen 3 Internet-Draft Muenster Univ. of Appl. Sciences 4 Intended status: Informational R. Seggelmann 5 Expires: July 26, 2014 T-Systems International GmbH 6 R. Stewart 7 Adara Networks 8 S. Loreto 9 Ericsson 10 January 22, 2014 12 Additional Policies for the Partial Reliability Extension of the Stream 13 Control Transmission Protocol 14 draft-ietf-tsvwg-sctp-prpolicies-01.txt 16 Abstract 18 This document defines policies for the Partial Reliability Extension 19 of the Stream Control Transmission Protocol (PR-SCTP) allowing to 20 limit the number of retransmissions or to prioritize user messages 21 for more efficient send buffer usage. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 26, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Additional PR-SCTP Policies . . . . . . . . . . . . . . . . . 3 61 2.1. Limited Retransmissions Policy . . . . . . . . . . . . . 3 62 2.2. Priority Policy . . . . . . . . . . . . . . . . . . . . . 3 63 3. Socket API Considerations . . . . . . . . . . . . . . . . . . 3 64 3.1. Support for Added PR-SCTP Policies . . . . . . . . . . . 4 65 3.2. Socket Option for Getting the PR-SCTP Status 66 (SCTP_PR_STATUS) . . . . . . . . . . . . . . . . . . . . 4 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 72 7.2. Informative References . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 1.1. Overview 79 The SCTP Partial Reliability Extension (PR-SCTP) defined in [RFC3758] 80 provides a generic method for senders to abandon user messages. The 81 decision to abandon a user message is sender side only and the exact 82 condition is called a PR-SCTP policy. [RFC3758] also defines one 83 particular PR-SCTP policy, called Timed Reliability. This allows the 84 sender to specify a timeout for a user message after which the SCTP 85 stack abandons the user message. 87 This document specifies two additional PR-SCTP policies: 89 Limited Retransmission Policy: Allows to limit the number of 90 retransmissions. 92 Priority Policy: Allows to discard lower priority messages if space 93 for higher priority messages is needed in the send buffer. 95 1.2. Data Types 97 This documents uses data types from Draft 6.6 (March 1997) of POSIX 98 1003.1g: uintN_t means an unsigned integer of exactly N bits (e.g. 99 uint16_t). This is the same as in [RFC6458] 101 2. Additional PR-SCTP Policies 103 2.1. Limited Retransmissions Policy 105 Using the Limited Retransmission Policy allows the sender of a user 106 message to specify an upper limit for the number of retransmissions 107 for each DATA chunk of the given user messages. The sender must 108 abandon a user message if the number of retransmissions of any of the 109 DATA chunks of the user message would exceed the provided limit. 110 Please note that the number of retransmissions includes the fast and 111 the timer based retransmissions. 113 Limiting the number of retransmissions to 0 is allowed. This will 114 result in abandoning the message when it would get retransmitted for 115 the first time. The use of this setting provides a service similar 116 to UDP, which also does not send any retransmissions either. 118 The Limited Retransmissions Policy is used for data channels in the 119 RTCWeb protocol stack. 121 2.2. Priority Policy 123 Using the Priority Policy allows the sender of a user message to 124 specify a priority. When storing a user message in the send buffer 125 while there is not enough available space, the SCTP stack may abandon 126 other user messages with a priority lower than the provided one. The 127 algorithm for selecting the message being abandoned is implementation 128 specific. 130 After lower priority messages have been abandoned high priority 131 messages can be transferred without blocking the send call. 133 The Priority Policy can be used in the IPFIX protocol stack. See 134 [RFC7011] for more information. 136 3. Socket API Considerations 138 This section describes how the socket API defined in [RFC6458] is 139 extended to support the newly defined PR-SCTP policies and to provide 140 some statistical information. 142 Please note that this section is informational only. 144 3.1. Support for Added PR-SCTP Policies 146 As defined in [RFC6458], the PR-SCTP policy is specified and 147 configured by using the following sctp_prinfo structure: 149 struct sctp_prinfo { 150 uint16_t pr_policy; 151 uint32_t pr_value; 152 }; 154 When the Limited Retransmission Policy described in Section 2.1 is 155 used, pr_policy has the value SCTP_PR_SCTP_RTX and the number of 156 retransmissions is given in pr_value. 158 For using the Priority Policy described in Section 2.2, pr_policy has 159 the value SCTP_PR_SCTP_PRIO. The priority is given in pr_value. The 160 value of zero is the highest priority and larger numbers in pr_value 161 denote lower priorities. 163 The following table summarizes the possible parameter settings 164 defined in [RFC6458] and this document: 166 +-------------------+---------------------------+---------------+ 167 | pr_policy | pr_value | Specification | 168 +-------------------+---------------------------+---------------+ 169 | SCTP_PR_SCTP_NONE | Ignored | [RFC6458] | 170 | SCTP_PR_SCTP_TTL | Lifetime in ms | [RFC6458] | 171 | SCTP_PR_SCTP_RTX | Number of retransmissions | Section 2.1 | 172 | SCTP_PR_SCTP_PRIO | Priority | Section 2.2 | 173 +-------------------+---------------------------+---------------+ 175 3.2. Socket Option for Getting the PR-SCTP Status (SCTP_PR_STATUS) 177 This socket option uses IPPROTO_SCTP as its level and SCTP_PR_STATUS 178 as its name. It can only be used with getsockopt(), but not with 179 setsockopt(). The socket option value uses the following structure: 181 struct sctp_prstatus { 182 sctp_assoc_t sprstat_assoc_id; 183 uint64_t sprstat_abandoned_unsent; 184 uint64_t sprstat_abandoned_sent; 185 }; 187 sprstat_assoc_id: This parameter is ignored for one-to-one style 188 sockets. For one-to-many style sockets this parameter indicates 189 for which association the user wants the information. It is an 190 error to use SCTP_{CURRENT|ALL|FUTURE}_ASSOC in sprstat_assoc_id. 192 sprstat_abandoned_unsent: The number of user messages which have 193 been abandoned, before any part of the user message could be sent. 195 sprstat_abandoned_sent: The number of user messages which have been 196 abandoned, after a part of the user message has been sent. 198 There are separate counters for unsent and sent user messages because 199 the SCTP_SEND_FAILED_EVENT supports a similar differentiation. 200 Please note that an abandoned large user messages requiring an SCTP 201 level fragmentation is reported in the sprstat_abandoned_sent counter 202 as soon as at least one fragment of it has been sent. Therefore each 203 abandoned user messages is either counted in sprstat_abandoned_unsent 204 or sprstat_abandoned_sent. 206 If more detailed information about abandoned user messages is 207 required, the subscription to the SCTP_SEND_FAILED_EVENT is 208 recommended. 210 sctp_opt_info() needs to be extended to support SCTP_PR_STATUS. 212 4. IANA Considerations 214 This document requires no actions from IANA. 216 5. Security Considerations 218 This document does not add any additional security considerations in 219 addition to the ones given in [RFC4960], [RFC3758], and [RFC6458]. 221 6. Acknowledgments 223 The authors wish to thank Ka-Cheong Poon, Irene Ruengeler, Jamal Hadi 224 Salim, and Vlad Yasevich for their invaluable comments. 226 7. References 228 7.1. Normative References 230 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 231 Conrad, "Stream Control Transmission Protocol (SCTP) 232 Partial Reliability Extension", RFC 3758, May 2004. 234 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 235 4960, September 2007. 237 7.2. Informative References 239 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 240 Yasevich, "Sockets API Extensions for the Stream Control 241 Transmission Protocol (SCTP)", RFC 6458, December 2011. 243 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 244 the IP Flow Information Export (IPFIX) Protocol for the 245 Exchange of Flow Information", STD 77, RFC 7011, September 246 2013. 248 Authors' Addresses 250 Michael Tuexen 251 Muenster University of Applied Sciences 252 Stegerwaldstrasse 39 253 48565 Steinfurt 254 DE 256 Email: tuexen@fh-muenster.de 258 Robin Seggelmann 259 T-Systems International GmbH 260 Fasanenweg 5 261 70771 Leinfelden-Echterdingen 262 DE 264 Email: robin.seggelmann@t-systems.com 266 Randall R. Stewart 267 Adara Networks 268 Chapin, SC 29036 269 US 271 Email: randall@lakerest.net 273 Salvatore Loreto 274 Ericsson 275 Hirsalantie 11 276 Jorvas 02420 277 FI 279 Email: Salvatore.Loreto@ericsson.com