idnits 2.17.1 draft-kohler-dccp-ccid3-drops-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 349. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (3 July 2007) is 6134 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 3448 (Obsoleted by RFC 5348) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Kohler 3 INTERNET-DRAFT UCLA 4 draft-kohler-dccp-ccid3-drops-01.txt 3 July 2007 5 Expires: 3 January 2008 7 Datagram Congestion Control Protocol (DCCP) 8 Congestion Control ID 3 Dropped Packets Option 10 Status of This Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of 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 3 January 2008. 35 Abstract 37 This document describes the Dropped Packets option, a mechanism for 38 reporting the number of lost and marked packets per loss interval in 39 the Datagram Congestion Control Protocol (DCCP)'s Congestion Control 40 ID 3, TCP-Friendly Rate Control. This option may be useful for 41 applications that need to know precisely how many packets are being 42 dropped. 44 Table of Contents 46 1. Introduction ....................................................2 47 2. Conventions .....................................................3 48 3. Options and Features ............................................3 49 3.1. Dropped Packets Option .....................................4 50 3.1.1. Example .............................................5 51 3.2. Send Dropped Packets Feature ...............................6 52 4. Security Considerations .........................................6 53 5. IANA Considerations .............................................6 54 6. Thanks ..........................................................6 55 Normative References ...............................................7 57 List of Tables 59 Table 1: Additional DCCP CCID 3 Options ............................3 60 Table 2: Additional DCCP CCID 3 Feature Numbers ....................4 62 1. Introduction 64 The Datagram Congestion Control Protocol (DCCP) [RFC4340] allows the 65 use of several distinct congestion control mechanisms. One of these, 66 Congestion Control Identifier 3 [RFC4342], specifies the use of TCP- 67 Friendly Rate Control (TFRC) [RFC3448]. The core information 68 reported by CCID 3 receivers is a list of recent loss intervals, 69 where a loss interval begins with a lost or ECN-marked data packet; 70 continues with at most one round-trip time's worth of packets that 71 may or may not be lost or marked; and completes with an arbitrarily 72 long series of non-dropped, non-marked data packets. Loss intervals 73 model the congestion behavior of TCP NewReno senders, which reduce 74 their sending rate at most once per window of data packets. 75 Consequently, the number of packets lost in a loss interval is not 76 important for either TCP's or TFRC's congestion response. CCID 3's 77 Loss Intervals option reports the length of each loss interval's 78 lossy part, not the number of packets that were actually lost or 79 marked in that lossy part. 81 Nevertheless, applications and experimental variants of TFRC, such as 82 the Small Packet variant, may be interested in the number of packets 83 lost or marked in a loss interval, over and above the length of the 84 loss interval in packets. This document specifies the Dropped 85 Packets option, a CCID 3-specific option that reports this 86 information. Together with the existing Loss Intervals option, the 87 Dropped Packets option allows CCID 3 senders to discover exactly how 88 many packets were dropped from each loss interval. 90 The mechanisms in this document do not change existing CCID 3 91 congestion response behavior. CCID 3's congestion response still 92 depends entirely on loss interval lengths, not the number of packets 93 dropped per loss interval. Most CCID 3 senders will therefore ignore 94 the contents of any Dropped Packets options they receive. Sending 95 applications may, however, be interested in Dropped Packets 96 information. 98 2. Conventions 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 All multi-byte numerical quantities in CCID 3, such as arguments to 105 options, are transmitted in network byte order (most significant byte 106 first). 108 A DCCP half-connection consists of the application data sent by one 109 endpoint and the corresponding acknowledgements sent by the other 110 endpoint. The terms "HC-Sender" and "HC-Receiver" denote the 111 endpoints sending application data and acknowledgements, 112 respectively. Since CCIDs apply at the level of half-connections, we 113 abbreviate HC-Sender to "sender" and HC-Receiver to "receiver" in 114 this document. See [RFC4340] for more discussion. 116 For simplicity, we say that senders send DCCP-Data packets and 117 receivers send DCCP-Ack packets. Both of these categories are meant 118 to include DCCP-DataAck packets. 120 The phrases "ECN-marked" and "marked" refer to packets marked ECN 121 Congestion Experienced unless otherwise noted. 123 3. Options and Features 125 This document defines a single CCID 3-specific option, Dropped 126 Packets. 128 Option DCCP- Section 129 Type Length Meaning Data? Reference 130 ----- ------ ------- ----- --------- 131 195 variable Dropped Packets N 3.1 133 Table 1: Additional DCCP CCID 3 Options 135 The "DCCP-Data?" column indicates that Dropped Packets MUST be 136 ignored when it occurs on a DCCP-Data packet. 138 A CCID 3-specific feature governing the use of the Dropped Packets 139 option is also defined. 141 Rec'n Initial Section 142 Number Meaning Rule Value Req'd Reference 143 ------ ------- ----- ----- ----- --------- 144 195 Send Dropped Packets SP 0 N 3.2 146 Table 2: Additional DCCP CCID 3 Feature Numbers 148 The column meanings are described in [RFC4340], Table 4. "Rec'n 149 Rule" defines the feature's reconciliation rule, where "SP" means 150 server-priority. "Req'd" specifies whether every CCID 3 151 implementation MUST understand a feature; Send Dropped Packets is 152 optional, in that it behaves like an extension ([RFC4340], Section 153 15). 155 3.1. Dropped Packets Option 157 +--------+--------+-------...-------+--------+------- 158 |11000011| Length | Drop Count | More Drop Counts... 159 +--------+--------+-------...-------+--------+------- 160 Type=195 3 bytes 162 The receiver reports the number of lost or marked packets in its 163 recently observed loss intervals using a Dropped Packets option. 165 The Dropped Packets option contains information about one to 84 166 consecutive loss intervals, always including the most recent loss 167 interval. As with CCID 3's Loss Intervals option, intervals are 168 listed in reverse chronological order. Should more than 84 loss 169 intervals need to be reported, multiple Dropped Packets options can 170 be sent; the second option begins where the first left off, and so 171 forth. 173 One Drop Count is specified per loss interval. Drop Count is a 174 24-bit number that equals the number of packets lost or received ECN- 175 marked during the corresponding loss interval. By definition, this 176 number MUST NOT exceed the corresponding loss interval's Loss Length. 178 Dropped Packets options SHOULD be sent in tandem with corresponding 179 Loss Intervals options. Consider a CCID 3 receiver that is reporting 180 Dropped Packets information. When this receiver sends a feedback 181 packet containing information about the N most recent loss intervals 182 (packaged in one or more Loss Intervals options), it SHOULD include 183 on the same feedback packet one or more Dropped Packets options 184 covering exactly those N loss intervals. CCID 3 senders MUST ignore 185 Drop Counts information for loss intervals not covered by a Loss 186 Intervals option on the same feedback packet. Conversely, a CCID 3 187 sender might want to interpolate Drop Counts information for a loss 188 interval not covered by any Dropped Packets options; such a sender 189 SHOULD use the corresponding loss interval's Loss Length as its Drop 190 Count. 192 Each loss interval's Drop Count MUST by definition be less than or 193 equal to its Loss Length. A Drop Count that exceeds the 194 corresponding Loss Length MUST be ignored. 196 3.1.1. Example 198 Consider the following sequence of packets, where "-" represents a 199 safely delivered packet and "*" represents a lost or marked packet. 200 This sequence is repeated from [RFC4342]. 202 Sequence 203 Numbers: 0 10 20 30 40 44 204 | | | | | | 205 ----------*--------***-*--------*----------*- 207 Assuming that packet 43 was lost, not marked, this sequence might be 208 divided into loss intervals as follows: 210 0 10 20 30 40 44 211 | | | | | | 212 ----------*--------***-*--------*----------*- 213 \________/\_______/\___________/\_________/ 214 L0 L1 L2 L3 216 A Loss Intervals option sent on a packet with Acknowledgement Number 217 44 to acknowledge this set of loss intervals might contain the bytes 218 193,39,2, 0,0,10, 128,0,1, 0,0,10, 0,0,8, 0,0,5, 0,0,10, 0,0,8, 219 0,0,1, 0,0,8, 0,0,10, 128,0,0, 0,0,15; for interpretation of this 220 option, see [RFC4342]. A Dropped Packets option sent in tandem on 221 this packet would contain the bytes 195,14, 0,0,1, 0,0,4, 0,0,1, 222 0,0,0. This is interpreted as follows. 224 195 The Dropped Packets option number. 226 14 The length of the option, including option type and length bytes. 227 This option contains information about (14 - 2)/3 = 4 loss 228 intervals. Note that the two most recent sequence numbers are 229 not yet part of any loss interval -- the Loss Intervals option 230 includes them in its Skip Length -- and are thus not included in 231 the Dropped Packets option. 233 0,0,1 234 These bytes define the Drop Count for L3, which is 1. As 235 required, the Drop Count is less than or equal to L3's Loss 236 Length, which is also 1. 238 0,0,4 239 The Drop Count for L2 is 4. 241 0,0,1 242 The Drop Count for L1 is 1. 244 0,0,0 245 Finally, the Drop Count for L0 is 0. 247 3.2. Send Dropped Packets Feature 249 The Send Dropped Packets feature lets CCID 3 endpoints negotiate 250 whether the receiver MUST provide Dropped Packets options on its 251 acknowledgements. DCCP A sends a "Change R(Send Dropped Packets, 1)" 252 option to ask DCCP B to send Dropped Packets options as part of its 253 acknowledgement traffic. 255 Send Dropped Packets has feature number 195 and is server-priority. 256 It takes one-byte Boolean values. DCCP B MUST send Dropped Packets 257 options on its acknowledgements when Send Dropped Packets/B is one, 258 although it MAY send Dropped Packets options even when Send Dropped 259 Packets/B is zero. Values of two or more are reserved. A CCID 3 260 half-connection starts with Send Dropped Packets equal to zero. 262 4. Security Considerations 264 The Dropped Packets option does not affect the existing security 265 considerations for DCCP CCID 3, which have been discussed in 266 [RFC4340] and [RFC4342]. For instance, the Dropped Packets option 267 neither helps nor hinders the existing CCID 3 mechanisms for ECN 268 Nonce verification. 270 5. IANA Considerations 272 This specification allocates two values in namespaces managed by 273 IANA. Specifically, the value 195 is allocated from the DCCP CCID 274 3-specific option type registry for the Dropped Packets option (Table 275 1), and the value 195 is allocated from the DCCP CCID 3-specific 276 feature number registry for the Send Dropped Packets feature (Table 277 2). 279 6. Thanks 281 Thanks to Sally Floyd for inspiring this document. 283 Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, March 1997. 288 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, 289 "TCP Friendly Rate Control (TFRC): Protocol 290 Specification", RFC 3448, January 2003. 292 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 293 Congestion Control Protocol (DCCP)", RFC 4340, March 294 2006. 296 [RFC4342] Floyd, S., E. Kohler, and J. Padhye, "Profile for 297 Datagram Congestion Control Protocol (DCCP) Congestion 298 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 299 4342, March 2006. 301 Authors' Addresses 303 Eddie Kohler 304 4531C Boelter Hall 305 UCLA Computer Science Department 306 Los Angeles, CA 90095 307 USA 309 EMail: kohler@cs.ucla.edu 311 Full Copyright Statement 313 Copyright (C) The IETF Trust (2007). 315 This document is subject to the rights, licenses and restrictions 316 contained in BCP 78, and except as set forth therein, the authors 317 retain all their rights. 319 This document and the information contained herein are provided on an 320 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 321 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 322 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 323 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 324 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 325 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 327 Intellectual Property 329 The IETF takes no position regarding the validity or scope of any 330 Intellectual Property Rights or other rights that might be claimed to 331 pertain to the implementation or use of the technology described in 332 this document or the extent to which any license under such rights 333 might or might not be available; nor does it represent that it has 334 made any independent effort to identify any such rights. Information 335 on the procedures with respect to rights in RFC documents can be 336 found in BCP 78 and BCP 79. 338 Copies of IPR disclosures made to the IETF Secretariat and any 339 assurances of licenses to be made available, or the result of an 340 attempt made to obtain a general license or permission for the use of 341 such proprietary rights by implementers or users of this 342 specification can be obtained from the IETF on-line IPR repository at 343 http://www.ietf.org/ipr. 345 The IETF invites any interested party to bring to its attention any 346 copyrights, patents or patent applications, or other proprietary 347 rights that may cover technology that may be required to implement 348 this standard. Please address the information to the IETF at ietf- 349 ipr@ietf.org. 351 Acknowledgement 353 Funding for the RFC Editor function is provided by the IETF 354 Administrative Support Activity (IASA).