idnits 2.17.1 draft-ietf-tsvwg-sctp-ndata-00.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 (February 6, 2014) is 3731 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 371, 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: August 10, 2014 Muenster Univ. of Appl. Sciences 6 S. Loreto 7 Ericsson 8 R. Seggelmann 9 T-Systems International GmbH 10 February 6, 2014 12 A New Data Chunk for Stream Control Transmission Protocol 13 draft-ietf-tsvwg-sctp-ndata-00.txt 15 Abstract 17 The Stream Control Transmission Protocol (SCTP) is a message oriented 18 transport protocol supporting arbitrary large user messages. 19 However, the sender can not interleave different user messages which 20 which causes head of line blocking at the sender side. To overcome 21 this limitation, this document adds a new data chunk to SCTP. 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 August 10, 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 2. N-DATA Chunk . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Socket API Considerations . . . . . . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 1.1. Overview 71 When SCTP [RFC4960] was initially designed it was mainly envisioned 72 for transport of small signaling messages. Late in the design stage 73 it was decided to add support for fragmentation and reassembly of 74 larger messages with the thought that someday Session Initiation 75 Protocol (SIP) [RFC3261] style signaling messages may also need to 76 use SCTP and a single MTU sized message would be too small. 77 Unfortunately this design decision, though valid at the time, did not 78 account for other applications which might send very large messages 79 over SCTP. When such large messages are now sent over SCTP a form of 80 sender side head of line blocking becomes created within the 81 protocol. This head of line blocking is caused by the use of the 82 Transmission Sequence Number (TSN) for two different purposes: 84 1. As an identifier for DATA chunks to provide a reliable transfer. 86 2. As an identifier for the sequence of fragments to allow 87 reassembly. 89 The protocol requires all fragments of a user message to have 90 consecutive TSNs. Therefore the sender can not interleave different 91 messages. 93 This document describes a new Data chunk called N-DATA. This chunk 94 incorporates all the flags and properties of the current SCTP Data 95 chunk but also adds a new field in its chunk header, the Fragment 96 Sequence Number (FSN). Then the FSN is only used for reassembly and 97 the TSN only for the reliability. Therefore, the head of line 98 blocking caused by the original design is avoided. 100 1.2. Conventions 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 2. N-DATA Chunk 108 The following Figure 1 shows the new data chunk N-DATA. 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Type = 17 | Res |I|U|B|E| Length | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | TSN | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | Stream Identifier | Stream Sequence Number | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Payload Protocol Identifier | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Message Identifier | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Fragment Sequence Number | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 \ \ 126 / User Data / 127 \ \ 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 Figure 1: N-DATA chunk format 132 The only differences between the N-DATA chunk in Figure 1 and the 133 DATA chunk defined in [RFC4960] and [RFC7053] is the addition of the 134 new Message Identifier (MID) and Fragment Sequence Number (FSN). 136 Message Identifier (MID): 32 bits (unsigned integer) 137 The Message Identifier. Please note that the MID is in "network 138 byte order", a.k.a. Big Endian. 140 Fragment Sequence Number (FSN): 32 bits (unsigned integer) 141 Identifies the fragment number of this piece of a message. FSN's 142 are unsigned number, the first fragment MUST start at 0 and MUST 143 have the 'B' bit set. The last fragment of a message MUST have 144 the 'E' bit set. Note that the FSN may wrap completely multiple 145 times allowing arbitrary large messages. Please note that the FSN 146 is in "network byte order", a.k.a. Big Endian. 148 3. Procedures 150 3.1. Sender Side Considerations 152 A sender MUST NOT send a N-DATA chunk unless the peer has indicated 153 its support of the N-DATA chunk type within the Supported Extensions 154 Parameter as defined in [RFC5061]. 156 A sender MUST NOT use the N-DATA chunk unless the user has requested 157 that use via the socket API (see Section 4). This constraint is made 158 since usage of this chunk requires that the application be willing to 159 interleave messages upon reception within an association. This is 160 not the default choice within the socket API (see [RFC6458]) thus the 161 user MUST indicate support to the protocol of the reception of 162 completely interleaved messages. Note that for stacks that do not 163 implement [RFC6458] they may use other methods to indicate 164 interleaved message support and thus enable the usage of the N-DATA 165 chunk, the key is that the the stack MUST know the application has 166 indicated its choice in wanting to use the extension. 168 Sender side usage of the N-Data chunk is quite simple. Instead of 169 using the TSN for fragmentation purposes, the sender uses the new FSN 170 field to indicate which fragment number is being sent. The first 171 fragment MUST have the 'B' bit set. The last fragment MUST have the 172 'E' bit set. All other fragments MUST NOT have the 'B' or 'E' bit 173 set. If the 'I' bit is set the 'E' bit MUST also be set, i.e. the 174 'I' bit may only be set on the last fragment of a message. All other 175 properties of the existing SCTP DATA chunk also apply to the N-DATA 176 chunk, i.e. congestion control as well as receiver window conditions 177 MUST be observed as defined in [RFC4960]. 179 Note that the usage of this chunk should also imply late binding of 180 the actual TSN to any chunk being sent. This way other messages from 181 other streams may be interleaved with the fragmented message. 183 The sender MUST NOT have more than one ordered fragmented message 184 being produced in any one stream. The sender MUST NOT have more than 185 one un-ordered fragmented message being produced in any one stream. 186 The sender MAY have one ordered and one unordered fragmented message 187 being produced within a single stream. At any time multiple streams 188 MAY be producing an ordered or unordered fragmented message. 190 3.2. Receiver Side Considerations 192 Upon reception of an SCTP packet containing a N-DATA chunk if the 193 message needs to be reassembled, then the receiver MUST use the FSN 194 for reassembly of the message and not the TSN. Note that a non- 195 fragmented messages is indicated by the fact that both the 'E' and 196 'B' bits are set. An ordered or unordered fragmented message is thus 197 identified with any message not having both bits set. 199 4. Socket API Considerations 201 This section describes how the socket API defined in [RFC6458] is 202 extended to allow applications to use the extension described in this 203 document. 205 Please note that this section is informational only. 207 4.1. Socket Options 209 +-------------------+--------------------------+-----+-----+ 210 | option name | data type | get | set | 211 +-------------------+--------------------------+-----+-----+ 212 | SCTP_NDATA_ENABLE | int | X | X | 213 | SCTP_PLUGGABLE_SS | struct sctp_assoc_value | X | X | 214 | SCTP_SS_VALUE | struct sctp_stream_value | X | X | 215 +-------------------+--------------------------+-----+-----+ 217 4.1.1. Enable or Disable the Interleaving Capability 218 (SCTP_NDATA_ENABLE) 220 A new socket option to turn on/off the usage of the N-DATA chunk. 221 Turning this option on only effect future associations, and MUST be 222 turned on for the protocol stack to indicate support of the N-DATA 223 chunk to the peer during association setup. Turning this option off, 224 will prevent the N-DATA chunk from being indicated supported in 225 future associations, and will also prevent current associations from 226 producing N-DATA chunks for future large fragmented messages. Note 227 that this does not stop the peer from sending N-DATA chunks. 229 An N-DATA chunk aware application should also set the fragment 230 interleave level to 2. This allows the reception from multiple 231 streams simultaneously. Failure to set this option can possibly lead 232 to application deadlock. 234 4.1.2. Get or Set the Stream Scheduler (SCTP_PLUGGABLE_SS) 236 A stream scheduler can be selected with the SCTP_PLUGGABLE_SS option 237 for setsockopt(). The struct sctp_assoc_value is used to specify the 238 association for which the scheduler should be changed and the value 239 of the desired algorithm. 241 The definition of struct sctp_assoc_value is the same as in 242 [RFC6458]: 244 struct sctp_assoc_value { 245 sctp_assoc_t assoc_id; 246 uint32_t assoc_value; 247 }; 249 assoc_id: Holds the identifier for the association of which the 250 scheduler should be changed. The special 251 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 252 is ignored for one-to-one style sockets. 254 assoc_value: This specifies which scheduler is used. The following 255 constants can be used: 257 SCTP_SS_DEFAULT: The default scheduler used by the SCTP 258 implementation. Typical values are SCTP_SS_ROUND_ROBIN or 259 SCTP_SS_FIRST_COME. 261 SCTP_SS_ROUND_ROBIN: This scheduler provides a fair scheduling 262 based on the number of user messages by cycling around non- 263 empty stream queues. 265 SCTP_SS_ROUND_ROBIN_PACKET: This is a round-robin scheduler but 266 only bundles user messages of the same stream in one packet. 267 This minimizes head-of-line blocking when a packet is lost 268 because only a single stream is affected. 270 SCTP_SS_PRIORITY: Scheduling with different priorities is used. 271 Streams having a higher priority will be scheduled first and 272 when multiple streams have the same priority, the default 273 scheduling should be used for them. The priority can be 274 assigned with the sctp_stream_value struct. The higher the 275 assigned value, the lower the priority, that is the default 276 value 0 is the highest priority and therefore the default 277 scheduling will be used if no priorities have been assigned. 279 SCTP_SS_FAIR_BANDWITH: A fair bandwidth distribution between the 280 streams can be activated using this value. This scheduler 281 considers the lengths of the messages of each stream and 282 schedules them in a certain way to maintain an equal bandwidth 283 for all streams. 285 SCTP_SS_FIRST_COME: The simple first-come, first-serve algorithm 286 is selected by using this value. It just passes through the 287 messages in the order in which they have been delivered by the 288 application. No modification of the order is done at all. 290 4.1.3. Get or Set the Stream Scheduler Parameter (SCTP_SS_VALUE) 292 Some schedulers require additional information to be set for single 293 streams as shown in the following table: 295 +----------------------+-----------------+ 296 | name | per stream info | 297 +----------------------+-----------------+ 298 | SCTP_SS_DEFAULT | no | 299 | SCTP_SS_RR | no | 300 | SCTP_SS_RR_INTER | no | 301 | SCTP_SS_RR_PKT | no | 302 | SCTP_SS_RR_PKT_INTER | no | 303 | SCTP_SS_PRIO | yes | 304 | SCTP_SS_PRIO_INTER | yes | 305 | SCTP_SS_FB | no | 306 | SCTP_SS_FB_INTER | no | 307 | SCTP_SS_FCFS | no | 308 +----------------------+-----------------+ 310 This is achieved with the SCTP_SS_VALUE option and the corresponding 311 struct sctp_stream_value. The definition of struct sctp_stream_value 312 is as follows: 314 struct sctp_stream_value { 315 sctp_assoc_t assoc_id; 316 uint16_t stream_id; 317 uint16_t stream_value; 318 }; 320 assoc_id: Holds the identifier for the association of which the 321 scheduler should be changed. The special 322 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 323 is ignored for one-to-one style sockets. 325 stream_id: Holds the stream id for the stream for which additional 326 information has to be provided. 328 stream_value: The meaning of this field depends on the scheduler 329 specified. It is ignored when the scheduler does not need 330 additional information. 332 5. IANA Considerations 334 [NOTE to RFC-Editor: 336 "RFCXXXX" is to be replaced by the RFC number you assign this 337 document. 339 ] 341 [NOTE to RFC-Editor: 343 The suggested values for the chunk type and the chunk flags are 344 tentative and to be confirmed by IANA. 346 ] 348 This document (RFCXXXX) is the reference for all registrations 349 described in this section. 351 A new chunk type has to be assigned by IANA. IANA should assign this 352 value from the pool of chunks with the upper two bits set to '00'. 353 This requires an additional line in the "Chunk Types" registry for 354 SCTP: 356 +----------+-------------------------+-----------+ 357 | ID Value | Chunk Type | Reference | 358 +----------+-------------------------+-----------+ 359 | 17 | New DATA chunk (N-DATA) | [RFCXXXX] | 360 +----------+-------------------------+-----------+ 362 The registration table as defined in [RFC6096] for the chunk flags of 363 this chunk type is initially given by the following table: 365 +------------------+-----------------+-----------+ 366 | Chunk Flag Value | Chunk Flag Name | Reference | 367 +------------------+-----------------+-----------+ 368 | 0x01 | E bit | [RFCXXXX] | 369 | 0x02 | B bit | [RFCXXXX] | 370 | 0x04 | U bit | [RFCXXXX] | 371 | 0x08 | I bit | [RFCXXXX] | 372 | 0x10 | Unassigned | | 373 | 0x20 | Unassigned | | 374 | 0x40 | Unassigned | | 375 | 0x80 | Unassigned | | 376 +------------------+-----------------+-----------+ 378 6. Security Considerations 380 This document does not add any additional security considerations in 381 addition to the ones given in [RFC4960] and [RFC6458]. 383 7. Acknowledgments 385 The authors wish to thank Lixia Zhang for her invaluable comments. 387 8. References 389 8.1. Normative References 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", BCP 14, RFC 2119, March 1997. 394 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 395 4960, September 2007. 397 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 398 Kozuka, "Stream Control Transmission Protocol (SCTP) 399 Dynamic Address Reconfiguration", RFC 5061, September 400 2007. 402 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 403 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 404 January 2011. 406 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 407 IMMEDIATELY Extension for the Stream Control Transmission 408 Protocol", RFC 7053, November 2013. 410 8.2. Informative References 412 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 413 A., Peterson, J., Sparks, R., Handley, M., and E. 414 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 415 June 2002. 417 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 418 Yasevich, "Sockets API Extensions for the Stream Control 419 Transmission Protocol (SCTP)", RFC 6458, December 2011. 421 Authors' Addresses 423 Randall R. Stewart 424 Adara Networks 425 Chapin, SC 29036 426 US 428 Email: randall@lakerest.net 430 Michael Tuexen 431 Muenster University of Applied Sciences 432 Stegerwaldstrasse 39 433 48565 Steinfurt 434 DE 436 Email: tuexen@fh-muenster.de 438 Salvatore Loreto 439 Ericsson 440 Hirsalantie 11 441 Jorvas 02420 442 FI 444 Email: Salvatore.Loreto@ericsson.com 446 Robin Seggelmann 447 T-Systems International GmbH 448 Fasanenweg 5 449 70771 Leinfelden-Echterdingen 450 DE 452 Email: robin.seggelmann@t-systems.com