Internet Engineering Task Force Eddie Kohler |
|
INTERNET-DRAFT UCLA |
|
draft-ietf-dccp-spec-09.txt Mark Handley |
draft-ietf-dccp-spec-08.txt Mark Handley |
Expires: 14 May 2005 UCL |
Expires: 25 April 2005 UCL |
Sally Floyd |
|
ICIR |
|
14 November 2004 |
25 October 2004 |
|
|
|
|
Datagram Congestion Control Protocol (DCCP) |
|
|
|
|
|
Status of this Memo |
|
|
|
This document is an Internet-Draft and is subject to all provisions |
|
of section 3 of RFC 3667. By submitting this Internet-Draft, each |
|
author represents that any applicable patent or other IPR claims of |
|
which he or she is aware have been or will be disclosed, and any of |
|
which he or she become aware will be disclosed, in accordance with |
|
RFC 3668. |
|
|
|
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. |
|
|
|
This Internet-Draft will expire on 14 May 2005. |
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: 14 May 2005 November 2004 |
|
|
|
|
|
TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: |
|
|
|
Changes since draft-ietf-dccp-spec-08.txt: |
|
|
|
* Added minimum Sequence Window. |
|
|
|
* Init Cookie implementation sketch. |
|
|
|
* Include reasoning for ignoring options on DCCP-Data. |
|
|
|
* More Aggression Penalty explanation. |
|
|
|
* More explanation on Ack Vectors that report information on packets |
|
that haven't been sent. |
|
|
|
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. |
|
|
|
|
|
|
|
|
|
Kohler/Handley/Floyd [Page 3] |
|
|
|
INTERNET-DRAFT Expires: 14 May 2005 November 2004 |
|
|
|
|
|
Table of Contents |
|
|
|
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 10 |
|
2. Design Rationale. . . . . . . . . . . . . . . . . . . . . . . 11 |
|
3. Conventions and Terminology . . . . . . . . . . . . . . . . . 12 |
|
3.1. Numbers and Fields . . . . . . . . . . . . . . . . . . . 12 |
|
3.2. Parts of a Connection. . . . . . . . . . . . . . . . . . 13 |
|
3.3. Features . . . . . . . . . . . . . . . . . . . . . . . . 13 |
|
3.4. Round-Trip Times . . . . . . . . . . . . . . . . . . . . 14 |
|
3.5. Security Limitation. . . . . . . . . . . . . . . . . . . 14 |
|
3.6. Robustness Principle . . . . . . . . . . . . . . . . . . 14 |
|
4. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
|
4.1. Packet Types . . . . . . . . . . . . . . . . . . . . . . 15 |
|
4.2. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 16 |
|
4.3. States . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
|
4.4. Congestion Control . . . . . . . . . . . . . . . . . . . 18 |
4.4. Congestion Control . . . . . . . . . . . . . . . . . . . 19 |
4.5. Features . . . . . . . . . . . . . . . . . . . . . . . . 19 |
|
4.6. Differences From TCP . . . . . . . . . . . . . . . . . . 20 |
|
4.7. Example Connection . . . . . . . . . . . . . . . . . . . 21 |
|
5. Packet Formats. . . . . . . . . . . . . . . . . . . . . . . . 23 |
|
5.1. Generic Header . . . . . . . . . . . . . . . . . . . . . 23 |
|
5.2. DCCP-Request Packets . . . . . . . . . . . . . . . . . . 27 |
|
5.3. DCCP-Response Packets. . . . . . . . . . . . . . . . . . 28 |
|
5.4. DCCP-Data, DCCP-Ack, and DCCP-DataAck Packets. . . . . . 28 |
|
5.5. DCCP-CloseReq and DCCP-Close Packets . . . . . . . . . . 30 |
|
5.6. DCCP-Reset Packets . . . . . . . . . . . . . . . . . . . 30 |
|
5.7. DCCP-Sync and DCCP-SyncAck Packets . . . . . . . . . . . 33 |
|
5.8. Options. . . . . . . . . . . . . . . . . . . . . . . . . 34 |
|
5.8.1. Padding Option. . . . . . . . . . . . . . . . . . . 36 |
|
5.8.2. Mandatory Option. . . . . . . . . . . . . . . . . . 36 |
|
6. Feature Negotiation . . . . . . . . . . . . . . . . . . . . . 37 |
|
6.1. Change Options . . . . . . . . . . . . . . . . . . . . . 37 |
|
6.2. Confirm Options. . . . . . . . . . . . . . . . . . . . . 38 |
|
6.3. Reconciliation Rules . . . . . . . . . . . . . . . . . . 38 |
|
6.3.1. Server-Priority . . . . . . . . . . . . . . . . . . 38 |
|
6.3.2. Non-Negotiable. . . . . . . . . . . . . . . . . . . 39 |
|
6.4. Feature Numbers. . . . . . . . . . . . . . . . . . . . . 39 |
|
6.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 40 |
|
6.6. Option Exchange. . . . . . . . . . . . . . . . . . . . . 41 |
|
6.6.1. Normal Exchange . . . . . . . . . . . . . . . . . . 42 |
|
6.6.2. Processing Received Options . . . . . . . . . . . . 42 |
|
6.6.3. Loss and Retransmission . . . . . . . . . . . . . . 44 |
|
6.6.4. Reordering. . . . . . . . . . . . . . . . . . . . . 45 |
|
6.6.5. Preference Changes. . . . . . . . . . . . . . . . . 46 |
|
6.6.6. Simultaneous Negotiation. . . . . . . . . . . . . . 46 |
|
6.6.7. Unknown Features. . . . . . . . . . . . . . . . . . 46 |
|
6.6.8. Invalid Options . . . . . . . . . . . . . . . . . . 47 |
|
6.6.9. Mandatory Feature Negotiation . . . . . . . . . . . 48 |
|
|
|
|
|
|
|
Kohler/Handley/Floyd [Page 5] |
|
|
|
INTERNET-DRAFT Expires: 14 May 2005 November 2004 |
|
|
|
|
|
7. Sequence Numbers. . . . . . . . . . . . . . . . . . . . . . . 48 |
|
7.1. Variables. . . . . . . . . . . . . . . . . . . . . . . . 48 |
7.1. Variables. . . . . . . . . . . . . . . . . . . . . . . . 49 |
7.2. Initial Sequence Numbers . . . . . . . . . . . . . . . . 49 |
|
7.3. Quiet Time . . . . . . . . . . . . . . . . . . . . . . . 50 |
|
7.4. Acknowledgement Numbers. . . . . . . . . . . . . . . . . 51 |
|
7.5. Validity and Synchronization . . . . . . . . . . . . . . 51 |
|
7.5.1. Sequence and Acknowledgement Number |
|
Windows. . . . . . . . . . . . . . . . . . . . . . . . . . 52 |
|
7.5.2. Sequence Window Feature . . . . . . . . . . . . . . 53 |
|
7.5.3. Sequence-Validity Rules . . . . . . . . . . . . . . 53 |
|
7.5.4. Handling Sequence-Invalid Packets . . . . . . . . . 55 |
|
7.5.5. Sequence Number Attacks . . . . . . . . . . . . . . 56 |
|
7.5.6. Examples. . . . . . . . . . . . . . . . . . . . . . 57 |
|
7.6. Short Sequence Numbers . . . . . . . . . . . . . . . . . 58 |
|
7.6.1. Allow Short Sequence Numbers Feature. . . . . . . . 59 |
|
7.6.2. When to Avoid Short Sequence Numbers. . . . . . . . 59 |
|
7.7. NDP Count and Detecting Application Loss . . . . . . . . 60 |
|
7.7.1. Usage Notes . . . . . . . . . . . . . . . . . . . . 61 |
|
7.7.2. Send NDP Count Feature. . . . . . . . . . . . . . . 61 |
|
8. Event Processing. . . . . . . . . . . . . . . . . . . . . . . 61 |
|
8.1. Connection Establishment . . . . . . . . . . . . . . . . 62 |
|
8.1.1. Client Request. . . . . . . . . . . . . . . . . . . 62 |
|
8.1.2. Service Codes . . . . . . . . . . . . . . . . . . . 63 |
|
8.1.3. Server Response . . . . . . . . . . . . . . . . . . 64 |
|
8.1.4. Init Cookie Option. . . . . . . . . . . . . . . . . 65 |
|
8.1.5. Handshake Completion. . . . . . . . . . . . . . . . 66 |
|
8.2. Data Transfer. . . . . . . . . . . . . . . . . . . . . . 66 |
|
8.3. Termination. . . . . . . . . . . . . . . . . . . . . . . 67 |
|
8.3.1. Abnormal Termination. . . . . . . . . . . . . . . . 69 |
|
8.4. DCCP State Diagram . . . . . . . . . . . . . . . . . . . 69 |
|
8.5. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 70 |
|
9. Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . 74 |
|
9.1. Header Checksum Field. . . . . . . . . . . . . . . . . . 75 |
|
9.2. Header Checksum Coverage Field . . . . . . . . . . . . . 76 |
|
9.2.1. Minimum Checksum Coverage Feature . . . . . . . . . 77 |
|
9.3. Data Checksum Option . . . . . . . . . . . . . . . . . . 77 |
|
9.3.1. Check Data Checksum Feature . . . . . . . . . . . . 78 |
|
9.3.2. Usage Notes . . . . . . . . . . . . . . . . . . . . 78 |
|
10. Congestion Control . . . . . . . . . . . . . . . . . . . . . 79 |
|
10.1. TCP-like Congestion Control . . . . . . . . . . . . . . 80 |
|
10.2. TFRC Congestion Control . . . . . . . . . . . . . . . . 80 |
|
10.3. CCID-Specific Options, Features, and Reset |
|
Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 |
|
10.4. CCID Profile Requirements . . . . . . . . . . . . . . . 83 |
|
10.5. Congestion State. . . . . . . . . . . . . . . . . . . . 83 |
|
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 84 |
|
11.1. Acks of Acks and Unidirectional Connections . . . . . . 84 |
|
11.2. Ack Piggybacking. . . . . . . . . . . . . . . . . . . . 86 |
|
|
|
|
|
|
|
Kohler/Handley/Floyd [Page 6] |
|
|
|
INTERNET-DRAFT Expires: 14 May 2005 November 2004 |
|
|
|
|
|
11.3. Ack Ratio Feature . . . . . . . . . . . . . . . . . . . 86 |
|
11.4. Ack Vector Options. . . . . . . . . . . . . . . . . . . 88 |
|
11.4.1. Ack Vector Consistency . . . . . . . . . . . . . . 90 |
|
11.4.2. Ack Vector Coverage. . . . . . . . . . . . . . . . 92 |
|
11.5. Send Ack Vector Feature . . . . . . . . . . . . . . . . 92 |
|
11.6. Slow Receiver Option. . . . . . . . . . . . . . . . . . 93 |
|
11.7. Data Dropped Option . . . . . . . . . . . . . . . . . . 94 |
11.7. Data Dropped Option . . . . . . . . . . . . . . . . . . 93 |
11.7.1. Data Dropped and Normal Congestion |
|
Response . . . . . . . . . . . . . . . . . . . . . . . . . 97 |
Response . . . . . . . . . . . . . . . . . . . . . . . . . 96 |
11.7.2. Particular Drop Codes. . . . . . . . . . . . . . . 97 |
|
12. Explicit Congestion Notification . . . . . . . . . . . . . . 98 |
|
12.1. ECN Incapable Feature . . . . . . . . . . . . . . . . . 98 |
|
12.2. ECN Nonces. . . . . . . . . . . . . . . . . . . . . . . 99 |
|
12.3. Aggression Penalties. . . . . . . . . . . . . . . . . . 100 |
12.3. Other Aggression Penalties. . . . . . . . . . . . . . . 100 |
13. Timing Options . . . . . . . . . . . . . . . . . . . . . . . 101 |
13. Timing Options . . . . . . . . . . . . . . . . . . . . . . . 100 |
13.1. Timestamp Option. . . . . . . . . . . . . . . . . . . . 101 |
|
13.2. Elapsed Time Option . . . . . . . . . . . . . . . . . . 102 |
13.2. Elapsed Time Option . . . . . . . . . . . . . . . . . . 101 |
13.3. Timestamp Echo Option . . . . . . . . . . . . . . . . . 103 |
13.3. Timestamp Echo Option . . . . . . . . . . . . . . . . . 102 |
14. Maximum Packet Size. . . . . . . . . . . . . . . . . . . . . 104 |
14. Maximum Packet Size. . . . . . . . . . . . . . . . . . . . . 103 |
14.1. Measuring PMTU. . . . . . . . . . . . . . . . . . . . . 104 |
|
14.2. Sender Behavior . . . . . . . . . . . . . . . . . . . . 106 |
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 . . . . . . . . . . 110 |
17.2. Congestion Manager and Multiplexing . . . . . . . . . . 109 |
18. Security Considerations. . . . . . . . . . . . . . . . . . . 110 |
|
18.1. Security Considerations for Partial |
|
Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . 111 |
Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . 110 |
19. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 112 |
19. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 111 |
19.1. Packet Types. . . . . . . . . . . . . . . . . . . . . . 112 |
19.1. Packet Types. . . . . . . . . . . . . . . . . . . . . . 111 |
19.2. Reset Codes . . . . . . . . . . . . . . . . . . . . . . 112 |
19.2. Reset Codes . . . . . . . . . . . . . . . . . . . . . . 111 |
19.3. Option Types. . . . . . . . . . . . . . . . . . . . . . 112 |
|
19.4. Feature Numbers . . . . . . . . . . . . . . . . . . . . 113 |
19.4. Feature Numbers . . . . . . . . . . . . . . . . . . . . 112 |
19.5. Congestion Control Identifiers. . . . . . . . . . . . . 113 |
19.5. Congestion Control Identifiers. . . . . . . . . . . . . 112 |
19.6. Ack Vector States . . . . . . . . . . . . . . . . . . . 113 |
|
19.7. Drop Codes. . . . . . . . . . . . . . . . . . . . . . . 113 |
|
19.8. Service Codes . . . . . . . . . . . . . . . . . . . . . 114 |
19.8. Service Codes . . . . . . . . . . . . . . . . . . . . . 113 |
20. Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 |
20. Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 |
A. Appendix: Ack Vector Implementation Notes . . . . . . . . . . 115 |
A. Appendix: Ack Vector Implementation Notes . . . . . . . . . . 114 |
A.1. Packet Arrival . . . . . . . . . . . . . . . . . . . . . 117 |
A.1. Packet Arrival . . . . . . . . . . . . . . . . . . . . . 116 |
A.1.1. New Packets . . . . . . . . . . . . . . . . . . . . 117 |
A.1.1. New Packets . . . . . . . . . . . . . . . . . . . . 116 |
A.1.2. Old Packets . . . . . . . . . . . . . . . . . . . . 118 |
A.1.2. Old Packets . . . . . . . . . . . . . . . . . . . . 117 |
A.2. Sending Acknowledgements . . . . . . . . . . . . . . . . 119 |
A.2. Sending Acknowledgements . . . . . . . . . . . . . . . . 118 |
A.3. Clearing State . . . . . . . . . . . . . . . . . . . . . 119 |
|
A.4. Processing Acknowledgements. . . . . . . . . . . . . . . 121 |
A.4. Processing Acknowledgements. . . . . . . . . . . . . . . 120 |
B. Appendix: Partial Checksumming Design Motivation. . . . . . . 121 |
B. Appendix: Design Motivation . . . . . . . . . . . . . . . . . 121 |
Normative References . . . . . . . . . . . . . . . . . . . . . . 123 |
B.1. CsCov and Partial Checksumming . . . . . . . . . . . . . 121 |
|
Normative References . . . . . . . . . . . . . . . . . . . . . . 122 |
|
Informative References . . . . . . . . . . . . . . . . . . . . . 123 |
|
|
Kohler/Handley/Floyd [Page 7] |
|
|
|
INTERNET-DRAFT Expires: 14 May 2005 November 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 |
|
1191]. |
|
|
|
o A choice of modular congestion control mechanisms. Two |
|
mechanisms are currently specified, TCP-like Congestion Control |
|
[CCID 2 PROFILE] and TFRC (TCP-Friendly Rate Control) Congestion |
|
Control [CCID 3 PROFILE], but DCCP is easily extensible to |
|
further forms of unicast congestion control. |
|
|
|
DCCP is intended for applications such as streaming media that can |
DCCP is intended for applications that can benefit from control over |
benefit from control over the tradeoffs between delay and reliable |
the tradeoffs between delay and reliable in-order delivery. Such |
in-order delivery. TCP is not well-suited for these applications, |
applications include streaming media and Internet telephony. TCP is |
since reliable in-order delivery and congestion control can cause |
not well-suited for these applications, since reliable in-order |
arbitrarily long delays. UDP avoids long delays, but UDP |
delivery and congestion control can cause arbitrarily long delays. |
applications that implement congestion control must do so on their |
UDP avoids long delays, but UDP applications that implement |
own. DCCP provides built-in congestion control, including ECN |
congestion control must do so on their own. DCCP provides built-in |
support, for unreliable datagram flows, avoiding the arbitrary |
congestion control, including ECN support, for unreliable datagram |
|
flows, avoiding the arbitrary delays associated with TCP. It also |
|
implements reliable connection setup, teardown, and feature |
|
negotiation. |
Kohler/Handley/Floyd Section 1. [Page 10] |
|
|
|
INTERNET-DRAFT Expires: 14 May 2005 November 2004 |
|
|
|
|
|
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 |
|
little reason not to switch to DCCP, once it is deployed. To |
|
facilitate this, DCCP was designed to have as little overhead as |
|
possible, both in terms of the packet header size and in terms of |
|
the state and CPU overhead required at end hosts. Only the minimal |
|
necessary functionality was included in DCCP, leaving other |
|
functionality, such as forward error correction (FEC), semi- |
|
reliability, and multiple streams, to be layered on top of DCCP as |
|
desired. |
|
|
|
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 |
|
mechanisms. One alternative, TCP-like Congestion Control, halves |
|
the congestion window in response to a packet drop or mark, as in |
|
TCP. Applications using this congestion control mechanism will |
|
respond quickly to changes in available bandwidth, but must tolerate |
|
the 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 |
|
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 |
|
TFRC where the state about past packet drops or marks is maintained |
|
|
|
|
|
|
|
Kohler/Handley/Floyd Section 2. [Page 11] |
|
|
|
INTERNET-DRAFT Expires: 14 May 2005 November 2004 |
|
|
|
|
|
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]. |
|
|
|
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. Note that the common |
numbers as they roll over from 2**48 - 1 to 0. We note that the |
technique for implementing circular comparison using two's- |
two's-complement trick for implementing circular comparison -- |
complement arithmetic, whereby A < B using circular arithmetic if |
namely, A < B in the circular comparison sense if and only if |
and only if (A - B) < 0 using conventional two's-complement |
(A - B) < 0 in the conventional arithmetic sense -- applies directly |
arithmetic, may be used for DCCP sequence numbers, providing they |
to DCCP sequence numbers, as long as they are stored in the most |
are stored in the most significant 48 bits of 64-bit integers. |
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 |
|
particular, DCCP processors MUST NOT reset a DCCP connection simply |
|
|
|
|
|
|
|
Kohler/Handley/Floyd Section 3.1. [Page 12] |
|
|
|
INTERNET-DRAFT Expires: 14 May 2005 November 2004 |
|
|
|
|
|
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 |
|
DCCP A and DCCP B. Each connection is actively initiated by one of |
|
the hosts, which we call the client; the other, initially passive |
|
host is called the server. The term "DCCP endpoint" is used to |
|
refer to either of the two hosts explicitly named by the connection |
|
(the client and the server). The term "DCCP processor" refers more |
|
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 |
|
through the exchange of feature negotiation options in DCCP headers. |
|
|
|
|
|
|
|
Kohler/Handley/Floyd Section 3.3. [Page 13] |
|
|
|
INTERNET-DRAFT Expires: 14 May 2005 November 2004 |
|
|
|
|
|
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 |
|
control mechanisms; different mechanisms may measure round-trip time |
|
in different ways, or not measure it at all. However, the main DCCP |
|
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 reasonably conservative round-trip time for Internet |
0.2 seconds, a reasonable median round-trip time for Internet TCP |
TCP connections. Protocol behavior specified in terms of "round- |
connections. Protocol behavior specified in terms of "round-trip |
trip time" values actually refers to "a current round-trip time |
time" values actually refers to "a current round-trip time estimate |
estimate taken by some CCID, or, if no estimate is available, the |
taken by some CCID, or, if no estimate is available, the default |
default round-trip time parameter". |
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 |
|
of TCP, which is normally two minutes. |
|
|
|
3.5. Security Limitation |
|
|
|
DCCP provides no protection against attackers who can snoop on a |
|
connection in progress, or who can guess valid sequence numbers in |
|
other ways. Applications desiring stronger security should use |
|
IPsec [RFC 2401]; depending on the level of security required, |
|
application-level cryptography may also suffice. These issues are |
|
discussed further in Sections 18 and 7.5.5. |
|
|
|
3.6. Robustness Principle |
|
|
|
DCCP implementations will follow TCP's "general principle of |
|
robustness": "be conservative in what you do, be liberal in what you |
|
accept from others" [RFC 793]. |
|
|
|
4. Overview |
|
|
|
DCCP's high-level connection dynamics echo those of TCP. |
|
Connections progress through three phases: initiation, including a |
|
three-way handshake; data transfer; and termination. Data can flow |
|
both ways over the connection. An acknowledgement framework lets |
|
|
|
|
|
|
|
Kohler/Handley/Floyd Section 4. [Page 14] |
|
|
|
INTERNET-DRAFT Expires: 14 May 2005 November 2004 |
|
|
|
|
|
senders discover how much data has been lost, and thus avoid |
|
unfairly congesting the network. Of course, DCCP provides |
|
unreliable datagram semantics, not TCP's reliable bytestream |
|
semantics. The application must package its data into explicit |
|
frames, and must retransmit its own data as necessary. It may be |
|
useful to think of DCCP as TCP minus bytestream semantics and |
|
reliability, or as UDP plus congestion control, handshakes, and |
|
acknowledgements. |
|
|
|
4.1. Packet Types |
|
|
|
Ten packet types implement DCCP's protocol functions. For example, |
|
every new connection attempt begins with a DCCP-Request packet sent |
|
by the client. A DCCP-Request packet thus resembles a TCP SYN; but |
|
DCCP-Request is a packet type, not a flag, so there's no way to send |
|
an unexpected combination such as TCP's SYN+FIN+ACK+RST. |
|
|
|
Eight packet types occur during the progress of a typical |
|
connection, shown here. Note the three-way handshakes during |
|
initiation and termination. |
|
|
|
Client Server |
|
------ ------ |
|
(1) Initiation |
|
DCCP-Request --> |
|
<-- DCCP-Response |
|
DCCP-Ack --> |
|
(2) Data transfer |
|
DCCP-Data, DCCP-Ack, DCCP-DataAck --> |
|
<-- DCCP-Data, DCCP-Ack, DCCP-DataAck |
|
(3) Termination |
|
<-- DCCP-CloseReq |
|
DCCP-Close --> |
|
<-- DCCP-Reset |
|
|
|
The two remaining packet types are used to resynchronize after |
|
bursts of loss. |
|
|
|
Every DCCP packet starts with a 12-byte generic header. Particular |
|
packet types include additional fixed-size header data; for example, |
|
DCCP-Acks include an Acknowledgement Number. DCCP options and any |
|
application data follow the fixed-size header. |
|
|
|
The packet types are as follows: |
|
|
|
DCCP-Request |
|
Sent by the client to initiate a connection (the first part of |
|
the three-way initiation handshake). |
|
|
|
|
|
|