idnits 2.17.1 draft-tuexen-tsvwg-sctp-sack-immediately-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 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 (February 16, 2009) is 5519 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: 1 error (**), 0 flaws (~~), 1 warning (==), 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 Intended status: Standards Track Muenster Univ. of Applied Sciences 5 Expires: August 20, 2009 R. Stewart 6 Researcher 7 February 16, 2009 9 SACK-IMMEDIATELY extension for the Stream Control Transmission Protocol 10 draft-tuexen-tsvwg-sctp-sack-immediately-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 20, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 This document defines a method for a sender of a DATA chunk to 50 indicate that the corresponding SACK chunk should be sent back 51 immediately. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. The I-bit in the DATA Chunk Header . . . . . . . . . . . . . . 3 58 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Sender Side Considerations . . . . . . . . . . . . . . . . 4 60 4.2. Receiver Side Considerations . . . . . . . . . . . . . . . 4 61 5. Interoperability Considerations . . . . . . . . . . . . . . . . 4 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 64 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 [RFC4960] states that an SCTP implementation should use delayed 70 SACKs. In combination with the Nagle algorithm, reduced congestion 71 windows after timeouts, the handling of the SHUTDOWN-SENDING state, 72 or other situations this might result in reduced performance of the 73 protocol. 75 This document describes a simple extension of the SCTP DATA chunk by 76 defining a new flag, the I-bit. The sender indicates by setting this 77 bit that the corresponding SACK chunk should be sent back without 78 delaying it. 80 2. Conventions 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 3. The I-bit in the DATA Chunk Header 88 The following Figure 1 shows the extended DATA chunk. 90 0 1 2 3 91 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 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | Type = 0 | Res |I|U|B|E| Length | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | TSN | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Stream Identifier | Stream Sequence Number | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Payload Protocol Identifier | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 \ \ 102 / User Data / 103 \ \ 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 Figure 1 108 The only difference between the DATA chunk in Figure 1 and the DATA 109 chunk defined in [RFC4960] is the addition of the I-bit in the flags 110 field of the chunk header. 112 4. Procedures 114 4.1. Sender Side Considerations 116 Whenever the sender of a DATA chunk can benefit from the 117 corresponding SACK chunk being sent back without delay, the sender 118 MAY set the I-bit in the DATA chunk header. 120 Reasons for setting the I-bit include 122 o The sender has not enough queued user data to send the remaining 123 DATA chunks due to the Nagle algorithm. 125 o The sending of a DATA chunk fills the congestion or receiver 126 window. 128 o The sender is in the SHUTDOWN-PENDING state. 130 o The sender has reduced its RTO.Min such that a retransmission 131 timeout will occur if the receiver would delay its SACK. 133 4.2. Receiver Side Considerations 135 On reception of an SCTP packet containing a DATA chunk with the I-bit 136 set, the receiver SHOULD NOT delay the sending of the corresponding 137 SACK chunk and SHOULD send it back immediately. 139 5. Interoperability Considerations 141 According to [RFC4960] a receiver of a DATA chunk with the I-bit set 142 should ignore this bit when it does not support the extension 143 described in this document. Since the sender of the DATA chunk is 144 able to handle this case, there is no requirement for negotiating the 145 feature described in this document. 147 6. IANA Considerations 149 There are no actions required from IANA. 151 7. Security Considerations 153 This document does not add any additional security considerations in 154 addition to the ones given in [RFC4960]. 156 8. Normative References 158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 159 Requirement Levels", BCP 14, RFC 2119, March 1997. 161 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 162 RFC 4960, September 2007. 164 Authors' Addresses 166 Michael Tuexen 167 Muenster Univ. of Applied Sciences 168 Stegerwaldstr. 39 169 48565 Steinfurt 170 Germany 172 Email: tuexen@fh-muenster.de 174 Irene Ruengeler 175 Muenster Univ. of Applied Sciences 176 Stegerwaldstr. 39 177 48565 Steinfurt 178 Germany 180 Email: i.ruengeler@fh-muenster.de 182 Randall R. Stewart 183 Researcher 184 Chapin, SC 29036 185 USA 187 Phone: 188 Email: randall@lakerest.net