idnits 2.17.1 draft-ietf-tsvwg-sctp-ndata-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 (July 4, 2014) is 3576 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 402, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6096 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 7053 (Obsoleted by RFC 9260) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Adara Networks 4 Intended status: Standards Track M. Tuexen 5 Expires: January 5, 2015 Muenster Univ. of Appl. Sciences 6 S. Loreto 7 Ericsson 8 R. Seggelmann 9 T-Systems International GmbH 10 July 4, 2014 12 Stream Schedulers and a New Data Chunk for the Stream Control 13 Transmission Protocol 14 draft-ietf-tsvwg-sctp-ndata-01.txt 16 Abstract 18 The Stream Control Transmission Protocol (SCTP) is a message oriented 19 transport protocol supporting arbitrary large user messages. 20 However, the sender can not interleave different user messages which 21 causes head of line blocking at the sender side. To overcome this 22 limitation, this document adds a new data chunk to SCTP. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 5, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. N-DATA Chunk . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Socket API Considerations . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 1.1. Overview 72 When SCTP [RFC4960] was initially designed it was mainly envisioned 73 for transport of small signaling messages. Late in the design stage 74 it was decided to add support for fragmentation and reassembly of 75 larger messages with the thought that someday Session Initiation 76 Protocol (SIP) [RFC3261] style signaling messages may also need to 77 use SCTP and a single MTU sized message would be too small. 78 Unfortunately this design decision, though valid at the time, did not 79 account for other applications which might send very large messages 80 over SCTP. When such large messages are now sent over SCTP a form of 81 sender side head of line blocking becomes created within the 82 protocol. This head of line blocking is caused by the use of the 83 Transmission Sequence Number (TSN) for two different purposes: 85 1. As an identifier for DATA chunks to provide a reliable transfer. 87 2. As an identifier for the sequence of fragments to allow 88 reassembly. 90 The protocol requires all fragments of a user message to have 91 consecutive TSNs. Therefore the sender can not interleave different 92 messages. 94 This document describes a new Data chunk called N-DATA. This chunk 95 incorporates all the flags and properties of the current SCTP Data 96 chunk but also adds a new field in its chunk header, the Fragment 97 Sequence Number (FSN). Then the FSN is only used for reassembly and 98 the TSN only for the reliability. Therefore, the head of line 99 blocking caused by the original design is avoided. 101 The support of the N-DATA chunk is negotiated during the association 102 setup using the Supported Extensions Parameter as defined in 103 [RFC5061]. If N-DATA support has been negotiated for an association 104 N-DATA chunks are used for all user-messages and no DATA chunks. It 105 should be noted, that an SCTP implementation needs to support the 106 coexistence of associations using DATA chunks and associations using 107 N-DATA chunks. 109 This document also defines several stream schedulers for general SCTP 110 associations. If N-DATA support has been negotiated, several more 111 schedulers are available. 113 1.2. Conventions 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 2. N-DATA Chunk 121 The following Figure 1 shows the new data chunk N-DATA. 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Type = 64 | Res |I|U|B|E| Length | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | TSN | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Stream Identifier | Stream Sequence Number | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Payload Protocol Identifier | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Message Identifier | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Fragment Sequence Number | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 \ \ 139 / User Data / 140 \ \ 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Figure 1: N-DATA chunk format 145 The only differences between the N-DATA chunk in Figure 1 and the 146 DATA chunk defined in [RFC4960] and [RFC7053] is the addition of the 147 new Message Identifier (MID) and Fragment Sequence Number (FSN). 149 Message Identifier (MID): 32 bits (unsigned integer) 150 The Message Identifier. Please note that the MID is in "network 151 byte order", a.k.a. Big Endian. 153 Fragment Sequence Number (FSN): 32 bits (unsigned integer) 154 Identifies the fragment number of this piece of a message. FSN's 155 are unsigned numbers, the first fragment MUST start at 0 and MUST 156 have the 'B' bit set. The last fragment of a message MUST have 157 the 'E' bit set. Note that the FSN may wrap completely multiple 158 times allowing arbitrary large messages. Please note that the FSN 159 is in "network byte order", a.k.a. Big Endian. 161 3. Procedures 163 3.1. Sender Side Considerations 165 A sender MUST NOT send a N-DATA chunk unless the peer has indicated 166 its support of the N-DATA chunk type within the Supported Extensions 167 Parameter as defined in [RFC5061]. If N-DATA support has been 168 negotiated on an association, N-DATA chunks MUST be used for all user 169 data and DATA-chunk MUST NOT be used at all. If N-DATA support has 170 not been negotiated on an association, DATA chunks MUST be used for 171 all user data and N-DATA chunks MUST NOT be used at all. 173 A sender MUST NOT use the N-DATA chunk unless the user has requested 174 that use via the socket API (see Section 4). This constraint is made 175 since usage of this chunk requires that the application be willing to 176 interleave messages upon reception within an association. This is 177 not the default choice within the socket API (see [RFC6458]) thus the 178 user MUST indicate support to the protocol of the reception of 179 completely interleaved messages. Note that for stacks that do not 180 implement [RFC6458] they may use other methods to indicate 181 interleaved message support and thus enable the usage of the N-DATA 182 chunk, the key is that the the stack MUST know the application has 183 indicated its choice in wanting to use the extension. 185 Sender side usage of the N-DATA chunk is quite simple. Instead of 186 using the TSN for fragmentation purposes, the sender uses the new FSN 187 field to indicate which fragment number is being sent. The first 188 fragment MUST have the 'B' bit set. The last fragment MUST have the 189 'E' bit set. All other fragments MUST NOT have the 'B' or 'E' bit 190 set. If the 'I' bit is set the 'E' bit MUST also be set, i.e. the 191 'I' bit may only be set on the last fragment of a message. All other 192 properties of the existing SCTP DATA chunk also apply to the N-DATA 193 chunk, i.e. congestion control as well as receiver window conditions 194 MUST be observed as defined in [RFC4960]. 196 Note that the usage of this chunk should also imply late binding of 197 the actual TSN to any chunk being sent. This way other messages from 198 other streams may be interleaved with the fragmented message. 200 The sender MUST NOT have more than one ordered fragmented message 201 being produced in any one stream. The sender MUST NOT have more than 202 one un-ordered fragmented message being produced in any one stream. 203 The sender MAY have one ordered and one unordered fragmented message 204 being produced within a single stream. At any time multiple streams 205 MAY be producing an ordered or unordered fragmented message. 207 3.2. Receiver Side Considerations 209 Upon reception of an SCTP packet containing a N-DATA chunk if the 210 message needs to be reassembled, then the receiver MUST use the FSN 211 for reassembly of the message and not the TSN. Note that a non- 212 fragmented messages is indicated by the fact that both the 'E' and 213 'B' bits are set. An ordered or unordered fragmented message is thus 214 identified with any message not having both bits set. 216 4. Socket API Considerations 218 This section describes how the socket API defined in [RFC6458] is 219 extended to allow applications to use the extension described in this 220 document. 222 Please note that this section is informational only. 224 4.1. SCTP_ASSOC_CHANGE Notification 226 The notification has to be extended to provide 227 SCTP_SUPPORTS_INTERLEAVING in sac_info if the support of N-DATA has 228 been negotiated. 230 4.2. Socket Options 232 +-------------------+--------------------------+-----+-----+ 233 | option name | data type | get | set | 234 +-------------------+--------------------------+-----+-----+ 235 | SCTP_NDATA_ENABLE | int | X | X | 236 | SCTP_PLUGGABLE_SS | struct sctp_assoc_value | X | X | 237 | SCTP_SS_VALUE | struct sctp_stream_value | X | X | 238 +-------------------+--------------------------+-----+-----+ 240 4.2.1. Enable or Disable the Interleaving Capability 241 (SCTP_NDATA_ENABLE) 243 A new socket option to turn on/off the usage of the N-DATA chunk. 244 Turning this option on only effect future associations, and MUST be 245 turned on for the protocol stack to indicate support of the N-DATA 246 chunk to the peer during association setup. Turning this option off, 247 will prevent the N-DATA chunk from being indicated supported in 248 future associations, and will also prevent current associations from 249 producing N-DATA chunks for future large fragmented messages. Note 250 that this does not stop the peer from sending N-DATA chunks. 252 An N-DATA chunk aware application should also set the fragment 253 interleave level to 2. This allows the reception from multiple 254 streams simultaneously. Failure to set this option can possibly lead 255 to application deadlock. 257 4.2.2. Get or Set the Stream Scheduler (SCTP_PLUGGABLE_SS) 259 A stream scheduler can be selected with the SCTP_PLUGGABLE_SS option 260 for setsockopt(). The struct sctp_assoc_value is used to specify the 261 association for which the scheduler should be changed and the value 262 of the desired algorithm. 264 The definition of struct sctp_assoc_value is the same as in 265 [RFC6458]: 267 struct sctp_assoc_value { 268 sctp_assoc_t assoc_id; 269 uint32_t assoc_value; 270 }; 272 assoc_id: Holds the identifier for the association of which the 273 scheduler should be changed. The special 274 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 275 is ignored for one-to-one style sockets. 277 assoc_value: This specifies which scheduler is used. The following 278 constants can be used: 280 SCTP_SS_DEFAULT: The default scheduler used by the SCTP 281 implementation. Typical values are SCTP_SS_ROUND_ROBIN or 282 SCTP_SS_FIRST_COME. 284 SCTP_SS_ROUND_ROBIN: This scheduler provides a fair scheduling 285 based on the number of user messages by cycling around non- 286 empty stream queues. 288 SCTP_SS_ROUND_ROBIN_PACKET: This is a round-robin scheduler but 289 only bundles user messages of the same stream in one packet. 290 This minimizes head-of-line blocking when a packet is lost 291 because only a single stream is affected. 293 SCTP_SS_PRIORITY: Scheduling with different priorities is used. 294 Streams having a higher priority will be scheduled first and 295 when multiple streams have the same priority, the default 296 scheduling should be used for them. The priority can be 297 assigned with the sctp_stream_value struct. The higher the 298 assigned value, the lower the priority, that is the default 299 value 0 is the highest priority and therefore the default 300 scheduling will be used if no priorities have been assigned. 302 SCTP_SS_FAIR_BANDWITH: A fair bandwidth distribution between the 303 streams can be activated using this value. This scheduler 304 considers the lengths of the messages of each stream and 305 schedules them in a certain way to maintain an equal bandwidth 306 for all streams. 308 SCTP_SS_WEIGHTED_ROUND_ROBIN: A weighted round robin distribution 309 between the streams can be activated using this value. This 310 scheduler considers the lengths of the messages of each stream 311 and schedules them in a certain way to use the bandwidth 312 according to the given weights. 314 SCTP_SS_FIRST_COME: The simple first-come, first-serve algorithm 315 is selected by using this value. It just passes through the 316 messages in the order in which they have been delivered by the 317 application. No modification of the order is done at all. 319 4.2.3. Get or Set the Stream Scheduler Parameter (SCTP_SS_VALUE) 321 Some schedulers require additional information to be set for single 322 streams as shown in the following table: 324 +----------------------+-----------------+ 325 | name | per stream info | 326 +----------------------+-----------------+ 327 | SCTP_SS_DEFAULT | no | 328 | SCTP_SS_RR | no | 329 | SCTP_SS_RR_INTER | no | 330 | SCTP_SS_RR_PKT | no | 331 | SCTP_SS_RR_PKT_INTER | no | 332 | SCTP_SS_PRIO | yes | 333 | SCTP_SS_PRIO_INTER | yes | 334 | SCTP_SS_FB | no | 335 | SCTP_SS_FB_INTER | no | 336 | SCTP_SS_WRR | yes | 337 | SCTP_SS_WRR_INTER | yes | 338 | SCTP_SS_FCFS | no | 339 +----------------------+-----------------+ 341 This is achieved with the SCTP_SS_VALUE option and the corresponding 342 struct sctp_stream_value. The definition of struct sctp_stream_value 343 is as follows: 345 struct sctp_stream_value { 346 sctp_assoc_t assoc_id; 347 uint16_t stream_id; 348 uint16_t stream_value; 349 }; 351 assoc_id: Holds the identifier for the association of which the 352 scheduler should be changed. The special 353 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 354 is ignored for one-to-one style sockets. 356 stream_id: Holds the stream id for the stream for which additional 357 information has to be provided. 359 stream_value: The meaning of this field depends on the scheduler 360 specified. It is ignored when the scheduler does not need 361 additional information. 363 5. IANA Considerations 365 [NOTE to RFC-Editor: 367 "RFCXXXX" is to be replaced by the RFC number you assign this 368 document. 370 ] 372 [NOTE to RFC-Editor: 374 The suggested values for the chunk type and the chunk flags are 375 tentative and to be confirmed by IANA. 377 ] 379 This document (RFCXXXX) is the reference for all registrations 380 described in this section. 382 A new chunk type has to be assigned by IANA. IANA should assign this 383 value from the pool of chunks with the upper two bits set to '01'. 384 This requires an additional line in the "Chunk Types" registry for 385 SCTP: 387 +----------+-------------------------+-----------+ 388 | ID Value | Chunk Type | Reference | 389 +----------+-------------------------+-----------+ 390 | 64 | New DATA chunk (N-DATA) | [RFCXXXX] | 391 +----------+-------------------------+-----------+ 393 The registration table as defined in [RFC6096] for the chunk flags of 394 this chunk type is initially given by the following table: 396 +------------------+-----------------+-----------+ 397 | Chunk Flag Value | Chunk Flag Name | Reference | 398 +------------------+-----------------+-----------+ 399 | 0x01 | E bit | [RFCXXXX] | 400 | 0x02 | B bit | [RFCXXXX] | 401 | 0x04 | U bit | [RFCXXXX] | 402 | 0x08 | I bit | [RFCXXXX] | 403 | 0x10 | Unassigned | | 404 | 0x20 | Unassigned | | 405 | 0x40 | Unassigned | | 406 | 0x80 | Unassigned | | 407 +------------------+-----------------+-----------+ 409 6. Security Considerations 411 This document does not add any additional security considerations in 412 addition to the ones given in [RFC4960] and [RFC6458]. 414 7. Acknowledgments 416 The authors wish to thank Karen E. Egede Nielsen, Irene Ruengeler, 417 and Lixia Zhang for her invaluable comments. 419 8. References 421 8.1. Normative References 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, March 1997. 426 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 427 4960, September 2007. 429 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 430 Kozuka, "Stream Control Transmission Protocol (SCTP) 431 Dynamic Address Reconfiguration", RFC 5061, September 432 2007. 434 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 435 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 436 January 2011. 438 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 439 IMMEDIATELY Extension for the Stream Control Transmission 440 Protocol", RFC 7053, November 2013. 442 8.2. Informative References 444 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 445 A., Peterson, J., Sparks, R., Handley, M., and E. 446 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 447 June 2002. 449 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 450 Yasevich, "Sockets API Extensions for the Stream Control 451 Transmission Protocol (SCTP)", RFC 6458, December 2011. 453 Authors' Addresses 455 Randall R. Stewart 456 Adara Networks 457 Chapin, SC 29036 458 US 460 Email: randall@lakerest.net 461 Michael Tuexen 462 Muenster University of Applied Sciences 463 Stegerwaldstrasse 39 464 48565 Steinfurt 465 DE 467 Email: tuexen@fh-muenster.de 469 Salvatore Loreto 470 Ericsson 471 Hirsalantie 11 472 Jorvas 02420 473 FI 475 Email: Salvatore.Loreto@ericsson.com 477 Robin Seggelmann 478 T-Systems International GmbH 479 Fasanenweg 5 480 70771 Leinfelden-Echterdingen 481 DE 483 Email: robin.seggelmann@t-systems.com