Internet Engineering Task Force INTERNET-DRAFT Eddie Kohler draft-kohler-dcp-ccid0-00.txt Sally Floyd ACIRI 13 July 2001 Expires: January 2002 Profile for DCP Congestion Control ID 0: Single-Window Congestion Control Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC 2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document contains the profile for Congestion Control Identifier 0, Single-Window Congestion Control, in the Datagram Control Protocol (DCP) [DCP]. DCP implements a congestion-controlled, unreliable flow of datagrams suitable for use by applications such as streaming media. The Single- Window Congestion Control CCID is used by senders that promise to send no data whatsoever, except possibly for a single initial window of data sent at the beginning of the connection. Kohler/Floyd [Page 1] INTERNET-DRAFT Expires: January 2002 July 2001 Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3 1.1. Usage Scenario . . . . . . . . . . . . . . . . . . . 3 1.2. Example Half-Connection. . . . . . . . . . . . . . . 4 2. Connection Establishment. . . . . . . . . . . . . . . . 4 3. Congestion Control on Data Packets. . . . . . . . . . . 4 4. Acknowledgements. . . . . . . . . . . . . . . . . . . . 4 4.1. Congestion Control on Acknowledgements . . . . . . . 4 4.2. Quiescence . . . . . . . . . . . . . . . . . . . . . 5 4.3. Acknowledgements of Acknowledgements . . . . . . . . 5 5. Explicit Congestion Notification. . . . . . . . . . . . 5 6. Relevant Options and Features . . . . . . . . . . . . . 5 7. Application Requirements. . . . . . . . . . . . . . . . 5 8. Thanks. . . . . . . . . . . . . . . . . . . . . . . . . 5 9. References. . . . . . . . . . . . . . . . . . . . . . . 5 10. Authors' Addresses . . . . . . . . . . . . . . . . . . 6 Kohler/Floyd [Page 2] INTERNET-DRAFT Expires: January 2002 July 2001 1. Introduction This document contains the profile for Congestion Control Identifier 0, Single-Window Congestion Control, in the Datagram Control Protocol (DCP). DCP uses Congestion Control Identifiers, or CCIDs, to specify the congestion control mechanism in use on a half-connection. (A half- connection might consist of data packets sent from DCP A to DCP B, plus acknowledgements sent from DCP B to DCP A. DCP A is the HC- Sender, and DCP B the HC-Receiver, for this half-connection. In this document, we abbreviate HC-Sender and HC-Receiver as "sender" and "receiver", respectively.) The Single-Window Congestion Control CCID implies that the sender will send no data packets, except for at most an initial window's worth at the beginning of the connection. (This initial window is calculated as for TCP; currently, it is 2 packets.) It is suitable for senders who have almost no data to send -- for example, for clients in a client-server streaming media connection, where the clients might make an application request to start off the connection, but then keep quiet forever. We note that this draft is rough and incomplete, and needs considerably more attention. In particular, we have not yet decided how to deal with losses within the initial window of packets. 1.1. Usage Scenario Single-Window Congestion Control was designed for the potentially common case of a client connecting to a data stream not requiring any application feedback -- for example, a streaming media connection. (Current popular streaming-media protocols include application feedback to report congestion. That's unnecessary in DCP, which reports congestion events itself.) Using CCID 0 for the client's half-connection explicitly informs the server that the client will never have data to send. This can simplify the server's implementation: for example, the server need not keep track of detailed acknowledgement information for the client's packets. Some high-use services might choose to force their clients to use CCID 0, since then they would not have to deal with any client data. Note, however, that DCP was designed so that a quiescent half- connection causes absolutely no overhead. Any quiescent CCID behaves the same as CCID 0. The use of CCID 0 is entirely optional, and has almost no performance effect in terms of numbers of packets sent, or packet sizes sent, compared to sending the same (small) number of packets with a different CCID. Kohler/Floyd Section 1.1. [Page 3] INTERNET-DRAFT Expires: January 2002 July 2001 Compensating for losses within the initial window of data is a question for further research. 1.2. Example Half-Connection TBA. 2. Connection Establishment No special options or features are strictly necessary to set up a half-connection using CCID 0. Since half-connections begin in CCID 0, it may not even be necessary to negotiate the CCID. However, if the sender plans to send any data in its allowed initial window, the sender SHOULD negotiate the Use Ack Vector feature. 3. Congestion Control on Data Packets Since CCID 0 allows the sender to send at most one initial window's worth of data, there is no need for any congestion control mechanism for data packets. The initial window is defined by TCP; currently, its value is 2 packets. TCP senders may send an initial window's worth of data before receiving any congestion feedback. Therefore, CCID 0's behavior here is no worse than TCP. In a A-to-B half-connection using CCID 0, DCP A MUST drop every packet the application tries to send beyond the initial window. Furthermore, DCP B SHOULD reset the connection if DCP A sends more than an initial window of data packets. We have not yet determined how to handle loss events in CCID 0's allowed initial window of data. One solution might be to implement reliable transmission of this window in the kernel, using a simple exponential backoff. 4. Acknowledgements Any half-connection using CCID 0 is quiescent for most of its lifetime. During this period, no acknowledgements need be sent. During the initial window, DCP B SHOULD send acknowledgements to DCP A using Ack Vector, if Use Ack Vector was negotiated. 4.1. Congestion Control on Acknowledgements Since there are at most an initial window's worth of acknowledgements, there is no need for any congestion control on acknowledgements. Kohler/Floyd Section 4.1. [Page 4] INTERNET-DRAFT Expires: January 2002 July 2001 4.2. Quiescence This section refers to quiescence in the DCP sense (see section 6.1 of [DCP]): How does a CCID 0 receiver determine that the corresponding sender is not sending any data? The receiver detects that the sender has gone quiescent after receiving three consecutive DCP-Ack packets from the sender (not counting initial feature negotiation). If the other half-connection has any data to send whatsoever, this should happen almost immediately. CCID 0 half-connections stay quiescent permanently: after going quiescent, they never send data again. 4.3. Acknowledgements of Acknowledgements There is no need for the sender to acknowledge the receiver's acknowledgements. 5. Explicit Congestion Notification Senders using CCID 0 perform no worse than TCP, despite their lack of active congestion control, due to the extremely limited amount of data they send. All DCP-Data and DCP-Ack packets for CCID 0 SHOULD set ECN-Capable Transport on their packets, regardless of the value of the ECN Capable feature. There should be at most 2*(initial window) such packets. There is no need for the receiver to echo the ECN Nonce. 6. Relevant Options and Features CCID 0 optionally uses the Ack Vector option and the Use Ack Vector feature. 7. Application Requirements Obviously, an application using CCID 0 cannot send more than an initial window's worth of data. 8. Thanks We thank Mark Handley and Jitendra Padhye for their help in defining CCID 0. 9. References [DCP] Eddie Kohler, Mark Handley, Sally Floyd, and Jitendra Padhye. Datagram Control Protocol (DCP). Work in progress. Kohler/Floyd Section 9. [Page 5] INTERNET-DRAFT Expires: January 2002 July 2001 [RFC 2026] S. Bradner. The Internet Standards Process -- Revision 3. RFC 2026. 10. Authors' Addresses Eddie Kohler Sally Floyd AT&T Center for Internet Research at ICSI (ACIRI), ICSI, 1947 Center Street, Suite 600 Berkeley, CA 94704. Kohler/Floyd Section 10. [Page 6]