idnits 2.17.1 draft-ietf-tsvwg-sctp-sack-immediately-03.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 (April 08, 2013) is 4029 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 250, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6096 (Obsoleted by RFC 9260) Summary: 2 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. R. Stewart 6 Expires: October 10, 2013 Adara Networks 7 April 08, 2013 9 SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol 10 draft-ietf-tsvwg-sctp-sack-immediately-03.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 October 10, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. The I-bit in the DATA Chunk Header . . . . . . . . . . . . . 3 60 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4.1. Triggering at the Application Level . . . . . . . . . . . 3 62 4.2. Triggering at the SCTP Level . . . . . . . . . . . . . . 4 63 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5.1. Sender Side Considerations . . . . . . . . . . . . . . . 4 65 5.2. Receiver Side Considerations . . . . . . . . . . . . . . 5 66 6. Interoperability Considerations . . . . . . . . . . . . . . . 5 67 7. Socket API Considerations . . . . . . . . . . . . . . . . . . 5 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 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. If such a situation can be detected by 84 the receiver, the corresponding SACK can be sent immediately. For 85 example, [RFC4960] recommends the immediate sending if the receiver 86 has detected message loss or message duplication. However, if the 87 situation can only be detected by the sender of the DATA chunk, 88 [RFC4960] provides no method of avoiding a delay in sending the SACK. 90 This document describes a simple extension of the SCTP DATA chunk by 91 defining a new flag, the I-bit. The sender of a DATA chunk indicates 92 by setting this bit that the corresponding SACK chunk should not be 93 delayed. Use-cases are described in Section 4. 95 2. Conventions 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 3. The I-bit in the DATA Chunk Header 102 The following Figure 1 shows the extended DATA chunk. 104 0 1 2 3 105 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 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Type = 0 | Res |I|U|B|E| Length | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | TSN | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Stream Identifier | Stream Sequence Number | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Payload Protocol Identifier | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 \ \ 116 / User Data / 117 \ \ 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 Figure 1: Extended DATA chunk format 122 The only difference between the DATA chunk in Figure 1 and the DATA 123 chunk defined in [RFC4960] is the addition of the I-bit in the flags 124 field of the DATA chunk header. 126 This bit was Reserved in [RFC4960]. [RFC4960] specified that this 127 bit should be set to 0 by the sender and ignored by the receiver. 129 4. Use Cases 131 The setting of the I-bit can either be triggered by the application 132 using SCTP or by the SCTP stack itself. The following two 133 subsections provide a non-exhaustive list of examples. 135 4.1. Triggering at the Application Level 137 One example of a situation in which it may be desirable for an 138 application to trigger setting of the I-bit involves the 139 SCTP_SENDER_DRY_EVENT in the SCTP socket API [RFC6458]. Upper layers 140 of SCTP using the socket API as defined in [RFC6458] may subscribe to 141 the SCTP_SENDER_DRY_EVENT for getting a notification as soon as no 142 user data is outstanding anymore. To avoid an unnecessary delay 143 while waiting for such an event, the application can request the 144 setting of the I-Bit when sending the last user message before 145 waiting for the event. This results in setting the I-bit of the last 146 DATA chunk corresponding to the user message and is possible using 147 the extension of the socket API described in Section 7. 149 4.2. Triggering at the SCTP Level 151 There are also situations in which the SCTP implementation can set 152 the I-bit without interacting with the upper layer. 154 If the association is in the SHUTDOWN-PENDING state, setting the 155 I-bit reduces the number of simultaneous associations for a busy 156 server handling short living associations. 158 Another case is where the sending of a DATA chunk fills the 159 congestion or receiver window. Setting the I-bit in these cases 160 improves the throughput of the transfer. 162 If an SCTP association supports the SCTP Stream Reconfiguration 163 extension defined in [RFC6525], the performance can be improved by 164 setting the I-bit when there are pending reconfiguration requests 165 that require that there be no outstanding DATA chunks. 167 5. Procedures 169 5.1. Sender Side Considerations 171 Whenever the sender of a DATA chunk can benefit from the 172 corresponding SACK chunk being sent back without delay, the sender 173 MAY set the I-bit in the DATA chunk header. Please note that it is 174 irrelevant to the receiver why the sender has set the I-bit. 176 Reasons for setting the I-bit include, but are not limited to, the 177 following (see Section 4 for the benefits): 179 o The application requests to set the I-bit of the last DATA chunk 180 of a user message when providing the user message to the SCTP 181 implementation (see Section 7). 183 o The sender is in the SHUTDOWN-PENDING state. 185 o The sending of a DATA chunk fills the congestion or receiver 186 window. 188 o The sending of an Outgoing SSN Reset Request Parameter or an SSN/ 189 TSN Reset Request Parameter is pending, if the association 190 supports the Stream Reconfiguration extension defined in 191 [RFC6525]. 193 5.2. Receiver Side Considerations 195 On reception of an SCTP packet containing a DATA chunk with the I-bit 196 set, the receiver SHOULD NOT delay the sending of the corresponding 197 SACK chunk, i.e., the receiver SHOULD immediately respond with the 198 corresponding SACK chunk. 200 6. Interoperability Considerations 202 According to [RFC4960] the receiver of a DATA chunk with the I-bit 203 set should ignore this bit when it does not support the extension 204 described in this document. Since the sender of the DATA chunk is 205 able to handle this case, there is no requirement for negotiating the 206 support of the feature described in this document. 208 7. Socket API Considerations 210 This section describes how the socket API defined in [RFC6458] is 211 extended to provide a way for the application to set the I-bit. 213 Please note that this section is informational only. 215 A socket API implementation based on [RFC6458] needs to be extended 216 to allow the application to set the I-bit of the last DATA chunk when 217 sending each user message. 219 This can be done by setting a flag called SCTP_SACK_IMMEDIATELY in 220 the snd_flags field of the struct sctp_sndinfo structure when using 221 sctp_sendv() or sendmsg(). If the deprecated struct sctp_sndrcvinfo 222 structure is used instead when calling sctp_send(), sctp_sendx(), or 223 sendmsg(), the SCTP_SACK_IMMEDIATELY flag can be set in the 224 sinfo_flags field. When using the deprecated function sctp_sendmsg() 225 the SCTP_SACK_IMMEDIATELY flag can be in the flags parameter. 227 8. IANA Considerations 229 [NOTE to RFC-Editor: 231 "RFCXXXX" is to be replaced by the RFC number you assign this 232 document. 234 ] 236 Following the chunk flag registration procedure defined in [RFC6096], 237 IANA should register a new bit, the I-bit, for the DATA chunk. The 238 suggested value is 0x08 and the reference should be RFCXXXX. 240 This requires an update of the "DATA Chunk Flags" registry for SCTP: 242 DATA Chunk Flags 244 +------------------+-----------------+-----------+ 245 | Chunk Flag Value | Chunk Flag Name | Reference | 246 +------------------+-----------------+-----------+ 247 | 0x01 | E bit | [RFC4960] | 248 | 0x02 | B bit | [RFC4960] | 249 | 0x04 | U bit | [RFC4960] | 250 | 0x08 | I Bit | [RFCXXXX] | 251 | 0x10 | Unassigned | | 252 | 0x20 | Unassigned | | 253 | 0x40 | Unassigned | | 254 | 0x80 | Unassigned | | 255 +------------------+-----------------+-----------+ 257 9. Security Considerations 259 See [RFC4960] for general security considerations for SCTP. In 260 addition, a malicious sender can force its peer to send packets 261 containing a SACK chunk for each received packet containing DATA 262 chunks instead of every other. This could impact the network, 263 resulting in more packets sent on the network, or the peer because 264 the generating and sending of the packets has some processing cost. 265 However, the additional packets can only contain the most simplest 266 SACK chunk (no gap reports, no duplicate TSNs), since in case of 267 packet drop or reordering in the network a SACK chunk would be sent 268 immediately anyway. Therefore this does neither introduce a 269 significant additional processing cost on the receiver side nor does 270 it cause congestion on the network. 272 10. Acknowledgments 274 The authors wish to thank Mark Allmann, Brian Bidulock, David Black, 275 Anna Brunstrom, Gorry Fairhurst, Janardhan Iyengar, Kacheong Poon, 276 and Michael Welzl for their invaluable comments. 278 11. References 280 11.1. Normative References 282 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 283 Requirement Levels", BCP 14, RFC 2119, March 1997. 285 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 286 4960, September 2007. 288 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 289 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 290 January 2011. 292 11.2. Informative References 294 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 295 Yasevich, "Sockets API Extensions for the Stream Control 296 Transmission Protocol (SCTP)", RFC 6458, December 2011. 298 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 299 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 300 6525, February 2012. 302 Authors' Addresses 304 Michael Tuexen 305 Muenster University of Applied Sciences 306 Stegerwaldstr. 39 307 48565 Steinfurt 308 DE 310 Email: tuexen@fh-muenster.de 312 Irene Ruengeler 313 Muenster University of Applied Sciences 314 Stegerwaldstr. 39 315 48565 Steinfurt 316 DE 318 Email: i.ruengeler@fh-muenster.de 320 Randall R. Stewart 321 Adara Networks 322 Chapin, SC 29036 323 US 325 Email: randall@lakerest.net