idnits 2.17.1 draft-tuexen-tsvwg-sctp-sack-immediately-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 197. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 208. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 215. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 221. 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 Copyright Line does not match the current year -- 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 (July 5, 2008) is 5772 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) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 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 Intended status: Standards Track Muenster Univ. of Applied Sciences 5 Expires: January 6, 2009 R. Stewart 6 The Resource Group 7 July 5, 2008 9 SACK-IMMEDIATELY extension for the Stream Control Transmission Protocol 10 draft-tuexen-tsvwg-sctp-sack-immediately-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 6, 2009. 37 Abstract 39 This document defines a method for a sender of a DATA chunk to 40 indicate that the corresponding SACK chunk should be sent back 41 immediately. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. The I-bit in the DATA Chunk Header . . . . . . . . . . . . . . 3 48 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 4.1. Sender Side Considerations . . . . . . . . . . . . . . . . 4 50 4.2. Receiver Side Considerations . . . . . . . . . . . . . . . 4 51 5. Interoperability Considerations . . . . . . . . . . . . . . . . 4 52 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 53 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 54 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 56 Intellectual Property and Copyright Statements . . . . . . . . . . 6 58 1. Introduction 60 [RFC4960] states that an SCTP implementation should use delayed 61 SACKs. In combination with the Nagle algorithm, reduced congestion 62 windows after timeouts, the handling of the SHUTDOWN-SENDING state, 63 or other situations this might result in reduced performance of the 64 protocol. 66 This document describes a simple extension of the SCTP DATA chunk by 67 defining a new flag, the I-bit. The sender indicates by setting this 68 bit that the corresponding SACK chunk should be sent back without 69 delaying it. 71 2. Conventions 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 3. The I-bit in the DATA Chunk Header 79 The following Figure 1 shows the extended DATA chunk. 81 0 1 2 3 82 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 83 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 | Type = 0 | Res |I|U|B|E| Length | 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 | TSN | 87 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 | Stream Identifier | Stream Sequence Number | 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 | Payload Protocol Identifier | 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 \ \ 93 / User Data / 94 \ \ 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 Figure 1 99 The only difference between the DATA chunk in Figure 1 and the DATA 100 chunk defined in [RFC4960] is the addition of the I-bit in the flags 101 field of the chunk header. 103 4. Procedures 105 4.1. Sender Side Considerations 107 Whenever the sender of a DATA chunk can benefit from the 108 corresponding SACK chunk being sent back without delay, the sender 109 MAY set the I-bit in the DATA chunk header. 111 Reasons for setting the I-bit include 113 o The sender has not enough queued user data to send the remaining 114 DATA chunks due to the Nagle algorithm. 116 o The sending of a DATA chunk fills the congestion or receiver 117 window. 119 o The sender is in the SHUTDOWN-PENDING state. 121 o The sender has reduced its RTO.Min such that a retransmission 122 timeout will occur if the receiver would delay its SACK. 124 4.2. Receiver Side Considerations 126 On reception of an SCTP packet containing a DATA chunk with the I-bit 127 set, the receiver SHOULD NOT delay the sending of the corresponding 128 SACK chunk and SHOULD send it back immediately. 130 5. Interoperability Considerations 132 According to [RFC4960] a receiver of a DATA chunk with the I-bit set 133 should ignore this bit when it does not support the extension 134 described in this document. Since the sender of the DATA chunk is 135 able to handle this case, there is no requirement for negotiating the 136 feature described in this document. 138 6. IANA Considerations 140 There are no actions required from IANA. 142 7. Security Considerations 144 This document does not add any additional security considerations in 145 addition to the ones given in [RFC4960]. 147 8. Normative References 149 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 150 Requirement Levels", BCP 14, RFC 2119, March 1997. 152 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 153 RFC 4960, September 2007. 155 Authors' Addresses 157 Michael Tuexen 158 Muenster Univ. of Applied Sciences 159 Stegerwaldstr. 39 160 48565 Steinfurt 161 Germany 163 Email: tuexen@fh-muenster.de 165 Irene Ruengeler 166 Muenster Univ. of Applied Sciences 167 Stegerwaldstr. 39 168 48565 Steinfurt 169 Germany 171 Email: i.ruengeler@fh-muenster.de 173 Randall R. Stewart 174 The Resource Group 175 1700 Pennsylvania Ave NW 176 Suite 56 177 Washington, DC 20006 178 USA 180 Phone: 181 Email: randall.stewart@trgworld.com 183 Full Copyright Statement 185 Copyright (C) The IETF Trust (2008). 187 This document is subject to the rights, licenses and restrictions 188 contained in BCP 78, and except as set forth therein, the authors 189 retain all their rights. 191 This document and the information contained herein are provided on an 192 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 193 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 194 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 195 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 196 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 197 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 199 Intellectual Property 201 The IETF takes no position regarding the validity or scope of any 202 Intellectual Property Rights or other rights that might be claimed to 203 pertain to the implementation or use of the technology described in 204 this document or the extent to which any license under such rights 205 might or might not be available; nor does it represent that it has 206 made any independent effort to identify any such rights. Information 207 on the procedures with respect to rights in RFC documents can be 208 found in BCP 78 and BCP 79. 210 Copies of IPR disclosures made to the IETF Secretariat and any 211 assurances of licenses to be made available, or the result of an 212 attempt made to obtain a general license or permission for the use of 213 such proprietary rights by implementers or users of this 214 specification can be obtained from the IETF on-line IPR repository at 215 http://www.ietf.org/ipr. 217 The IETF invites any interested party to bring to its attention any 218 copyrights, patents or patent applications, or other proprietary 219 rights that may cover technology that may be required to implement 220 this standard. Please address the information to the IETF at 221 ietf-ipr@ietf.org.