Internet Engineering Task Force Eddie Kohler |
|
INTERNET-DRAFT UCLA |
|
draft-ietf-dccp-spec-08.txt Mark Handley |
draft-ietf-dccp-spec-07.txt Mark Handley |
Expires: 25 April 2005 UCL |
Expires: April 2005 UCL |
Sally Floyd |
|
ICIR |
|
25 October 2004 |
|
|
|
|
|
Datagram Congestion Control Protocol (DCCP) |
|
|
|
|
|
Status of this Memo |
|
|
|
This document is an Internet-Draft and is subject to all provisions |
This document is an Internet-Draft. |
of section 3 of RFC 3667. By submitting this Internet-Draft, each |
By submitting this Internet-Draft, we certify that any applicable |
author represents that any applicable patent or other IPR claims of |
patent or other IPR claims of which we are aware have been |
which he or she is aware have been or will be disclosed, and any of |
disclosed, or will be disclosed, and any of which we become aware |
which he or she become aware will be disclosed, in accordance with |
will be disclosed, in accordance with RFC 3668 (BCP 79). |
RFC 3668. |
By submitting this Internet-Draft, we accept the provisions of |
|
Section 3 of RFC 3667 (BCP 78). |
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." |
reference material or to cite them other than a "work in progress." |
|
|
The list of current Internet-Drafts can be accessed at |
|
http://www.ietf.org/ietf/1id-abstracts.txt. |
http://www.ietf.org/1id-abstracts.html |
|
|
The list of Internet-Draft Shadow Directories can be accessed at |
|
http://www.ietf.org/shadow.html. |
http://www.ietf.org/shadow.html |
|
|
This Internet-Draft will expire on 25 April 2005. |
|
|
|
Copyright Notice |
|
|
|
Copyright (C) The Internet Society (2004). All Rights Reserved. |
|
|
|
|
|
|
|
|
|
|
|
|
|
Kohler/Handley/Floyd [Page 1] |
|
|
|
INTERNET-DRAFT Expires: 25 April 2005 October 2004 |
|
|
|
|
|
TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: |
|
|
|
Changes since draft-ietf-dccp-spec-07.txt: |
|
|
|
* Many changes, not listed here, for WGLC. |
|
|
|
* The more stringent Sequence Number checks on DCCP-Sync and DCCP- |
|
SyncAck packets become SHOULD, not MAY. |
|
|
|
Changes since draft-ietf-dccp-spec-06.txt: |
|
|
|
* Change extended sequence numbers. Now 48-bit sequence numbers are |
|
MANDATORY, and all packet types except Data, Ack, and DataAck always |
|
use 48-bit sequence numbers. This change improves DCCP's robustness |
|
against blind attacks. |
|
|
|
* Removed empty Change options. |
|
|
|
* Allow preference list changes during feature negotiations (this |
|
seems easier to implement than the alternative). This required a |
|
new feature negotiation state, UNSTABLE. |
|
|
|
* Add Minimum Checksum Coverage feature. |
|
|
|
* Add Reset Congestion State option. |
|
|
|
* Simplify the implementation of CCID-specific option processing: no |
|
need to check whether the CCID feature is being negotiated. |
|
|
|
* Many more minor changes. |
|
|
|
Changes since draft-ietf-dccp-spec-05.txt: |
|
|
|
* Organization overhaul. |
|
|
|
* Add pseudocode for event processing. |
|
|
|
* Remove # NDP; replace with Ack Count. |
|
|
|
* Remove Identification, Challenge, ID Regime, and Connection Nonce. |
|
|
|
* Data Checksum (formerly Payload Checksum) uses a 32-bit CRC. |
|
|
|
* Switch location of non-negotiable features to clarify |
|
presentation; now the feature location controls its value. |
|
|
|
* Rename "value type" to "reconciliation rule". |
|
|
|
|
|
|
|
|
|
Kohler/Handley/Floyd [Page 3] |
|
|
|
INTERNET-DRAFT Expires: 25 April 2005 October 2004 |
|
|
|
|
|
Table of Contents |
|
|
|
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 10 |
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 7 |
2. Design Rationale. . . . . . . . . . . . . . . . . . . . . . . 11 |
2. Design Rationale. . . . . . . . . . . . . . . . . . . . . . . 8 |
3. Conventions and Terminology . . . . . . . . . . . . . . . . . 12 |
3. Conventions and Terminology . . . . . . . . . . . . . . . . . 9 |
3.1. Numbers and Fields . . . . . . . . . . . . . . . . . . . 12 |
3.1. Numbers and Fields . . . . . . . . . . . . . . . . . . . 9 |
3.2. Parts of a Connection. . . . . . . . . . . . . . . . . . 13 |
3.2. Parts of a Connection. . . . . . . . . . . . . . . . . . 9 |
3.3. Features . . . . . . . . . . . . . . . . . . . . . . . . 13 |
3.3. Features . . . . . . . . . . . . . . . . . . . . . . . . 10 |
3.4. Round-Trip Times . . . . . . . . . . . . . . . . . . . . 14 |
3.4. Round-Trip Times . . . . . . . . . . . . . . . . . . . . 10 |
3.5. Security Limitation. . . . . . . . . . . . . . . . . . . 14 |
3.5. Security Limitation. . . . . . . . . . . . . . . . . . . 11 |
3.6. Robustness Principle . . . . . . . . . . . . . . . . . . 14 |
3.6. Robustness Principle . . . . . . . . . . . . . . . . . . 11 |
4. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
4. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
4.1. Packet Types . . . . . . . . . . . . . . . . . . . . . . 15 |
4.1. Packet Types . . . . . . . . . . . . . . . . . . . . . . 11 |
4.2. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 16 |
4.2. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 13 |
4.3. States . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
4.3. States . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
4.4. Congestion Control . . . . . . . . . . . . . . . . . . . 19 |
4.4. Congestion Control . . . . . . . . . . . . . . . . . . . 15 |
4.5. Features . . . . . . . . . . . . . . . . . . . . . . . . 19 |
4.5. Features . . . . . . . . . . . . . . . . . . . . . . . . 16 |
4.6. Differences From TCP . . . . . . . . . . . . . . . . . . 20 |
4.6. Differences From TCP . . . . . . . . . . . . . . . . . . 17 |
4.7. Example Connection . . . . . . . . . . . . . . . . . . . 21 |
4.7. Example Connection . . . . . . . . . . . . . . . . . . . 18 |
5. Packet Formats. . . . . . . . . . . . . . . . . . . . . . . . 23 |
5. Header Formats. . . . . . . . . . . . . . . . . . . . . . . . 19 |
5.1. Generic Header . . . . . . . . . . . . . . . . . . . . . 23 |
5.1. Generic Header . . . . . . . . . . . . . . . . . . . . . 20 |
5.2. DCCP-Request Packets . . . . . . . . . . . . . . . . . . 27 |
5.2. DCCP-Request Header. . . . . . . . . . . . . . . . . . . 23 |
5.3. DCCP-Response Packets. . . . . . . . . . . . . . . . . . 28 |
5.3. DCCP-Response Header . . . . . . . . . . . . . . . . . . 23 |
5.4. DCCP-Data, DCCP-Ack, and DCCP-DataAck Packets. . . . . . 28 |
5.4. DCCP-Data, DCCP-Ack, and DCCP-DataAck Headers. . . . . . 24 |
5.5. DCCP-CloseReq and DCCP-Close Packets . . . . . . . . . . 30 |
5.5. DCCP-CloseReq and DCCP-Close Headers . . . . . . . . . . 26 |
5.6. DCCP-Reset Packets . . . . . . . . . . . . . . . . . . . 30 |
5.6. DCCP-Reset Header. . . . . . . . . . . . . . . . . . . . 26 |
5.7. DCCP-Sync and DCCP-SyncAck Packets . . . . . . . . . . . 33 |
5.7. DCCP-Sync and DCCP-SyncAck Headers . . . . . . . . . . . 29 |
5.8. Options. . . . . . . . . . . . . . . . . . . . . . . . . 34 |
5.8. Options. . . . . . . . . . . . . . . . . . . . . . . . . 30 |
5.8.1. Padding Option. . . . . . . . . . . . . . . . . . . 36 |
5.8.1. Padding Option. . . . . . . . . . . . . . . . . . . 31 |
5.8.2. Mandatory Option. . . . . . . . . . . . . . . . . . 36 |
5.8.2. Mandatory Option. . . . . . . . . . . . . . . . . . 31 |
6. Feature Negotiation . . . . . . . . . . . . . . . . . . . . . 37 |
6. Feature Negotiation . . . . . . . . . . . . . . . . . . . . . 32 |
6.1. Change Options . . . . . . . . . . . . . . . . . . . . . 37 |
6.1. Change Options . . . . . . . . . . . . . . . . . . . . . 33 |
6.2. Confirm Options. . . . . . . . . . . . . . . . . . . . . 38 |
6.2. Confirm Options. . . . . . . . . . . . . . . . . . . . . 33 |
6.3. Reconciliation Rules . . . . . . . . . . . . . . . . . . 38 |
6.3. Reconciliation Rules . . . . . . . . . . . . . . . . . . 34 |
6.3.1. Server-Priority . . . . . . . . . . . . . . . . . . 38 |
6.3.1. Server-Priority . . . . . . . . . . . . . . . . . . 34 |
6.3.2. Non-Negotiable. . . . . . . . . . . . . . . . . . . 39 |
6.3.2. Non-Negotiable. . . . . . . . . . . . . . . . . . . 34 |
6.4. Feature Numbers. . . . . . . . . . . . . . . . . . . . . 39 |
6.4. Feature Numbers. . . . . . . . . . . . . . . . . . . . . 35 |
6.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 40 |
6.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 35 |
6.6. Option Exchange. . . . . . . . . . . . . . . . . . . . . 41 |
6.6. Option Exchange. . . . . . . . . . . . . . . . . . . . . 37 |
6.6.1. Normal Exchange . . . . . . . . . . . . . . . . . . 42 |
6.6.1. Normal Exchange . . . . . . . . . . . . . . . . . . 37 |
6.6.2. Processing Received Options . . . . . . . . . . . . 42 |
6.6.2. Processing Received Options . . . . . . . . . . . . 38 |
6.6.3. Loss and Retransmission . . . . . . . . . . . . . . 44 |
6.6.3. Loss and Retransmission . . . . . . . . . . . . . . 40 |
6.6.4. Reordering. . . . . . . . . . . . . . . . . . . . . 45 |
6.6.4. Reordering. . . . . . . . . . . . . . . . . . . . . 41 |
6.6.5. Preference Changes. . . . . . . . . . . . . . . . . 46 |
6.6.5. Preference Changes. . . . . . . . . . . . . . . . . 42 |
6.6.6. Simultaneous Negotiation. . . . . . . . . . . . . . 46 |
6.6.6. Simultaneous Negotiation. . . . . . . . . . . . . . 42 |
6.6.7. Unknown Features. . . . . . . . . . . . . . . . . . 46 |
6.6.7. Unknown Features. . . . . . . . . . . . . . . . . . 42 |
6.6.8. Invalid Options . . . . . . . . . . . . . . . . . . 47 |
6.6.8. Invalid Options . . . . . . . . . . . . . . . . . . 43 |
6.6.9. Mandatory Feature Negotiation . . . . . . . . . . . 48 |
6.6.9. Mandatory Feature Negotiation . . . . . . . . . . . 43 |
|
6.6.10. Out-of-Band Agreement. . . . . . . . . . . . . . . 44 |
|
7. Sequence Numbers. . . . . . . . . . . . . . . . . . . . . . . 44 |
|
7.1. Variables. . . . . . . . . . . . . . . . . . . . . . . . 44 |
Kohler/Handley/Floyd [Page 5] |
7.2. Initial Sequence Numbers . . . . . . . . . . . . . . . . 45 |
|
|
INTERNET-DRAFT Expires: 25 April 2005 October 2004 |
7.3. Quiet Time . . . . . . . . . . . . . . . . . . . . . . . 46 |
|
7.4. Acknowledgement Numbers. . . . . . . . . . . . . . . . . 46 |
|
7.5. Validity and Synchronization . . . . . . . . . . . . . . 47 |
7. Sequence Numbers. . . . . . . . . . . . . . . . . . . . . . . 48 |
7.5.1. Sequence-Validity Rules . . . . . . . . . . . . . . 47 |
7.1. Variables. . . . . . . . . . . . . . . . . . . . . . . . 49 |
7.5.2. Handling Sequence-Invalid Packets . . . . . . . . . 49 |
7.2. Initial Sequence Numbers . . . . . . . . . . . . . . . . 49 |
7.5.3. Sequence and Acknowledgement Number |
7.3. Quiet Time . . . . . . . . . . . . . . . . . . . . . . . 50 |
Windows. . . . . . . . . . . . . . . . . . . . . . . . . . 50 |
7.4. Acknowledgement Numbers. . . . . . . . . . . . . . . . . 51 |
7.5.4. Sequence Window Feature . . . . . . . . . . . . . . 51 |
7.5. Validity and Synchronization . . . . . . . . . . . . . . 51 |
7.5.5. Sequence Number Attacks . . . . . . . . . . . . . . 52 |
7.5.1. Sequence and Acknowledgement Number |
7.5.6. Examples. . . . . . . . . . . . . . . . . . . . . . 53 |
Windows. . . . . . . . . . . . . . . . . . . . . . . . . . 52 |
7.6. Short Sequence Numbers . . . . . . . . . . . . . . . . . 54 |
7.5.2. Sequence Window Feature . . . . . . . . . . . . . . 53 |
7.6.1. Allow Short Sequence Numbers Feature. . . . . . . . 54 |
7.5.3. Sequence-Validity Rules . . . . . . . . . . . . . . 53 |
7.6.2. When to Avoid Short Sequence Numbers. . . . . . . . 55 |
7.5.4. Handling Sequence-Invalid Packets . . . . . . . . . 55 |
7.7. NDP Count and Detecting Application Loss . . . . . . . . 55 |
7.5.5. Sequence Number Attacks . . . . . . . . . . . . . . 56 |
7.7.1. Usage Notes . . . . . . . . . . . . . . . . . . . . 56 |
7.5.6. Examples. . . . . . . . . . . . . . . . . . . . . . 57 |
7.7.2. Send NDP Count Feature. . . . . . . . . . . . . . . 57 |
7.6. Short Sequence Numbers . . . . . . . . . . . . . . . . . 58 |
8. Event Processing. . . . . . . . . . . . . . . . . . . . . . . 57 |
7.6.1. Allow Short Sequence Numbers Feature. . . . . . . . 59 |
8.1. Connection Establishment . . . . . . . . . . . . . . . . 57 |
7.6.2. When to Avoid Short Sequence Numbers. . . . . . . . 59 |
8.1.1. Client Request. . . . . . . . . . . . . . . . . . . 57 |
7.7. NDP Count and Detecting Application Loss . . . . . . . . 60 |
8.1.2. Service Codes . . . . . . . . . . . . . . . . . . . 58 |
7.7.1. Usage Notes . . . . . . . . . . . . . . . . . . . . 61 |
8.1.3. Server Response . . . . . . . . . . . . . . . . . . 59 |
7.7.2. Send NDP Count Feature. . . . . . . . . . . . . . . 61 |
8.1.4. Init Cookie Option. . . . . . . . . . . . . . . . . 60 |
8. Event Processing. . . . . . . . . . . . . . . . . . . . . . . 61 |
8.1.5. Handshake Completion. . . . . . . . . . . . . . . . 61 |
8.1. Connection Establishment . . . . . . . . . . . . . . . . 62 |
8.2. Data Transfer. . . . . . . . . . . . . . . . . . . . . . 62 |
8.1.1. Client Request. . . . . . . . . . . . . . . . . . . 62 |
8.3. Termination. . . . . . . . . . . . . . . . . . . . . . . 62 |
8.1.2. Service Codes . . . . . . . . . . . . . . . . . . . 63 |
8.3.1. Abnormal Termination. . . . . . . . . . . . . . . . 64 |
8.1.3. Server Response . . . . . . . . . . . . . . . . . . 64 |
8.4. DCCP State Diagram . . . . . . . . . . . . . . . . . . . 64 |
8.1.4. Init Cookie Option. . . . . . . . . . . . . . . . . 65 |
8.5. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 65 |
8.1.5. Handshake Completion. . . . . . . . . . . . . . . . 66 |
9. Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . 69 |
8.2. Data Transfer. . . . . . . . . . . . . . . . . . . . . . 66 |
9.1. Header Checksum Field. . . . . . . . . . . . . . . . . . 69 |
8.3. Termination. . . . . . . . . . . . . . . . . . . . . . . 67 |
9.2. Header Checksum Coverage Field . . . . . . . . . . . . . 70 |
8.3.1. Abnormal Termination. . . . . . . . . . . . . . . . 69 |
9.2.1. Minimum Checksum Coverage Feature . . . . . . . . . 71 |
8.4. DCCP State Diagram . . . . . . . . . . . . . . . . . . . 69 |
9.3. Data Checksum Option . . . . . . . . . . . . . . . . . . 71 |
8.5. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 70 |
9.3.1. Check Data Checksum Feature . . . . . . . . . . . . 72 |
9. Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . 74 |
9.3.2. Usage Notes . . . . . . . . . . . . . . . . . . . . 73 |
9.1. Header Checksum Field. . . . . . . . . . . . . . . . . . 75 |
10. Congestion Control IDs . . . . . . . . . . . . . . . . . . . 73 |
9.2. Header Checksum Coverage Field . . . . . . . . . . . . . 76 |
10.1. Unspecified Sender-Based Congestion Control . . . . . . 74 |
9.2.1. Minimum Checksum Coverage Feature . . . . . . . . . 77 |
10.2. TCP-like Congestion Control . . . . . . . . . . . . . . 75 |
9.3. Data Checksum Option . . . . . . . . . . . . . . . . . . 77 |
10.3. TFRC Congestion Control . . . . . . . . . . . . . . . . 76 |
9.3.1. Check Data Checksum Feature . . . . . . . . . . . . 78 |
10.4. CCID-Specific Options, Features, and Reset |
9.3.2. Usage Notes . . . . . . . . . . . . . . . . . . . . 78 |
Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 |
10. Congestion Control . . . . . . . . . . . . . . . . . . . . . 79 |
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 |
10.1. TCP-like Congestion Control . . . . . . . . . . . . . . 80 |
11.1. Acks of Acks and Unidirectional Connections . . . . . . 78 |
10.2. TFRC Congestion Control . . . . . . . . . . . . . . . . 80 |
11.2. Ack Piggybacking. . . . . . . . . . . . . . . . . . . . 80 |
10.3. CCID-Specific Options, Features, and Reset |
11.3. Ack Ratio Feature . . . . . . . . . . . . . . . . . . . 80 |
Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 |
11.4. Ack Vector Options. . . . . . . . . . . . . . . . . . . 82 |
10.4. CCID Profile Requirements . . . . . . . . . . . . . . . 83 |
11.4.1. Ack Vector Consistency . . . . . . . . . . . . . . 84 |
10.5. Congestion State. . . . . . . . . . . . . . . . . . . . 83 |
11.4.2. Ack Vector Coverage. . . . . . . . . . . . . . . . 85 |
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 84 |
11.5. Send Ack Vector Feature . . . . . . . . . . . . . . . . 86 |
11.1. Acks of Acks and Unidirectional Connections . . . . . . 84 |
11.6. Slow Receiver Option. . . . . . . . . . . . . . . . . . 86 |
11.2. Ack Piggybacking. . . . . . . . . . . . . . . . . . . . 86 |
11.7. Reset Congestion State Option . . . . . . . . . . . . . 87 |
|
11.8. Data Dropped Option . . . . . . . . . . . . . . . . . . 87 |
|
11.8.1. Data Dropped and Normal Congestion |
|
Response . . . . . . . . . . . . . . . . . . . . . . . . . 90 |
Kohler/Handley/Floyd [Page 6] |
11.8.2. Particular Drop Codes. . . . . . . . . . . . . . . 90 |
|
|
INTERNET-DRAFT Expires: 25 April 2005 October 2004 |
12. Explicit Congestion Notification . . . . . . . . . . . . . . 91 |
|
12.1. ECN Capable Feature . . . . . . . . . . . . . . . . . . 92 |
|
12.2. ECN Nonces. . . . . . . . . . . . . . . . . . . . . . . 92 |
11.3. Ack Ratio Feature . . . . . . . . . . . . . . . . . . . 86 |
12.3. Other Aggression Penalties. . . . . . . . . . . . . . . 93 |
11.4. Ack Vector Options. . . . . . . . . . . . . . . . . . . 88 |
13. Timing Options . . . . . . . . . . . . . . . . . . . . . . . 94 |
11.4.1. Ack Vector Consistency . . . . . . . . . . . . . . 90 |
13.1. Timestamp Option. . . . . . . . . . . . . . . . . . . . 94 |
11.4.2. Ack Vector Coverage. . . . . . . . . . . . . . . . 92 |
13.2. Elapsed Time Option . . . . . . . . . . . . . . . . . . 94 |
11.5. Send Ack Vector Feature . . . . . . . . . . . . . . . . 92 |
13.3. Timestamp Echo Option . . . . . . . . . . . . . . . . . 95 |
11.6. Slow Receiver Option. . . . . . . . . . . . . . . . . . 93 |
14. Maximum Packet Size. . . . . . . . . . . . . . . . . . . . . 96 |
11.7. Data Dropped Option . . . . . . . . . . . . . . . . . . 93 |
15. Forward Compatibility. . . . . . . . . . . . . . . . . . . . 99 |
11.7.1. Data Dropped and Normal Congestion |
16. Middlebox Considerations . . . . . . . . . . . . . . . . . . 99 |
Response . . . . . . . . . . . . . . . . . . . . . . . . . 96 |
17. Relations to Other Specifications. . . . . . . . . . . . . . 101 |
11.7.2. Particular Drop Codes. . . . . . . . . . . . . . . 97 |
17.1. DCCP and RTP. . . . . . . . . . . . . . . . . . . . . . 101 |
12. Explicit Congestion Notification . . . . . . . . . . . . . . 98 |
17.2. Multiplexing Issues . . . . . . . . . . . . . . . . . . 102 |
12.1. ECN Incapable Feature . . . . . . . . . . . . . . . . . 98 |
18. Security Considerations. . . . . . . . . . . . . . . . . . . 102 |
12.2. ECN Nonces. . . . . . . . . . . . . . . . . . . . . . . 99 |
|
12.3. Other Aggression Penalties. . . . . . . . . . . . . . . 100 |
|
13. Timing Options . . . . . . . . . . . . . . . . . . . . . . . 100 |
|
13.1. Timestamp Option. . . . . . . . . . . . . . . . . . . . 101 |
|
13.2. Elapsed Time Option . . . . . . . . . . . . . . . . . . 101 |
|
13.3. Timestamp Echo Option . . . . . . . . . . . . . . . . . 102 |
|
14. Maximum Packet Size. . . . . . . . . . . . . . . . . . . . . 103 |
|
14.1. Measuring PMTU. . . . . . . . . . . . . . . . . . . . . 104 |
|
14.2. Sender Behavior . . . . . . . . . . . . . . . . . . . . 105 |
|
15. Forward Compatibility. . . . . . . . . . . . . . . . . . . . 106 |
|
16. Middlebox Considerations . . . . . . . . . . . . . . . . . . 107 |
|
17. Relations to Other Specifications. . . . . . . . . . . . . . 108 |
|
17.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 108 |
|
17.2. Congestion Manager and Multiplexing . . . . . . . . . . 109 |
|
18. Security Considerations. . . . . . . . . . . . . . . . . . . 110 |
|
18.1. Security Considerations for Partial |
|
Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . 110 |
Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . 103 |
19. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 111 |
19. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 104 |
19.1. Packet Types. . . . . . . . . . . . . . . . . . . . . . 111 |
20. Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 |
19.2. Reset Codes . . . . . . . . . . . . . . . . . . . . . . 111 |
A. Appendix: Ack Vector Implementation Notes . . . . . . . . . . 105 |
19.3. Option Types. . . . . . . . . . . . . . . . . . . . . . 112 |
A.1. Packet Arrival . . . . . . . . . . . . . . . . . . . . . 107 |
19.4. Feature Numbers . . . . . . . . . . . . . . . . . . . . 112 |
A.1.1. New Packets . . . . . . . . . . . . . . . . . . . . 107 |
19.5. Congestion Control Identifiers. . . . . . . . . . . . . 112 |
A.1.2. Old Packets . . . . . . . . . . . . . . . . . . . . 108 |
19.6. Ack Vector States . . . . . . . . . . . . . . . . . . . 113 |
A.2. Sending Acknowledgements . . . . . . . . . . . . . . . . 109 |
19.7. Drop Codes. . . . . . . . . . . . . . . . . . . . . . . 113 |
A.3. Clearing State . . . . . . . . . . . . . . . . . . . . . 110 |
19.8. Service Codes . . . . . . . . . . . . . . . . . . . . . 113 |
A.4. Processing Acknowledgements. . . . . . . . . . . . . . . 111 |
20. Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 |
B. Appendix: Design Motivation . . . . . . . . . . . . . . . . . 112 |
A. Appendix: Ack Vector Implementation Notes . . . . . . . . . . 114 |
B.1. CsCov and Partial Checksumming . . . . . . . . . . . . . 112 |
A.1. Packet Arrival . . . . . . . . . . . . . . . . . . . . . 116 |
Normative References . . . . . . . . . . . . . . . . . . . . . . 113 |
A.1.1. New Packets . . . . . . . . . . . . . . . . . . . . 116 |
Informative References . . . . . . . . . . . . . . . . . . . . . 114 |
A.1.2. Old Packets . . . . . . . . . . . . . . . . . . . . 117 |
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 116 |
A.2. Sending Acknowledgements . . . . . . . . . . . . . . . . 118 |
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 116 |
A.3. Clearing State . . . . . . . . . . . . . . . . . . . . . 119 |
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 116 |
A.4. Processing Acknowledgements. . . . . . . . . . . . . . . 120 |
|
B. Appendix: Design Motivation . . . . . . . . . . . . . . . . . 121 |
|
B.1. CsCov and Partial Checksumming . . . . . . . . . . . . . 121 |
|
|
|
|
|
|
|
Kohler/Handley/Floyd [Page 7] |
|
|
|
INTERNET-DRAFT Expires: 25 April 2005 October 2004 |
|
|
|
|
|
1. Introduction |
|
|
|
The Datagram Congestion Control Protocol (DCCP) is a transport |
|
protocol that implements bidirectional, unicast connections of |
|
congestion-controlled, unreliable datagrams. Specifically, DCCP |
|
provides: |
|
|
|
o Unreliable flows of datagrams, with acknowledgements. |
|
|
|
o Reliable handshakes for connection setup and teardown. |
|
|
|
o Reliable negotiation of options, including negotiation of a |
|
suitable congestion control mechanism. |
|
|
|
o Mechanisms allowing servers to avoid holding state for |
|
unacknowledged connection attempts and already-finished |
|
connections. |
|
|
|
o Congestion control incorporating Explicit Congestion Notification |
|
(ECN) and the ECN Nonce, as per [RFC 3168] and [RFC 3540]. |
|
|
|
o Acknowledgement mechanisms communicating packet loss and ECN |
|
information. Acks are transmitted as reliably as the relevant |
|
congestion control mechanism requires, possibly completely |
|
reliably. |
|
|
|
o Optional mechanisms that tell the sending application, with high |
|
reliability, which data packets reached the receiver, and whether |
|
those packets were ECN marked, corrupted, or dropped in the |
|
receive buffer. |
|
|
|
o Path Maximum Transmission Unit (PMTU) discovery, as per [RFC |
o Path Maximum Transfer Unit (PMTU) discovery, as per [RFC 1191]. |
1191]. |
DCCP is intended for applications, such as streaming media and |
|
Internet telephony, where the costs of long delays can exceed the |
o A choice of modular congestion control mechanisms. Two |
costs of loss and out-of-order delivery. TCP is not well-suited for |
mechanisms are currently specified, TCP-like Congestion Control |
these applications, since its reliable in-order delivery, combined |
[CCID 2 PROFILE] and TFRC (TCP-Friendly Rate Control) Congestion |
with congestion control, can cause arbitrarily long delays. UDP |
Control [CCID 3 PROFILE], but DCCP is easily extensible to |
avoids long delays, but UDP applications must implement congestion |
further forms of unicast congestion control. |
control on their own. DCCP provides built-in congestion control, |
|
including ECN support, for unreliable datagram flows. DCCP avoids |
DCCP is intended for applications that can benefit from control over |
the arbitrary delays associated with TCP. It also implements |
the tradeoffs between delay and reliable in-order delivery. Such |
reliable connection setup, teardown, and feature negotiation, and |
applications include streaming media and Internet telephony. TCP is |
provides a choice of congestion control mechanisms. |
not well-suited for these applications, since reliable in-order |
|
delivery and congestion control can cause arbitrarily long delays. |
|
UDP avoids long delays, but UDP applications that implement |
|
congestion control must do so on their own. DCCP provides built-in |
|
congestion control, including ECN support, for unreliable datagram |
|
|
|
|
|
|
|
Kohler/Handley/Floyd Section 1. [Page 10] |
|
|
|
INTERNET-DRAFT Expires: 25 April 2005 October 2004 |
|
|
|
|
|
flows, avoiding the arbitrary delays associated with TCP. It also |
|
implements reliable connection setup, teardown, and feature |
|
negotiation. |
|
|
|
2. Design Rationale |
|
|
|
One DCCP design goal was to give most streaming UDP applications |
Most streaming UDP applications should have little reason not to |
little reason not to switch to DCCP, once it is deployed. To |
switch to DCCP, once it is deployed. To facilitate this, DCCP was |
facilitate this, DCCP was designed to have as little overhead as |
designed to have as little overhead as possible, both in terms of |
possible, both in terms of the packet header size and in terms of |
the packet header size and in terms of the state and CPU overhead |
the state and CPU overhead required at end hosts. Only the minimal |
required at end hosts. Only the minimal necessary functionality was |
necessary functionality was included in DCCP, leaving other |
included in DCCP, leaving other functionality, such as forward error |
functionality, such as forward error correction (FEC), semi- |
correction (FEC), semi-reliability, and multiple streams, to be |
reliability, and multiple streams, to be layered on top of DCCP as |
layered on top of DCCP as desired. This desire for minimal overhead |
desired. |
is also one of the reasons to avoid proposing an unreliable variant |
|
of the Stream Control Transmission Protocol (SCTP, [RFC 2960]). |
Different forms of conformant congestion control are appropriate for |
|
different applications. For example, on-line games might want to |
|
make quick use of any available bandwidth, while streaming media |
|
might trade off this responsiveness for a steadier, less bursty |
|
rate. (Sudden rate changes can cause unacceptable UI glitches, such |
|
as audible pauses or clicks in the playout stream.) DCCP thus |
|
allows applications to choose from a set of congestion control |
allows applications to choose between several forms of congestion |
mechanisms. One alternative, TCP-like Congestion Control, halves |
control. One choice, TCP-like Congestion Control, halves the |
the congestion window in response to a packet drop or mark, as in |
congestion window in response to a packet drop or mark, as in TCP. |
TCP. Applications using this congestion control mechanism will |
Applications using this congestion control mechanism will respond |
respond quickly to changes in available bandwidth, but must tolerate |
quickly to changes in available bandwidth, but must tolerate the |
the abrupt changes in congestion window typical of TCP. A second |
abrupt changes in congestion window typical of TCP. A second |
alternative, TCP-Friendly Rate Control (TFRC, [RFC 3448]), a form of |
|
equation-based congestion control, minimizes abrupt changes in the |
|
sending rate while maintaining longer-term fairness with TCP. Other |
sending rate while maintaining longer-term fairness with TCP. |
alternatives can be added as future congestion control mechanisms |
|
are standardized. |
|
|
|
DCCP also lets unreliable traffic safely use ECN. A UDP kernel API |
|
might not allow applications to set UDP packets as ECN-capable, |
|
since the API could not guarantee the application would properly |
|
detect or respond to congestion. DCCP kernel APIs will have no such |
|
issues, since DCCP implements congestion control itself. |
|
|
|
We chose not to require the use of the Congestion Manager [RFC |
|
3124], which allows multiple concurrent streams between the same |
|
sender and receiver to share congestion control. The current |
|
Congestion Manager can only be used by applications that have their |
|
own end-to-end feedback about packet losses, but this is not the |
|
case for many of the applications currently using UDP. In addition, |
|
the current Congestion Manager does not easily support multiple |
|
congestion control mechanisms, or lend itself to the use of forms of |
|
|
|
|
|
|
|
Kohler/Handley/Floyd Section 2. [Page 11] |
|
|
|
INTERNET-DRAFT Expires: 25 April 2005 October 2004 |
|
|
|
|
|
TFRC where the state about past packet drops or marks is maintained |
|
at the receiver rather than at the sender. DCCP should be able to |
|
make use of CM where desired by the application, but we do not see |
|
any benefit in making the deployment of DCCP contingent on the |
|
deployment of CM itself. |
|
|
|
We intend for DCCP's protocol mechanisms, which are described in |
|
this document, to suit any application desiring unicast congestion- |
|
controlled streams of unreliable datagrams. The congestion control |
|
mechanisms currently approved for use with DCCP, which are described |
|
in separate Congestion Control ID Profiles [CCID 2 PROFILE] [CCID 3 |
|
PROFILE], may, however, cause problems for some applications, |
|
including high-bandwidth interactive video. These applications |
|
should be able to use DCCP once suitable Congestion Control ID |
|
Profiles are standardized. |
|
|
|
3. Conventions and Terminology |
|
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in |
|
this document are to be interpreted as described in [RFC 2119]. |
|
|
|
3.1. Numbers and Fields |
|
|
|
All multi-byte numerical quantities in DCCP, such as port numbers, |
|
Sequence Numbers, and arguments to options, are transmitted in |
|
network byte order (most significant byte first). |
|
|
|
We occasionally refer to the "left" and "right" sides of a bit |
|
field. "Left" means towards the most significant bit, and "right" |
|
means towards the least significant bit. |
|
|
|
Random numbers in DCCP are used for their security properties, and |
|
SHOULD be chosen according to the guidelines in [RFC 1750]. |
MUST be chosen according to the guidelines in [RFC 1750]. |
|
|
All operations on DCCP sequence numbers, and comparisons such as |
|
"greater" and "greatest", use circular arithmetic modulo 2**48. |
|
This form of arithmetic preserves the relationships between sequence |
|
numbers as they roll over from 2**48 - 1 to 0. We note that the |
numbers as they roll over from 2**48 - 1 to 0. |
two's-complement trick for implementing circular comparison -- |
|
namely, A < B in the circular comparison sense if and only if |
|
(A - B) < 0 in the conventional arithmetic sense -- applies directly |
|
to DCCP sequence numbers, as long as they are stored in the most |
|
significant 48 bits of 64-bit integers. |
|
|
|
Reserved bitfields in DCCP packet headers MUST be set to zero by |
|
senders, and MUST be ignored by receivers, unless otherwise |
|
specified. This is to allow for future protocol extensions. In |
|
|
|
|
|
|
|
Kohler/Handley/Floyd Section 3.1. [Page 12] |
|
|
|
INTERNET-DRAFT Expires: 25 April 2005 October 2004 |
|
|
|
|
|
particular, DCCP processors MUST NOT reset a DCCP connection simply |
|
because a Reserved field has non-zero value [RFC 3360]. |
|
|
|
3.2. Parts of a Connection |
|
|
|
Each DCCP connection runs between two hosts, which we often name |
Each DCCP connection runs between two endpoints, which we often name |
DCCP A and DCCP B. Each connection is actively initiated by one of |
DCCP A and DCCP B. |
the hosts, which we call the client; the other, initially passive |
DCCP connections are actively initiated by one endpoint. The active |
host is called the server. The term "DCCP endpoint" is used to |
endpoint is called the client, and the passive endpoint is called |
refer to either of the two hosts explicitly named by the connection |
the server. |
(the client and the server). The term "DCCP processor" refers more |
DCCP connections are bidirectional; data may pass from either |
generally to any host that might need to process a DCCP header; this |
|
includes the endpoints and any middleboxes on the path, such as |
|
firewalls and network address translators. |
|
|
|
DCCP connections are bidirectional: data may pass from either |
|
endpoint to the other. This means that data and acknowledgements |
|
may be flowing in both directions simultaneously. Logically, |
|
however, a DCCP connection consists of two separate unidirectional |
|
connections, called half-connections. Each half-connection consists |
|
of the application data sent by one endpoint and the corresponding |
|
acknowledgements sent by the other endpoint. We can illustrate this |
|
as follows: |
|
|
|
+--------+ A-to-B half-connection: +--------+ |
|
| | --> application data --> | | |
|
| | <-- acknowledgements <-- | | |
|
| DCCP A | | DCCP B | |
|
| | B-to-A half-connection: | | |
|
| | <-- application data <-- | | |
|
+--------+ --> acknowledgements --> +--------+ |
|
|
|
Although they are logically distinct, in practice the half- |
|
connections overlap; a DCCP-DataAck packet, for example, contains |
|
application data relevant to one half-connection and acknowledgement |
|
information relevant to the other. |
|
|
|
In the context of a single half-connection, the terms "HC-Sender" |
|
and "HC-Receiver" denote the endpoints sending application data and |
|
acknowledgements, respectively. For example, DCCP A is the HC- |
|
Sender and DCCP B is the HC-Receiver in the A-to-B half-connection. |
|
|
|
3.3. Features |
|
|
|
A DCCP feature is a connection attribute on whose value the two |
|
endpoints agree. Many properties of a DCCP connection are |
|
controlled by features, including the congestion control mechanisms |
|
in use on the two half-connections. The endpoints achieve agreement |
in use on the two half-connections. The endpoints can achieve |
|
agreement through the exchange of feature negotiation options in |
|
DCCP headers, or through out-of-band communication. |
|
|
Kohler/Handley/Floyd Section 3.3. [Page 13] |
|
|
|
INTERNET-DRAFT Expires: 25 April 2005 October 2004 |
|
|
|
|
|
through the exchange of feature negotiation options in DCCP headers. |
|
|
|
DCCP features are identified by a feature number and an endpoint. |
|
The notation "F/X" represents the feature with feature number F |
|
located at DCCP endpoint X. Each valid feature number thus |
|
corresponds to two features, which are negotiated separately and |
|
need not have the same value. The two endpoints know, and agree on, |
|
the value of every valid feature. DCCP A is the "feature location" |
|
for all features F/A, and the "feature remote" for all features F/B. |
|
|
|
3.4. Round-Trip Times |
|
|
|
DCCP round-trip time measurements are performed by congestion |
We sometimes refer to round-trip times -- for setting timers, for |
control mechanisms; different mechanisms may measure round-trip time |
example. If no useful round-trip time estimate is available, a DCCP |
in different ways, or not measure it at all. However, the main DCCP |
implementation SHOULD use 0.1 seconds instead. |
protocol does use round-trip times occasionally, such as in the |
|
initial values for certain timers. Each DCCP implementation thus |
|
defines a default round-trip time for use when no estimate is |
|
available; this parameter should default to not less than |
|
0.2 seconds, a reasonable median round-trip time for Internet TCP |
|
connections. Protocol behavior specified in terms of "round-trip |
|
time" values actually refers to "a current round-trip time estimate |
|
taken by some CCID, or, if no estimate is available, the default |
|
round-trip time parameter". |
|
|
|
The maximum segment lifetime, or MSL, is the maximum length of time |
|
a packet can survive in the network. The DCCP MSL should equal that |
a packet can survive in the network. The default MSL is two minutes |
of TCP, which is normally two minutes. |
for this specification. |
|
|
3.5. Security Limitation |
|
|
|
DCCP provides no protection against attackers who can snoop on a |
DCCP is not robust against attackers who can snoop on a connection |
connection in progress, or who can guess valid sequence numbers in |
in progress, or who can guess valid sequence numbers in other ways. |
other ways. Applications desiring stronger security should use |
Applications desiring stronger security should use IPsec or |
IPsec [RFC 2401]; depending on the level of security required, |
application-level cryptography. |
application-level cryptography may also suffice. These issues are |
|
discussed further in Sections 18 and 7.5.5. |
|
|
|
3.6. Robustness Principle |
|
|
|
DCCP impleme |