idnits 2.17.00 (12 Aug 2021) /tmp/idnits58210/draft-ietf-tsvwg-sctp-sack-immediately-04.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 (Using the creation date from RFC4960, updated by this document, for RFC5378 checks: 2006-02-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 28, 2013) is 3181 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 260, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tuexen 3 Internet-Draft I. Ruengeler 4 Updates: 4960 (if approved) Muenster Univ. of Appl. Sciences 5 Intended status: Standards Track R. Stewart 6 Expires: March 01, 2014 Adara Networks 7 August 28, 2013 9 SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol 10 draft-ietf-tsvwg-sctp-sack-immediately-04.txt 12 Abstract 14 This document updates RFC 4960 by defining a method for the sender of 15 a DATA chunk to indicate that the corresponding SACK chunk should be 16 sent back immediately and not be delayed. It is done by specifying a 17 bit in the DATA chunk header, called the I-bit, which can get set 18 either by the SCTP implementation or by the application using an SCTP 19 stack. Since unknown flags in chunk headers are ignored by SCTP 20 implementations, this extension does not introduce any 21 interoperability problems. 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 March 01, 2014. 40 Copyright Notice 42 Copyright (c) 2013 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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. The I-bit in the DATA Chunk Header . . . . . . . . . . . . . 3 60 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Triggering at the Application Level . . . . . . . . . . . 4 62 4.2. Triggering at the SCTP Level . . . . . . . . . . . . . . 4 63 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5.1. Sender Side Considerations . . . . . . . . . . . . . . . 5 65 5.2. Receiver Side Considerations . . . . . . . . . . . . . . 5 66 6. Interoperability Considerations . . . . . . . . . . . . . . . 5 67 7. Socket API Considerations . . . . . . . . . . . . . . . . . . 5 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 11.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 According to [RFC4960] the receiver of a DATA chunk should use 79 delayed SACKs. This delaying is completely controlled by the 80 receiver of the DATA chunk and remains the default behavior. 82 In specific situations the delaying of SACKs results in reduced 83 performance of the protocol: 85 1. If such a situation can be detected by the receiver, the 86 corresponding SACK can be sent immediately. For example, 87 [RFC4960] recommends the immediate sending if the receiver has 88 detected message loss or message duplication. 90 2. However, if the situation can only be detected by the sender of 91 the DATA chunk, [RFC4960] provides no method of avoiding a delay 92 in sending the SACK. Examples of these situations include ones 93 which require interaction with the application (e.g. applications 94 using the SCTP_SENDER_DRY_EVENT, see Section 4.1) and ones which 95 can be detected by the SCTP stack itself (e.g. closing the 96 association, hitting window limits or resetting streams, see 97 Section 4.2). 99 To overcome the limitation described in the second case, this 100 document describes a simple extension of the SCTP DATA chunk by 101 defining a new flag, the I-bit. The sender of a DATA chunk indicates 102 by setting this bit that the corresponding SACK chunk should not be 103 delayed. 105 2. Conventions 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 3. The I-bit in the DATA Chunk Header 113 The following Figure 1 shows the extended DATA chunk. 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Type = 0 | Res |I|U|B|E| Length | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | TSN | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Stream Identifier | Stream Sequence Number | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Payload Protocol Identifier | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 \ \ 127 / User Data / 128 \ \ 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Figure 1: Extended DATA chunk format 133 The only difference between the DATA chunk in Figure 1 and the DATA 134 chunk defined in [RFC4960] is the addition of the I-bit in the flags 135 field of the DATA chunk header. 137 This bit was Reserved in [RFC4960]. [RFC4960] specified that this 138 bit should be set to 0 by the sender and ignored by the receiver. 140 4. Use Cases 142 The setting of the I-bit can either be triggered by the application 143 using SCTP or by the SCTP stack itself. The following two 144 subsections provide a non-exhaustive list of examples. 146 4.1. Triggering at the Application Level 148 One example of a situation in which it may be desirable for an 149 application to trigger setting of the I-bit involves the 150 SCTP_SENDER_DRY_EVENT in the SCTP socket API [RFC6458]. Upper layers 151 of SCTP using the socket API as defined in [RFC6458] may subscribe to 152 the SCTP_SENDER_DRY_EVENT for getting a notification as soon as no 153 user data is outstanding anymore. To avoid an unnecessary delay 154 while waiting for such an event, the application can request the 155 setting of the I-Bit when sending the last user message before 156 waiting for the event. This results in setting the I-bit of the last 157 DATA chunk corresponding to the user message and is possible using 158 the extension of the socket API described in Section 7. 160 4.2. Triggering at the SCTP Level 162 There are also situations in which the SCTP implementation can set 163 the I-bit without interacting with the upper layer. 165 If the association is in the SHUTDOWN-PENDING state, setting the 166 I-bit reduces the number of simultaneous associations for a busy 167 server handling short living associations. 169 Another case is where the sending of a DATA chunk fills the 170 congestion or receiver window. Setting the I-bit in these cases 171 improves the throughput of the transfer. 173 If an SCTP association supports the SCTP Stream Reconfiguration 174 extension defined in [RFC6525], the performance can be improved by 175 setting the I-bit when there are pending reconfiguration requests 176 that require that there be no outstanding DATA chunks. 178 5. Procedures 179 5.1. Sender Side Considerations 181 Whenever the sender of a DATA chunk can benefit from the 182 corresponding SACK chunk being sent back without delay, the sender 183 MAY set the I-bit in the DATA chunk header. Please note that it is 184 irrelevant to the receiver why the sender has set the I-bit. 186 Reasons for setting the I-bit include, but are not limited to, the 187 following (see Section 4 for the benefits): 189 o The application requests to set the I-bit of the last DATA chunk 190 of a user message when providing the user message to the SCTP 191 implementation (see Section 7). 193 o The sender is in the SHUTDOWN-PENDING state. 195 o The sending of a DATA chunk fills the congestion or receiver 196 window. 198 o The sending of an Outgoing SSN Reset Request Parameter or an SSN/ 199 TSN Reset Request Parameter is pending, if the association 200 supports the Stream Reconfiguration extension defined in 201 [RFC6525]. 203 5.2. Receiver Side Considerations 205 On reception of an SCTP packet containing a DATA chunk with the I-bit 206 set, the receiver SHOULD NOT delay the sending of the corresponding 207 SACK chunk, i.e., the receiver SHOULD immediately respond with the 208 corresponding SACK chunk. 210 6. Interoperability Considerations 212 According to [RFC4960] the receiver of a DATA chunk with the I-bit 213 set should ignore this bit when it does not support the extension 214 described in this document. Since the sender of the DATA chunk is 215 able to handle this case, there is no requirement for negotiating the 216 support of the feature described in this document. 218 7. Socket API Considerations 220 This section describes how the socket API defined in [RFC6458] is 221 extended to provide a way for the application to set the I-bit. 223 Please note that this section is informational only. 225 A socket API implementation based on [RFC6458] needs to be extended 226 to allow the application to set the I-bit of the last DATA chunk when 227 sending each user message. 229 This can be done by setting a flag called SCTP_SACK_IMMEDIATELY in 230 the snd_flags field of the struct sctp_sndinfo structure when using 231 sctp_sendv() or sendmsg(). If the deprecated struct sctp_sndrcvinfo 232 structure is used instead when calling sctp_send(), sctp_sendx(), or 233 sendmsg(), the SCTP_SACK_IMMEDIATELY flag can be set in the 234 sinfo_flags field. When using the deprecated function sctp_sendmsg() 235 the SCTP_SACK_IMMEDIATELY flag can be in the flags parameter. 237 8. IANA Considerations 239 [NOTE to RFC-Editor: 241 "RFCXXXX" is to be replaced by the RFC number you assign this 242 document. 244 ] 246 Following the chunk flag registration procedure defined in [RFC6096], 247 IANA should register a new bit, the I-bit, for the DATA chunk. The 248 suggested value is 0x08 and the reference should be RFCXXXX. 250 This requires an update of the "DATA Chunk Flags" registry for SCTP: 252 DATA Chunk Flags 254 +------------------+-----------------+-----------+ 255 | Chunk Flag Value | Chunk Flag Name | Reference | 256 +------------------+-----------------+-----------+ 257 | 0x01 | E bit | [RFC4960] | 258 | 0x02 | B bit | [RFC4960] | 259 | 0x04 | U bit | [RFC4960] | 260 | 0x08 | I Bit | [RFCXXXX] | 261 | 0x10 | Unassigned | | 262 | 0x20 | Unassigned | | 263 | 0x40 | Unassigned | | 264 | 0x80 | Unassigned | | 265 +------------------+-----------------+-----------+ 267 9. Security Considerations 269 See [RFC4960] for general security considerations for SCTP. In 270 addition, a malicious sender can force its peer to send packets 271 containing a SACK chunk for each received packet containing DATA 272 chunks instead of every other. This could impact the network, 273 resulting in more packets sent on the network, or the peer because 274 the generating and sending of the packets has some processing cost. 275 However, the additional packets can only contain the most simplest 276 SACK chunk (no gap reports, no duplicate TSNs), since in case of 277 packet drop or reordering in the network a SACK chunk would be sent 278 immediately anyway. Therefore this does neither introduce a 279 significant additional processing cost on the receiver side. This 280 does not result in more traffic in the network than a receiver that 281 sends a SACK for every packet, which is already permitted. 283 10. Acknowledgments 285 The authors wish to thank Mark Allmann, Brian Bidulock, David Black, 286 Anna Brunstrom, Gorry Fairhurst, Janardhan Iyengar, Kacheong Poon, 287 and Michael Welzl for their invaluable comments. 289 11. References 291 11.1. Normative References 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, March 1997. 296 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 297 4960, September 2007. 299 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 300 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 301 January 2011. 303 11.2. Informative References 305 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 306 Yasevich, "Sockets API Extensions for the Stream Control 307 Transmission Protocol (SCTP)", RFC 6458, December 2011. 309 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 310 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 311 6525, February 2012. 313 Authors' Addresses 314 Michael Tuexen 315 Muenster University of Applied Sciences 316 Stegerwaldstr. 39 317 48565 Steinfurt 318 DE 320 Email: tuexen@fh-muenster.de 322 Irene Ruengeler 323 Muenster University of Applied Sciences 324 Stegerwaldstr. 39 325 48565 Steinfurt 326 DE 328 Email: i.ruengeler@fh-muenster.de 330 Randall R. Stewart 331 Adara Networks 332 Chapin, SC 29036 333 US 335 Email: randall@lakerest.net