idnits 2.17.1 draft-stewart-srwnd-sctp-sigtran-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 4) being 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that the parameter type field upper two bits dictates that any parameter not understood should be skipped and reported to the sender with an Operational Error. If an Operational Error is received that indicates that the 'Stream Flow Limit Request' is not understood, the sender of the limit request MUST not send subsequent limit requests. The endpoint SHOULD also inform the upper level application that the peer endpoint does not support this feature. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2402' is defined on line 285, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDIP' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. R. Stewart 2 INTERNET-DRAFT M. A. Ramalho 3 Cisco Systems 4 Q. Xie 5 Motorola 6 P. Conrad 7 Temple University 8 M. Rose 9 Invisible Worlds, Inc 11 expires in six months November 3,2000 13 SCTP Stream based flow control 14 16 Status of This Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts are 20 working documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 Taking advantage of the extensibility of SCTP, this document adds 33 a standard method for SCTP to provide a stream based flow control 34 mechanism. 36 Table Of Contents 37 1. Introduction...............................................1 38 2. Conventions................................................2 39 3. Parameter Formats..........................................2 40 3.1 New Parameter Types.......................................2 41 3.2 Stream Flow Limit Change..................................2 42 4. Procedures.................................................3 43 4.1 Stream Receiver side procedures...........................3 44 4.2 Stream Sender side procedures.............................4 45 5. Security Considerations....................................4 46 6. IANA considerations........................................5 47 7. Authors' Addresses.........................................5 48 7. References.................................................5 49 Appendix A Suggested application usage characteristics......6 51 1. Introduction 53 Taking advantage of the extensibility of SCTP, this document adds 54 a standard method for SCTP to provide a stream based flow control 55 Internet draft SCTP Stream based flow control November 2000 57 mechanism. This mechanism uses the reliable chunk transfer 58 extension [ADDIP] to carry the flow control restrictions to 59 peer endpoints that support this option. Some of the benefits 60 of this extension are: 62 A) The ability to minimize the occurrence of a single stream 63 hogging all transport level resources (e.g. a_rwnd). 65 B) The ability to dynamically change the stream buffering 66 limits as the situation changes within the application. 68 2. Conventions 70 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 71 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they 72 appear in this document, are to be interpreted as described in 73 RFC 2119 [RFC2119]. 75 3. Parameter Formats 77 Stream flow control requests MUST be delivered in a reliable 78 fashion. This information is used by the sending SCTP peer to limit 79 how much information one stream may send (based upon feedback from the 80 receiving peers application layer). Being that these flow changes MUST 81 be reliably delivered and are considered control information, the 82 methods specified in [ADDIP] is used to communicate this 83 information. Therefore this document will only specify the new 84 parameter required to carry the flow control requests from the 85 receiver side to the sender side. For the proper procedures for the 86 actual Reliable Chunk Transfer please see [ADDIP]. 88 3.1 New Parameter Types 90 Variable Parameters Type Value 91 ------------------------------------------------- 92 Stream Flow limit Request 32771 (0xC003) 94 3.2 Stream Flow Limit Change 96 0 1 2 3 97 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 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Type = 32771 | Length = Variable | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | Stream Number 1 | Flow Limit 1 | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 \ / 104 / \ 105 \ / 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Stream Number N | Flow Limit N | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 Internet draft SCTP Stream based flow control November 2000 112 Stream Number n : 16 bits (unsigned integer) 114 This is the stream number that is requesting a limit be placed 115 on the sender based on the applications receive buffer sizes. 117 Flow Limit n : 16 bits (unsigned integer) 119 This is the limit the receiver is requesting (in bytes) as to 120 the maximum amount of data that the receiver may accept. Note 121 that the value 0 holds a special meaning described in Section 4.1. 123 4. Procedures 125 A stream in SCTP is an uni-directional logical channel established from 126 one to another associated SCTP endpoint, within which all user 127 messages are delivered in sequence except for those submitted to the 128 unordered delivery service which may arrive out of sequence. Since 129 each stream is uni-directional and no feedback mechanism exists to 130 limit a sender, it is possible for one unique stream to hog all of the 131 transport level receiver window space. The mechanism defined here 132 attempts to alleviate this problem by allowing the receiver side to 133 communicate to the sender a limit on how much outstanding data may be 134 sent within a particular stream. 136 The procedures defined here are broken down into two sides: 138 o The stream receiver or peer requesting the limit. And, 140 o the stream sender side or peer that MUST honor the 141 limit request. 143 The receivers side is mainly involved with sending the request 144 to the peer. The senders side is where the actual limitations 145 and flow control will occur. 147 4.1 Stream Receiver side procedures 149 The receiver side SCTP makes decisions on stream flow 150 control based on upper layer input. Normally the upper layer makes a 151 request to limit all or a subset of the active streams that send data 152 to it via an API interface. How this decision is made is outside the 153 scope of this document but suggested usage characteristics can be 154 found in Appendix A [Editors note: appendix A will be completed 155 in a future draft]. 157 Any time flow limits are made known to the SCTP endpoint by the 158 application, the receiver side will create a Reliable Control Chunk 159 (based on the rules found in [ADDIP]) and attach to it one or more 160 stream flow limits with there respective stream number. If the 161 receiver wishes to remove all limits (previously placed on a 162 particular stream) it may do so by placing the special value '0' in 163 the 'Flow Limit' field. Once acknowledged by the peer endpoint the 164 receiver should consider the limit in place. 166 Internet draft SCTP Stream based flow control November 2000 168 Note that the parameter type field upper two bits dictates that any 169 parameter not understood should be skipped and reported to the sender 170 with an Operational Error. If an Operational Error is received that 171 indicates that the 'Stream Flow Limit Request' is not understood, the 172 sender of the limit request MUST not send subsequent limit 173 requests. The endpoint SHOULD also inform the upper level application 174 that the peer endpoint does not support this feature. 176 If the sender of the request receives a Operational Error indicating 177 that the REL-REQ chunk type (described in [ADDIP]) is not understood 178 then the sender must not send subsequent limit requests. The 179 endpoint SHOULD also inform the upper level application 180 that the peer endpoint does not support this feature. 182 4.2 Stream Sender side procedures 184 When a 'Stream Flow Limit Request' is received the sender MUST 185 record each flow limit with its appropriate stream. 187 After a limit is set on a stream the sender MUST obey the following rules 188 when sending to the peer on that stream: 190 R1) When the upper layer application attempts to send to the 191 peer on a stream, check the number of outstanding bytes 192 sent to that stream (those TSN's in queue to be sent, which 193 the cumulative TSN Acknowledgement has not passed, on this 194 stream) versus the limit set for that stream (The last received 195 limit for this stream is henceforth termed the current limit). 197 R2) If the number of outstanding bytes is greater than or 198 equal to the current limit, the SCTP endpoint MUST reject the 199 request and NOT queue the data for transmit. Instead it 200 SHOULD return an error to the sending application. 202 R3) If the number of outstanding bytes is less than the 203 current limit, validate that the data to be sent plus the 204 number of outstanding bytes is smaller than or equal to 205 this limit. If the user data plus the number of outstanding 206 bytes is smaller than or equal to the current limit accept 207 the data for transmit and queue the user data (increasing 208 the number of outstanding data bytes on this stream). If 209 the user data plus the number of outstanding bytes is larger 210 than the current limit for this stream, the SCTP endpoint MUST reject 211 the request and NOT queue the data for transmit and instead 212 SHOULD return an error to the application. 214 R4) Any time a stream limit is updated to the value of 0, consider 215 this indication to mean no limit is in effect for this stream. 217 Note that the effect of rule R3 above places a maximum size upon 218 a sender. Even though SCTP may be capable of sending and reassembling 219 larger user messages, by placing a flow limit on a stream this also 220 gates the largest single user message a receiver is willing to 221 accept. 223 5. Security Considerations 225 This extension is not deemed to create any additional security 226 hazards then currently exist in an SCTP association. All of the 227 threats and measures as defined in [RFC2960] are applicable to 228 this feature. 230 Internet draft SCTP Stream based flow control November 2000 232 6. IANA considerations 234 No new IANA considerations are added by this document. One new parameter 235 type is being allocated for use by this feature. 237 7. Authors' Addresses 239 Randall R. Stewart Tel: +1-815-342-5222 240 Cisco Systems, Inc. EMail: rrs@cisco.com 241 8745 W. Higgins Road, Suite 200 242 Chicago, Ill 60631 243 USA 245 Micheal A. Ramalho Tel: +1-732-809-0188 246 Cisco Systems, Inc. EMail: mramalho@cisco.com 247 1802 Rue de la Porte 248 Wall Township, NJ 0719-3784 250 Qiaobing Xie Tel: +1-847-632-3028 251 Motorola, Inc. EMail: qxie1@email.mot.com 252 1501 W. Shure Drive, #2309 253 Arlington Heights, IL 60004 254 USA 256 Phil Conrad Tel: +1-XXX-XXX-XXXX 257 Netlab Research Group Email conrad@joda.cis.temple.edu 258 Dept. Of Computer & 259 Information Sciences 260 Temple University 261 1805 N Broad St. 262 Philadelphia, PA 19122 263 USA 265 Marshall T. Rose Tel: +1 707 789 3700 266 Invisible Worlds, Inc. EMail: mrose@invisible.net 267 1179 North McDowell Boulevard URI: http://invisible.net/ 268 Petaluma, CA 94954-6559 269 USA 271 7. References 273 [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer, 274 T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, V. Paxson, 275 "Stream Control Transmission Protocol," RFC XXXX, October 2000. 277 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", 278 RFC 2026, October 1996. 280 Internet draft SCTP Stream based flow control November 2000 282 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 283 Requirement Levels", BCP 14, RFC 2119, March 1997. 285 [RFC2402] S. Kent, R. Atkinson., "IP Authentication Header.", 286 RFC 2402, November 1998. 288 [ADDIP] R. R. Stewart,Q. Xie, M. Tuexen, "SCTP Dynamic Addition 289 of IP addresses", Work in Progress, ietf draft. 291 Appendix A Suggested application usage characteristics 293 [ This section will be filled in in a future version of the draft ] 295 This Internet Draft expires in 6 months from November, 2000