idnits 2.17.1 draft-kohler-dcp-ccid0-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([DCP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 146: '... sender SHOULD negotiate the Use Ac...' RFC 2119 keyword, line 157: '...on using CCID 0, DCP A MUST drop every...' RFC 2119 keyword, line 159: '...rthermore, DCP B SHOULD reset the conn...' RFC 2119 keyword, line 171: '...al window, DCP B SHOULD send acknowled...' RFC 2119 keyword, line 203: '...ckets for CCID 0 SHOULD set ECN-Capabl...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (21 November 2001) is 8164 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'DCP' ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force 2 INTERNET-DRAFT Eddie Kohler 3 draft-kohler-dcp-ccid0-01.txt Sally Floyd 4 ACIRI 5 21 November 2001 6 Expires: May 2002 8 Profile for DCP Congestion Control ID 0: 9 Single-Window Congestion Control 11 Status of this Document 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of [RFC 2026]. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 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 This document contains the profile for Congestion Control 33 Identifier 0, Single-Window Congestion Control, in the 34 Datagram Control Protocol (DCP) [DCP]. DCP implements a 35 congestion-controlled, unreliable flow of datagrams suitable 36 for use by applications such as streaming media. The Single- 37 Window Congestion Control CCID is used by senders that promise 38 to send no data whatsoever, except possibly for a single 39 initial window of data sent at the beginning of the 40 connection. 42 Table of Contents 44 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3 45 1.1. Usage Scenario . . . . . . . . . . . . . . . . . . . 3 46 1.2. Example Half-Connection. . . . . . . . . . . . . . . 4 47 2. Connection Establishment. . . . . . . . . . . . . . . . 4 48 3. Congestion Control on Data Packets. . . . . . . . . . . 4 49 4. Acknowledgements. . . . . . . . . . . . . . . . . . . . 5 50 4.1. Congestion Control on Acknowledgements . . . . . . . 5 51 4.2. Quiescence . . . . . . . . . . . . . . . . . . . . . 5 52 4.3. Acknowledgements of Acknowledgements . . . . . . . . 5 53 5. Explicit Congestion Notification. . . . . . . . . . . . 5 54 6. Relevant Options and Features . . . . . . . . . . . . . 6 55 7. Application Requirements. . . . . . . . . . . . . . . . 6 56 8. Thanks. . . . . . . . . . . . . . . . . . . . . . . . . 6 57 9. References. . . . . . . . . . . . . . . . . . . . . . . 6 58 10. Authors' Addresses . . . . . . . . . . . . . . . . . . 6 60 1. Introduction 62 This document contains the profile for Congestion Control Identifier 63 0, Single-Window Congestion Control, in the Datagram Control 64 Protocol (DCP). 66 DCP uses Congestion Control Identifiers, or CCIDs, to specify the 67 congestion control mechanism in use on a half-connection. (A half- 68 connection might consist of data packets sent from DCP A to DCP B, 69 plus acknowledgements sent from DCP B to DCP A. DCP A is the HC- 70 Sender, and DCP B the HC-Receiver, for this half-connection. In this 71 document, we abbreviate HC-Sender and HC-Receiver as "sender" and 72 "receiver", respectively.) 74 The Single-Window Congestion Control CCID implies that the sender 75 will send no data packets, except for at most an initial window's 76 worth at the beginning of the connection. (This initial window is 77 calculated as for TCP; currently, it is two packets. [RFC 2581]) It 78 is suitable for senders who have almost no data to send -- for 79 example, for clients in a client-server streaming media connection, 80 where the clients might make an application request to start off the 81 connection, but then keep quiet forever. 83 We note that this draft is incomplete, in that we have not yet 84 decided how to deal with losses within the initial window of 85 packets. 87 1.1. Usage Scenario 89 Single-Window Congestion Control was designed for the potentially 90 common case of a client connecting to a data stream not requiring 91 any application feedback -- for example, a streaming media 92 connection. (Current popular streaming-media protocols include 93 application feedback to report congestion. That's unnecessary in 94 DCP, which reports congestion events itself.) Using CCID 0 for the 95 client's half-connection explicitly informs the server that the 96 client will never have data to send, other than the initial window. 97 This can simplify the server's implementation: for example, the 98 server need not keep track of detailed acknowledgement information 99 for the client's packets. Some high-use services might choose to 100 force their clients to use CCID 0, since then they would not have to 101 deal with any client data. 103 Note, however, that DCP was designed so that a quiescent half- 104 connection causes absolutely no overhead. Any quiescent CCID behaves 105 the same as CCID 0. The use of CCID 0 is entirely optional, and has 106 almost no performance effect in terms of numbers of packets sent, or 107 packet sizes sent, compared to sending the same (small) number of 108 packets with a different CCID. 110 Compensating for losses within the initial window of data is a 111 question for further research. 113 1.2. Example Half-Connection 115 This example is of a half-connection using Single-Window Congestion 116 Control specified by CCID 0. The "sender" is the HC-Sender, and the 117 "receiver" is the HC-Receiver. In this example the sender has 118 negotiated the Use Ack Vector feature. 120 (1) The sender sends at most an initial window of DCP-Data packets, 121 where the initial window is the same as the initial congestion 122 window ``cwnd'' in TCP. Each DCP-Data packet uses a sequence 123 number. 125 Each DCP-Data packet may be sent as ECN-Capable with either the 126 ECT(0) or the ECT(1) codepoint set, as described in [ECN NONCE 127 DRAFT]. 129 (2) The receiver acknowledges any DCP-Data packets with DCP-Ack or 130 DCP-DataAck packets containing an Ack Vector. 132 Since no packets are sent beyond the initial window, the 133 receiver is not required to return the ECN Nonce in the DCP-Ack 134 packet. The DCP-Ack packets from the receiver may be sent as 135 ECN-Capable with ECT(0). 137 (3) The sender sends no new DCP-Data packets after the initial 138 window of data. 140 2. Connection Establishment 142 No special options or features are strictly necessary to set up a 143 half-connection using CCID 0. Since half-connections begin in CCID 144 0, it is not strictly necessary to negotiate the CCID. However, if 145 the sender plans to send any data in its allowed initial window, the 146 sender SHOULD negotiate the Use Ack Vector feature. 148 3. Congestion Control on Data Packets 150 Since CCID 0 allows the sender to send at most one initial window's 151 worth of data, there is no need for any congestion control mechanism 152 for data packets. The initial window is defined by TCP; currently, 153 its value is two packets. TCP senders may send an initial window's 154 worth of data before receiving any congestion feedback. Therefore, 155 CCID 0's behavior here is no worse than TCP. 157 In a A-to-B half-connection using CCID 0, DCP A MUST drop every 158 packet the application tries to send beyond the initial window. 159 Furthermore, DCP B SHOULD reset the connection if DCP A sends more 160 than an initial window of data packets. 162 We have not yet determined how to handle loss events in CCID 0's 163 allowed initial window of data. One solution might be to implement 164 reliable transmission of this window in DCP, using a simple 165 exponential backoff. 167 4. Acknowledgements 169 Any half-connection using CCID 0 is quiescent for most of its 170 lifetime. During this period, no acknowledgements need be sent. 171 During the initial window, DCP B SHOULD send acknowledgements to DCP 172 A using Ack Vector, if Use Ack Vector was negotiated. 174 4.1. Congestion Control on Acknowledgements 176 Since there are at most an initial window's worth of 177 acknowledgements, there is no need for any congestion control on 178 acknowledgements. 180 4.2. Quiescence 182 This section refers to quiescence in the DCP sense (see section 6.1 183 of [DCP]): How does a CCID 0 receiver determine that the 184 corresponding sender is not sending any data? 186 The receiver, DCP B, detects that the sender, DCP A, has gone 187 quiescent after receiving three consecutive DCP-Ack packets from A 188 (not counting initial feature negotiation). If DCP B has any data to 189 send whatsoever, this should happen almost immediately. CCID 0 half- 190 connections stay quiescent permanently: after going quiescent, they 191 never send data again. 193 4.3. Acknowledgements of Acknowledgements 195 There is no need for the sender to acknowledge the receiver's 196 acknowledgements. 198 5. Explicit Congestion Notification 200 Senders using CCID 0 perform no worse than TCP-like Congestion 201 Control, despite their lack of active congestion control, due to the 202 extremely limited amount of data they send. All DCP-Data and DCP-Ack 203 packets for CCID 0 SHOULD set ECN-Capable Transport on their 204 packets, if the ECN Capable feature has been negotiated. There 205 should be at most 2*(initial window) such packets. 207 It is not required for the receiver to echo the ECN Nonce. The ECN 208 Nonce information is not used by the sender for congestion control 209 for this connection, as the sender has no further data to send, but 210 the nonce could be of use for other purposes, e.g., in cases with 211 sharing of congestion control state between multiple connections. 213 6. Relevant Options and Features 215 CCID 0 optionally uses the Ack Vector option and the Use Ack Vector 216 feature. 218 7. Application Requirements 220 Obviously, an application using CCID 0 cannot send more than an 221 initial window's worth of data. 223 8. Thanks 225 We thank Mark Handley and Jitendra Padhye for their help in defining 226 CCID 0. 228 9. References 230 [DCP] Eddie Kohler, Mark Handley, Sally Floyd, and Jitendra Padhye. 231 Datagram Control Protocol (DCP). Work in progress. 233 [RFC 2026] S. Bradner. The Internet Standards Process -- Revision 3. 234 RFC 2026. 236 [RFC 2581] W. Stevens, M. Allman, and V. Paxson, "TCP Congestion 237 Control", RFC 2581, April 1999. 239 10. Authors' Addresses 241 Eddie Kohler 242 Sally Floyd 244 AT&T Center for Internet Research at ICSI (ACIRI), 245 ICSI, 246 1947 Center Street, Suite 600 247 Berkeley, CA 94704.