Internet Engineering Task Force Eddie Kohler
INTERNET-DRAFT UCLA
draft-ietf-dccp-spec-13.txt Mark Handley	draft-ietf-dccp-spec-12.txt Mark Handley
Expires: 1 June 2006 UCL	Expires: 28 May 2006 UCL
Sally Floyd
ICIR
1 December 2005	28 November 2005


Datagram Congestion Control Protocol (DCCP)


Status of this Memo

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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

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 1 June 2006.	This Internet-Draft will expire on 28 May 2006.

Abstract

The Datagram Congestion Control Protocol (DCCP) is a transport
protocol that provides bidirectional unicast connections of
congestion-controlled unreliable datagrams. DCCP is suitable for
applications that transfer fairly large amounts of data, but can
benefit from control over the tradeoff between timeliness and
reliability.



Kohler/Handley/Floyd [Page 1]

INTERNET-DRAFT Expires: 1 June 2006 December 2005


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 2]

INTERNET-DRAFT Expires: 1 June 2006 December 2005


* 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".

* Rename "Reset Reason" to "Reset Code".

* Mobility ID becomes 128 bits long.

* Add probabilities to Mobility ID discussion.

* Add SyncAck.































Kohler/Handley/Floyd [Page 3]

INTERNET-DRAFT Expires: 1 June 2006 December 2005


Table of Contents

1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Design Rationale. . . . . . . . . . . . . . . . . . . . . . . 10
3. Conventions and Terminology . . . . . . . . . . . . . . . . . 11
3.1. Numbers and Fields . . . . . . . . . . . . . . . . . . . 11
3.2. Parts of a Connection. . . . . . . . . . . . . . . . . . 12
3.3. Features . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Round-Trip Times . . . . . . . . . . . . . . . . . . . . 13
3.5. Security Limitation. . . . . . . . . . . . . . . . . . . 13
3.6. Robustness Principle . . . . . . . . . . . . . . . . . . 13
4. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Packet Types . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Packet Sequencing. . . . . . . . . . . . . . . . . . . . 15
4.3. States . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Congestion Control Mechanisms. . . . . . . . . . . . . . 18
4.5. Connection Features. . . . . . . . . . . . . . . . . . . 19
4.6. Differences From TCP . . . . . . . . . . . . . . . . . . 20
4.7. Example Connection . . . . . . . . . . . . . . . . . . . 21
5. Packet Formats. . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Generic Header . . . . . . . . . . . . . . . . . . . . . 23
5.2. DCCP-Request Packets . . . . . . . . . . . . . . . . . . 26
5.3. DCCP-Response Packets. . . . . . . . . . . . . . . . . . 27
5.4. DCCP-Data, DCCP-Ack, and DCCP-DataAck Packets. . . . . . 28
5.5. DCCP-CloseReq and DCCP-Close Packets . . . . . . . . . . 29
5.6. DCCP-Reset Packets . . . . . . . . . . . . . . . . . . . 30
5.7. DCCP-Sync and DCCP-SyncAck Packets . . . . . . . . . . . 33
5.8. Options. . . . . . . . . . . . . . . . . . . . . . . . . 34
5.8.1. Padding Option. . . . . . . . . . . . . . . . . . . 35
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. Feature Negotiation 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 4]

INTERNET-DRAFT Expires: 1 June 2006 December 2005


7. Sequence Numbers. . . . . . . . . . . . . . . . . . . . . . . 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. Sequence Number Handling Examples . . . . . . . . . 58
7.6. Short Sequence Numbers . . . . . . . . . . . . . . . . . 58
7.6.1. Allow Short Sequence Numbers Feature. . . . . . . . 59
7.6.2. When to Avoid Short Sequence Numbers. . . . . . . . 60
7.7. NDP Count and Detecting Application Loss . . . . . . . . 60
7.7.1. NDP Count Usage Notes . . . . . . . . . . . . . . . 61
7.7.2. Send NDP Count Feature. . . . . . . . . . . . . . . 61
8. Event Processing. . . . . . . . . . . . . . . . . . . . . . . 62
8.1. Connection Establishment . . . . . . . . . . . . . . . . 62
8.1.1. Client Request. . . . . . . . . . . . . . . . . . . 62
8.1.2. Service Codes . . . . . . . . . . . . . . . . . . . 63
8.1.3. Server Response . . . . . . . . . . . . . . . . . . 65
8.1.4. Init Cookie Option. . . . . . . . . . . . . . . . . 66
8.1.5. Handshake Completion. . . . . . . . . . . . . . . . 67
8.2. Data Transfer. . . . . . . . . . . . . . . . . . . . . . 67
8.3. Termination. . . . . . . . . . . . . . . . . . . . . . . 68
8.3.1. Abnormal Termination. . . . . . . . . . . . . . . . 70
8.4. DCCP State Diagram . . . . . . . . . . . . . . . . . . . 70
8.5. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 71
9. Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.1. Header Checksum Field. . . . . . . . . . . . . . . . . . 76
9.2. Header Checksum Coverage Field . . . . . . . . . . . . . 77
9.2.1. Minimum Checksum Coverage Feature . . . . . . . . . 78
9.3. Data Checksum Option . . . . . . . . . . . . . . . . . . 78
9.3.1. Check Data Checksum Feature . . . . . . . . . . . . 79
9.3.2. Checksum Usage Notes. . . . . . . . . . . . . . . . 79
10. Congestion Control . . . . . . . . . . . . . . . . . . . . . 80
10.1. TCP-like Congestion Control . . . . . . . . . . . . . . 81
10.2. TFRC Congestion Control . . . . . . . . . . . . . . . . 81
10.3. CCID-Specific Options, Features, and Reset
Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
10.4. CCID Profile Requirements . . . . . . . . . . . . . . . 84
10.5. Congestion State. . . . . . . . . . . . . . . . . . . . 84
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 85
11.1. Acks of Acks and Unidirectional Connections . . . . . . 86
11.2. Ack Piggybacking. . . . . . . . . . . . . . . . . . . . 87



Kohler/Handley/Floyd [Page 5]

INTERNET-DRAFT Expires: 1 June 2006 December 2005


11.3. Ack Ratio Feature . . . . . . . . . . . . . . . . . . . 87
11.4. Ack Vector Options. . . . . . . . . . . . . . . . . . . 89
11.4.1. Ack Vector Consistency . . . . . . . . . . . . . . 91
11.4.2. Ack Vector Coverage. . . . . . . . . . . . . . . . 93
11.5. Send Ack Vector Feature . . . . . . . . . . . . . . . . 94
11.6. Slow Receiver Option. . . . . . . . . . . . . . . . . . 94
11.7. Data Dropped Option . . . . . . . . . . . . . . . . . . 95
11.7.1. Data Dropped and Normal Congestion
Response . . . . . . . . . . . . . . . . . . . . . . . . . 98
11.7.2. Particular Drop Codes. . . . . . . . . . . . . . . 98
12. Explicit Congestion Notification . . . . . . . . . . . . . . 99
12.1. ECN Incapable Feature . . . . . . . . . . . . . . . . . 100
12.2. ECN Nonces. . . . . . . . . . . . . . . . . . . . . . . 100
12.3. Aggression Penalties. . . . . . . . . . . . . . . . . . 101
13. Timing Options . . . . . . . . . . . . . . . . . . . . . . . 102
13.1. Timestamp Option. . . . . . . . . . . . . . . . . . . . 102
13.2. Elapsed Time Option . . . . . . . . . . . . . . . . . . 103
13.3. Timestamp Echo Option . . . . . . . . . . . . . . . . . 104
14. Maximum Packet Size. . . . . . . . . . . . . . . . . . . . . 105
14.1. Measuring PMTU. . . . . . . . . . . . . . . . . . . . . 105
14.2. Sender Behavior . . . . . . . . . . . . . . . . . . . . 107
15. Forward Compatibility. . . . . . . . . . . . . . . . . . . . 108
16. Middlebox Considerations . . . . . . . . . . . . . . . . . . 108
17. Relations to Other Specifications. . . . . . . . . . . . . . 110
17.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 110
17.2. Congestion Manager and Multiplexing . . . . . . . . . . 111
18. Security Considerations. . . . . . . . . . . . . . . . . . . 111
18.1. Security Considerations for Partial
Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . 112
19. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 113
19.1. Packet Types Registry . . . . . . . . . . . . . . . . . 113
19.2. Reset Codes Registry. . . . . . . . . . . . . . . . . . 113	19.2. Reset Codes Registry. . . . . . . . . . . . . . . . . . 114
19.3. Option Types Registry . . . . . . . . . . . . . . . . . 114
19.4. Feature Numbers Registry. . . . . . . . . . . . . . . . 114
19.5. Congestion Control Identifiers Registry . . . . . . . . 114	19.5. Congestion Control Identifiers Registry . . . . . . . . 115
19.6. Ack Vector States Registry. . . . . . . . . . . . . . . 115
19.7. Drop Codes Registry . . . . . . . . . . . . . . . . . . 115
19.8. Service Codes Registry. . . . . . . . . . . . . . . . . 115
19.9. Port Numbers Registry . . . . . . . . . . . . . . . . . 116
20. Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . . 117	20. Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
A. Appendix: Ack Vector Implementation Notes . . . . . . . . . . 118
A.1. Packet Arrival . . . . . . . . . . . . . . . . . . . . . 120
A.1.1. New Packets . . . . . . . . . . . . . . . . . . . . 120	A.1.1. New Packets . . . . . . . . . . . . . . . . . . . . 121
A.1.2. Old Packets . . . . . . . . . . . . . . . . . . . . 121	A.1.2. Old Packets . . . . . . . . . . . . . . . . . . . . 122
A.2. Sending Acknowledgements . . . . . . . . . . . . . . . . 122
A.3. Clearing State . . . . . . . . . . . . . . . . . . . . . 123
A.4. Processing Acknowledgements. . . . . . . . . . . . . . . 124
B. Appendix: Partial Checksumming Design Motivation. . . . . . . 125



Kohler/Handley/Floyd [Page 6]

INTERNET-DRAFT Expires: 1 June 2006 December 2005


Normative References . . . . . . . . . . . . . . . . . . . . . . 126	Normative References . . . . . . . . . . . . . . . . . . . . . . 127
Informative References . . . . . . . . . . . . . . . . . . . . . 127
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 129
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 129	Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 130
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 130














































Kohler/Handley/Floyd [Page 7]

INTERNET-DRAFT Expires: 1 June 2006 December 2005


List of Tables

Table 1: DCCP Packet Types . . . . . . . . . . . . . . . . . . . 25
Table 2: DCCP Reset Codes. . . . . . . . . . . . . . . . . . . . 32
Table 3: DCCP Options. . . . . . . . . . . . . . . . . . . . . . 34
Table 4: DCCP Feature Numbers. . . . . . . . . . . . . . . . . . 39
Table 5: DCCP Congestion Control Identifiers . . . . . . . . . . 80
Table 6: DCCP Ack Vector States. . . . . . . . . . . . . . . . . 90
Table 7: DCCP Drop Codes . . . . . . . . . . . . . . . . . . . . 96










































Kohler/Handley/Floyd [Page 8]

INTERNET-DRAFT Expires: 1 June 2006 December 2005


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) [RFC 3168] and the ECN Nonce [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 [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
benefit from control over the tradeoffs between delay and reliable
in-order delivery. TCP is 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 flows, avoiding the arbitrary
delays associated with TCP. It also implements reliable connection



Kohler/Handley/Floyd Section 1. [Page 9]

INTERNET-DRAFT Expires: 1 June 2006 December 2005


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
at the receiver rather than at the sender. DCCP should be able to



Kohler/Handley/Floyd Section 2. [Page 10]

INTERNET-DRAFT Expires: 1 June 2006 December 2005


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. Implementation
strategies for DCCP sequence numbers will resemble those for other
circular arithmetic spaces, including TCP's sequence numbers [RFC
793] and DNS's serial numbers [RFC 1982]. Note that the common
technique for implementing circular comparison using two's-
complement arithmetic, whereby A < B using circular arithmetic if
and only if (A - B) < 0 using conventional two's-complement
arithmetic, may be used for DCCP sequence numbers, provided 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



Kohler/Handley/Floyd Section 3.1. [Page 11]

INTERNET-DRAFT Expires: 1 June 2006 December 2005


specified. This is to allow for future protocol extensions. In
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
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



Kohler/Handley/Floyd Section 3.3. [Page 12]

INTERNET-DRAFT Expires: 1 June 2006 December 2005


in use on the two half-connections. The endpoints achieve agreement
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
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
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
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].







Kohler/Handley/Floyd Section 3.6. [Page 13]

INTERNET-DRAFT Expires: 1 June 2006 December 2005


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
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.



Kohler/Handley/Floyd Section 4.1. [Page 14]

INTERNET-DRAFT Expires: 1 June 2006 December 2005


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).

DCCP-Response
Sent by the server in response to a DCCP-Request (the second
part of the three-way initiation handshake).

DCCP-Data
Used to transmit application data.

DCCP-Ack
Used to transmit pure acknowledgements.

DCCP-DataAck
Used to transmit application data with piggybacked
acknowledgements.

DCCP-CloseReq
Sent by the server to request that the client close the
connection.

DCCP-Close
Used by the client or the server to close the connection;
elicits a DCCP-Reset in response.

DCCP-Reset
Used to terminate the connection, either normally or abnormally.

DCCP-Sync, DCCP-SyncAck
Used to resynchronize sequence numbers after large bursts of
loss.

4.2. Packet Sequencing

Each DCCP packet carries a sequence number, so that losses can be
detected and reported. Unlike TCP sequence numbers, which are byte-
based, DCCP sequence numbers increment by one per packet. For
example:










Kohler/Handley/Floyd Section 4.2. [Page 15]

INTERNET-DRAFT Expires: 1 June 2006 December 2005


DCCP A DCCP B
------ ------
DCCP-Data(seqno 1) -->
DCCP-Data(seqno 2) -->
<-- DCCP-Ack(seqno 10, ackno 2)
DCCP-DataAck(seqno 3, ackno 10) -->
<-- DCCP-Data(seqno 11)

Every DCCP packet increments the sequence number, whether or not it
contains application data. DCCP-Ack pure acknowledgements increment
the sequence number, for instance: DCCP B's second packet above uses