WDIFF

draft-ietf-dccp-spec-05.txt --> draft-ietf-dccp-spec-06.txt

INTERNET-DRAFT UCLA/ICIR
draft-ietf-dccp-spec-05.txt UCLA
draft-ietf-dccp-spec-06.txt Mark Handley
Expires: April August 2004 UCL
Sally Floyd
ICIR
Jitendra Padhye
Microsoft Research
27 October 2003
16 February 2004

Datagram Congestion Control Protocol (DCCP)

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC 2026]. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

Abstract

This document specifies the Datagram Congestion Control Protocol
(DCCP), which implements a congestion-controlled, unreliable flow of
unicast datagrams suitable for use by applications such as streaming
media, Internet telephony, and on-line games.

Kohler/Handley/Floyd/Padhye

Kohler/Handley/Floyd [Page 1]

INTERNET-DRAFT Expires: April August 2004 February 2004 October 2003

TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:

Changes since draft-ietf-dccp-spec-04.txt:

* Rearchitected feature negotiation (Junwen Lai). draft-ietf-dccp-spec-05.txt:

* Added figures, and modified text, to the Overview section.
Figures and text partly from Eric Rescorla.

* New synchronziation mechanism: DCCP-Sync. Organization overhaul.

* DCCP-Move: Add Mobility ID and remove Old Address and Old Port,
because they wouldn't work through a NAT.

* The MD5 ID Regime is now number 1. (It is still the default.) ID
Regime 0 is the Null Regime. Also switch the meaning of the ID
Regime feature.

* Rename Drop States to Drop Codes, and renumber them.

* Ignored cannot contain more option data bytes than the offending
option.

* Rename Service Name to Service Code (Gorry Fairhurst). pseudocode for event processing.

* Rename Cslen/Checksum Length to CsCov/Checksum Coverage and change
its values by analogy Remove # NDP; replace with UDP-Lite.

* Be more specific about what Slow Receiver means.

* Allow a textual error message in DCCP-Reset.

* Mention new PMTUD, but this mention needs work.

* CCID 1: Specify when acks may be sent.

* Specify Request retransmission strategy.

* Other changes throughout.

Changes since draft-ietf-dccp-spec-03.txt:

* Specify how the Loss Window is arranged.

* Ignored can contain multiple bytes of option data.

* Refine the tables in Section 8.5.1, on Ack Vector Consistency.

Kohler/Handley/Floyd/Padhye [Page 2]

INTERNET-DRAFT Expires: April 2004 October 2003

* CC mechanisms must treat Data Dropped like ECN Marked unless
otherwise specified. Count.

* An MTU is mandatory (although PMTU is not), Remove Identification, Challenge, ID Regime, and CCIDs can affect
the MTU.

* Clarifications in response to reviewer comments.

Changes since draft-ietf-dccp-spec-02.txt:

* Identification options include the Acknowledgement Number in their
hash.

* Added an additional condition to accepting a packet with an
invalid Sequence Number: the Acknowledgement Number must be valid,
as well as the Identification options.

* Explicitly allow Connection Nonces to be negotiated in other ways
than the Connection Nonce feature.

* Bad Moves are ignored, not reset, to avoid leaking information to
attackers.

Changes since draft-ietf-dccp-spec-01.txt:

* Revise definition of when packets are reported as received, due to
ECN Nonce verification problems with the previous definition and
options.

* Replace Receive Buffer Drops with Data Dropped.

* Remove Data Discarded in favor of Data Dropped with Drop State 0. Nonce.

* Remove Buffer Closed in favor of Data Dropped with Drop State 4
[NB: now Drop Code 1].

* Add Initial Sequence Number setting guidelines.

* Add sections on retransmission of Requests, and Checksum (formerly Payload Checksum) uses a table to the
state diagram.

* Made the 4-bit Reserved field in the DCCP generic header available
for use by CCIDs. 32-bit CRC.

* Refine description Switch location of CCID 1.

* Add Middlebox Considerations.

Kohler/Handley/Floyd/Padhye [Page 3]

INTERNET-DRAFT Expires: April 2004 October 2003

* Change Identification option to allow middleboxes non-negotiable features to change port
numbers, DCCP options, and/or packet data without disrupting clarify
presentation; now the
connection. feature location controls its value.

* Specify that Ignored should be sent only on packets with
Acknowledgement Numbers. Rename "value type" to "reconciliation rule".

* Add Aggression Penalty Reset Reason. Rename "Reset Reason" to "Reset Code".

* Add Payload Checksum option. Mobility ID becomes 128 bits long.

* Add Elapsed Time option (formerly specific probabilities to CCID 3).

* Timestamp Echo option can omit Elapsed Time, or provide a two-byte
Elapsed Time value. Elapsed Time is measured in tenths of
milliseconds, not microseconds.

* Clean up DCCP-Move and feature-negotiation options discussions.

* Confirm(Connection Nonce) sends no data.

* Ack Vector implementation supports ECN Nonce Echo. Mobility ID discussion.

* Add CSlen and Partial Checksumming Design Motivation.

* Clarify that Ack Vectors may be sent even if Use Ack Vector is
false.

Kohler/Handley/Floyd/Padhye SyncAck.

Kohler/Handley/Floyd [Page 4] 2]

INTERNET-DRAFT Expires: April August 2004 February 2004 October 2003

Table of Contents

1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 8 7
2. Design Rationale. . . . . . . . . . . . . . . . . . . . . . . 9 8
3. Conventions and Terminology . . . . . . . . . . . . . . . . . 10 9
3.1. Robustness Principle Numbers and Fields . . . . . . . . . . . . . . . . . . 10 . 9
3.2. Packet Types Parts of a Connection. . . . . . . . . . . . . . . . . . 9
3.3. Features . . . . . 11
3.3. States . . . . . . . . . . . . . . . . . . . 10
3.4. Round-Trip Times . . . . . . 11
3.4. Parts of a Connection. . . . . . . . . . . . . . . 10
3.5. Robustness Principle . . . 13
4. Overview. . . . . . . . . . . . . . . . 10
4. Overview. . . . . . . . . . . . 14
4.1. Connection Initiation and Termination. . . . . . . . . . 14
4.2. Congestion Control . . . . . . 11
4.1. Packet Types . . . . . . . . . . . . . 16
4.2.1. CCID 2. . . . . . . . . . 11
4.2. Sequence Numbers . . . . . . . . . . . . . 16
4.2.2. CCID 3. . . . . . . . 12
4.3. States . . . . . . . . . . . . . . . 16
4.3. Features . . . . . . . . . . 13
4.4. Congestion Control . . . . . . . . . . . . . . 16
4.4. Example Connection . . . . . 15
4.5. Features . . . . . . . . . . . . . . 18
4.5. Examples of DCCP Congestion Control. . . . . . . . . . . 19
4.5.1. DCCP with TCP-like Congestion Control 16
4.6. Other Differences from TCP . . . . . . . 19
4.5.2. DCCP with TFRC Congestion Control . . . . . . . . 17
4.7. Example Connection . 21
5. Packet Formats. . . . . . . . . . . . . . . . . . . 18
5. Header Formats. . . . . . 22
5.1. Generic Packet Header. . . . . . . . . . . . . . . . . . 22
5.2. Sequence Number Synchronization. . 19
5.1. Generic Header . . . . . . . . . . . 27
5.2.1. Variables . . . . . . . . . . 20
5.2. DCCP-Request Header. . . . . . . . . . . . 27
5.2.2. Appropriate Sequence Numbers. . . . . . . . 23
5.3. DCCP-Response Header . . . . 28
5.2.3. Appropriate Acknowledgement Numbers . . . . . . . . 29
5.2.4. Sequence-Validity By State. . . . . . . 23
5.4. DCCP-Data, DCCP-Ack, and DCCP-DataAck Head-
ers . . . . . . 29
5.2.5. Handling Sequence-Invalid Packets . . . . . . . . . 31
5.2.6. Examples. . . . . . . . . . . . . . . 24
5.5. DCCP-CloseReq and DCCP-Close Headers . . . . . . . 31
5.3. Extended Sequence Numbers. . . . 25
5.6. DCCP-Reset Header. . . . . . . . . . . . . 32
5.3.1. Transitioning to Extended Sequence Num-
bers . . . . . . . 26
5.7. DCCP-Move Header . . . . . . . . . . . . . . . . . . . . 34
5.4. DCCP State Diagram 27
5.8. DCCP-Sync and DCCP-SyncAck Headers . . . . . . . . . . . 28
5.9. Options. . . . . . . . . 36
5.5. DCCP-Request Packet Format . . . . . . . . . . . . . . . 37
5.6. DCCP-Response Packet Format. . 29
5.9.1. Padding Option. . . . . . . . . . . . . . 38
5.7. DCCP-Data, DCCP-Ack, and DCCP-DataAck Packet
Formats . . . . . 30
5.9.2. Mandatory Option. . . . . . . . . . . . . . . . . . 30
6. Feature Negotiation . . . . . 40
5.8. DCCP-CloseReq and DCCP-Close Packet Format . . . . . . . 42
5.9. DCCP-Reset Packet Format . . . . . . . . . 31
6.1. Change Options . . . . . . . 42
5.10. DCCP-Move Packet Format . . . . . . . . . . . . . . 31
6.2. Confirm Options. . . 44
5.11. DCCP-Sync Packet Format . . . . . . . . . . . . . . . . 46
6. Options and Features. . . 32
6.3. Reconciliation Rules . . . . . . . . . . . . . . . . . . 47
6.1. Padding Option 32
6.3.1. Server-Priority . . . . . . . . . . . . . . . . . . 33
6.3.2. Non-Negotiable. . . . 48
6.2. Ignored Option . . . . . . . . . . . . . . . 33
6.4. Feature Numbers. . . . . . . 48
6.3. Mandatory Option . . . . . . . . . . . . . . 33
6.5. Examples . . . . . . 49
6.4. Feature Negotiation. . . . . . . . . . . . . . . . . . . 49
6.4.1. Value Types 34
6.6. Option Exchange. . . . . . . . . . . . . . . . . . . . . 51
6.4.2. Feature Numbers 36
6.6.1. Normal Exchange . . . . . . . . . . . . . . . . . . 52
6.4.3. Change L Option 36
6.6.2. Loss and Retransmission . . . . . . . . . . . . . . 37
6.6.3. Reordering. . . . . 52

Kohler/Handley/Floyd/Padhye [Page 5]

INTERNET-DRAFT Expires: April 2004 October 2003

6.4.4. Confirm L Option. . . . . . . . . . . . . . . . . 38
6.6.4. Preference Changes. . 53
6.4.5. Change R Option . . . . . . . . . . . . . . . 39
6.6.5. Simultaneous Negotiation. . . . 53
6.4.6. Confirm R Option. . . . . . . . . . . 39
6.6.6. Unknown Features. . . . . . . . 54
6.4.7. Unknown Features. . . . . . . . . . . 39
6.6.7. Invalid Options . . . . . . . 54
6.4.8. State Diagram . . . . . . . . . . . 40
6.6.8. Mandatory Feature Negotiation . . . . . . . . 55
6.4.9. Streamlined Negotiation . . . 40

Kohler/Handley/Floyd [Page 3]

INTERNET-DRAFT Expires: August 2004 February 2004

6.6.9. Out-of-Band Agreement . . . . . . . . . . . 58
6.5. Identification Options . . . . 41
6.6.10. State Diagram. . . . . . . . . . . . . . 58
6.5.1. Identification Regime Feature . . . . . 41
7. Sequence Numbers. . . . . . . 59
6.5.2. Connection Nonce Feature. . . . . . . . . . . . . . 59
6.5.3. Identification Option . . . 42
7.1. Variables. . . . . . . . . . . . . 60
6.5.4. Challenge Option. . . . . . . . . . . . 42
7.2. Initial Sequence Numbers . . . . . . 61
6.6. Init Cookie Option . . . . . . . . . . 43
7.3. Quiet Time . . . . . . . . . 62
6.7. Timestamp Option . . . . . . . . . . . . . . 44
7.4. Acknowledgement Numbers. . . . . . . 63
6.8. Elapsed Time Option. . . . . . . . . . . 44
7.5. Validity and Synchronization . . . . . . . . 63
6.9. Timestamp Echo Option. . . . . . . 45
7.5.1. Sequence-Validity Rules . . . . . . . . . . . 64
6.10. Loss Window Feature . . . 45
7.5.2. Handling Sequence-Invalid Packets . . . . . . . . . 47
7.5.3. Sequence and Acknowledgement Number
Windows. . . . . . . 65
7. Congestion Control IDs. . . . . . . . . . . . . . . . . . . . 65
7.1. Unspecified Sender-Based Congestion
Control 48
7.5.4. Sequence Window Feature . . . . . . . . . . . . . . 49
7.5.5. Sequence Number Attacks . . . . . . . . . . . . . 66
7.2. TCP-like Congestion Control. . 49
7.5.6. Examples. . . . . . . . . . . . . . 67
7.3. TFRC Congestion Control. . . . . . . . . 50
7.6. Extended Sequence Numbers. . . . . . . . . 68
7.4. CCID-Specific Options, Features, and Reset
Reasons . . . . . . . 51
7.6.1. When to Use Extended Sequence Numbers . . . . . . . 51
7.6.2. Header Processing . . . . . . . . . . . . . 68
8. Acknowledgements. . . . . 52
7.6.3. Transitioning to Extended Sequence Num-
bers . . . . . . . . . . . . . . . . . . 70
8.1. Acks of Acks and Unidirectional
Connections . . . . . . . . . 53
7.6.4. Sequence Transition Capable Feature . . . . . . . . 54
7.7. NDP Count and Detecting Application Loss . . . . . . . . 70
8.2. Ack Piggybacking 55
7.7.1. Usage Notes . . . . . . . . . . . . . . . . . . . . 72
8.3. Ack Ratio 56
7.7.2. Send NDP Count Feature. . . . . . . . . . . . . . . 56
8. Event Processing. . . . . . 72
8.4. Use Ack Vector Feature . . . . . . . . . . . . . . . . . 73
8.5. Ack Vector Options 56
8.1. Connection Establishment . . . . . . . . . . . . . . . . 56
8.1.1. Client Request. . . . 73
8.5.1. Ack Vector Consistency. . . . . . . . . . . . . . . 75
8.5.2. Ack Vector Coverage . 57
8.1.2. Service Codes . . . . . . . . . . . . . . . 77
8.6. Slow Receiver Option . . . . 57
8.1.3. Server Response . . . . . . . . . . . . . . 77
8.7. Data Dropped Option. . . . . 59
8.1.4. Init Cookie Option. . . . . . . . . . . . . . . 78
8.7.1. Data Dropped and Normal Congestion
Response . . 60
8.1.5. Handshake Completion. . . . . . . . . . . . . . . . 60
8.2. Data Transfer. . . . . . . . . 81
8.7.2. Particular Drop Codes . . . . . . . . . . . . . 61
8.3. Termination. . . 81
8.8. Payload Checksum Option. . . . . . . . . . . . . . . . . 82
9. Explicit Congestion Notification. . . . . 62
8.3.1. Abnormal Termination. . . . . . . . . . . 83
9.1. ECN Capable Feature. . . . . . 63
8.4. DCCP State Diagram . . . . . . . . . . . . . 83
9.2. ECN Nonces . . . . . . 63
8.5. Pseudocode . . . . . . . . . . . . . . . . . 84
9.3. Other Aggression Penalties . . . . . . 64
9. Checksums . . . . . . . . . 85
10. Multihoming and Mobility . . . . . . . . . . . . . . . . . 68
9.1. Header Checksum Field. . 85
10.1. Mobility Capable Feature. . . . . . . . . . . . . . . . 86
10.2. Mobility ID . 68
9.2. Header Checksum Coverage Field . . . . . . . . . . . . . 69
9.3. Data Checksum Option . . . . . . . . 86
10.3. Security. . . . . . . . . . . 70
9.3.1. Check Data Checksum Feature . . . . . . . . . . . . 71
9.3.2. Usage Notes . 87
10.4. . . . . . . . . . . . . . . . . . . . 71
10. Congestion Control State. IDs . . . . . . . . . . . . . . . . 87
10.5. Loss During Transition. . . . 71
10.1. Unspecified Sender-Based Congestion
Control . . . . . . . . . . . . . 87

Kohler/Handley/Floyd/Padhye . . . . . . . . . . . . . . 72
10.2. TCP-like Congestion Control . . . . . . . . . . . . . . 74
10.3. TFRC Congestion Control . . . . . . . . . . . . . . . . 74
10.4. CCID-Specific Options, Features, and Reset

Kohler/Handley/Floyd [Page 6] 4]

INTERNET-DRAFT Expires: April August 2004 October 2003 February 2004

Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
11. Maximum Packet Size. Acknowledgements . . . . . . . . . . . . . . . . . . . . 88
12. Middlebox Considerations . . 76
11.1. Acks of Acks and Unidirectional
Connections . . . . . . . . . . . . . . . . 90
13. Abstract API . . . . . . . . . 77
11.2. Ack Piggybacking. . . . . . . . . . . . . . . . 91
14. Multiplexing Issues. . . . . 78
11.3. Ack Ratio Feature . . . . . . . . . . . . . . . . 91
15. DCCP and RTP . . . 79
11.4. Ack Vector Options. . . . . . . . . . . . . . . . . . . 79
11.4.1. Ack Vector Consistency . . . 92
16. Security Considerations. . . . . . . . . . . . 81
11.4.2. Ack Vector Coverage. . . . . . . . 93
16.1. Security Considerations for Mobility. . . . . . . . . 83
11.5. Send Ack Vector Feature . 94
16.2. Security Considerations for Partial Check-
sums. . . . . . . . . . . . . . . . 83
11.6. Slow Receiver Option. . . . . . . . . . . . . . 94
17. IANA Considerations. . . . . 84
11.7. Data Dropped Option . . . . . . . . . . . . . . . . 95
18. Thanks . . 84
11.7.1. Data Dropped and Normal Congestion
Response . . . . . . . . . . . . . . . . . . . . . . . . . 96
A. Appendix: Ack Vector Implementation Notes 87
11.7.2. Particular Drop Codes. . . . . . . . . . . 97
A.1. Packet Arrival . . . . 87
12. Explicit Congestion Notification . . . . . . . . . . . . . . 88
12.1. ECN Capable Feature . . . 99
A.1.1. New Packets . . . . . . . . . . . . . . . 88
12.2. ECN Nonces. . . . . . 99
A.1.2. Old Packets . . . . . . . . . . . . . . . . . 89
12.3. Other Aggression Penalties. . . . 100
A.2. Sending Acknowledgements . . . . . . . . . . . 90
13. Timing Options . . . . . 101
A.3. Clearing State . . . . . . . . . . . . . . . . . . 90
13.1. Timestamp Option. . . . 102
A.4. Processing Acknowledgements. . . . . . . . . . . . . . . 103
B. Appendix: Design Motivation . . 90
13.2. Elapsed Time Option . . . . . . . . . . . . . . . . . 104
B.1. CsCov . 91
13.3. Timestamp Echo Option . . . . . . . . . . . . . . . . . 92
14. Multihoming and Partial Checksumming Mobility . . . . . . . . . . . . . 104
Normative References . . . . . 92
14.1. Mobility Capable Feature. . . . . . . . . . . . . . . . 93
14.2. Mobility ID Feature . . 105
Informative References . . . . . . . . . . . . . . . . 93
14.3. Mobile Host Processing. . . . . . 106
Authors' Addresses . . . . . . . . . . . 94
14.4. Stationary Host Processing. . . . . . . . . . . . . 107

Kohler/Handley/Floyd/Padhye [Page 7]

INTERNET-DRAFT Expires: April 2004 October 2003

1. Introduction

This document specifies the Datagram . . 95
14.5. Congestion Control Protocol
(DCCP). DCCP provides the following features:

o An unreliable flow of datagrams, with acknowledgements.

o A reliable handshake for connection setup and teardown.

o Reliable negotiation of options, including negotiation of a
suitable congestion control mechanism.

o Mechanisms allowing a server to avoid holding any state for
unacknowledged connection attempts or already-finished
connections.

o Optional mechanisms that tell the sender, with high reliability,
which packets reached the receiver, and whether those packets were
ECN marked, corrupted, or dropped in the receive buffer.

o Congestion control incorporating Explicit Congestion Notification
(ECN) and the ECN Nonce, as per [RFC 3168] and [ECN NONCE].

o Path MTU discovery, as per [RFC 1191].

DCCP is intended for applications that require State. . . . . . . . . . . . . . . . 96
14.6. Security. . . . . . . . . . . . . . . . . . . . . . . . 96
15. Maximum Packet Size. . . . . . . . . . . . . . . . . . . . . 97
16. Forward Compatibility. . . . . . . . . . . . . . . . . . . . 99
17. Middlebox Considerations . . . . . . . . . . . . . . . . . . 100
18. Relations to Other Specifications. . . . . . . . . . . . . . 101
18.1. DCCP and RTP. . . . . . . . . . . . . . . . . . . . . . 101
18.2. Multiplexing Issues . . . . . . . . . . . . . . . . . . 102
19. Security Considerations. . . . . . . . . . . . . . . . . . . 103
19.1. Security Considerations for Mobility. . . . . . . . . . 103
19.2. Security Considerations for Partial Check-
sums. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
20. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 105
21. Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
A. Appendix: Ack Vector Implementation Notes . . . . . . . . . . 106
A.1. Packet Arrival . . . . . . . . . . . . . . . . . . . . . 108
A.1.1. New Packets . . . . . . . . . . . . . . . . . . . . 108
A.1.2. Old Packets . . . . . . . . . . . . . . . . . . . . 109
A.2. Sending Acknowledgements . . . . . . . . . . . . . . . . 110
A.3. Clearing State . . . . . . . . . . . . . . . . . . . . . 110

Kohler/Handley/Floyd [Page 5]

INTERNET-DRAFT Expires: August 2004 February 2004

A.4. Processing Acknowledgements. . . . . . . . . . . . . . . 112
B. Appendix: Design Motivation . . . . . . . . . . . . . . . . . 113
B.1. CsCov and Partial Checksumming . . . . . . . . . . . . . 113
Normative References . . . . . . . . . . . . . . . . . . . . . . 114
Informative References . . . . . . . . . . . . . . . . . . . . . 115
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 116
Intellectual Property Notice . . . . . . . . . . . . . . . . . . 117

Kohler/Handley/Floyd [Page 6]

INTERNET-DRAFT Expires: August 2004 February 2004

1. Introduction

This document describes the flow-based
semantics Datagram Congestion Control Protocol
(DCCP), a transport protocol that implements a congestion-
controlled, bidirectional stream of TCP, but which do not want TCP's in-order delivery unreliable datagrams.
Specifically, DCCP provides:

o An unreliable flow of datagrams, with acknowledgements.

o Reliable handshakes for connection setup and
reliability semantics, or which would like different teardown.

o Reliable negotiation of options, including negotiation of a
suitable congestion control dynamics than TCP. Similarly, DCCP is intended mechanism.

o Mechanisms allowing a server to avoid holding any state for
applications that do not require features of SCTP
unacknowledged connection attempts or already-finished
connections.

o Congestion control incorporating Explicit Congestion Notification
(ECN) and the ECN Nonce, as per [RFC 2960] such 3168] and [RFC 3540].

o Acknowledgement mechanisms communicating packet loss and ECN mark
information. Acks are transmitted as
sequenced delivery within multiple streams.

Applications reliably as the relevant
congestion control mechanism requires, possibly completely
reliably.

o Optional mechanisms that could make use of DCCP include those with timing
constraints on tell the delivery of 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 Transfer Unit (PMTU) discovery, as per [RFC 1191].

DCCP is intended for applications, such that as streaming media and
Internet telephony, where reliable in-order delivery, when combined with
congestion control, is likely to can result in some information arriving at the
receiver after it is no longer of use. Such applications might include streaming media and
Internet telephony.

To date So far, most such
applications have used either used TCP, with the attendant quality
problems described above, caused by late data delivery, or used UDP and implemented
their own congestion control mechanisms (or no congestion control at all).
The purpose of
DCCP is to provide a provides standard way to implement
congestion control and congestion control negotiation mechanisms for such
applications. One of the motivations for DCCP is to enable It enables the use of ECN, along with conformant end-to-end end-
to-end congestion control, for applications that would otherwise be
using UDP. In addition, DCCP implements reliable connection setup,
teardown, and feature

Kohler/Handley/Floyd/Padhye negotiation.

DCCP's target applications require the flow-based semantics of TCP,
but do not want TCP's in-order delivery and reliability, or would

Kohler/Handley/Floyd Section 1. [Page 8] 7]

INTERNET-DRAFT Expires: April August 2004 October 2003

negotiation.

A DCCP connection contains acknowledgement traffic as well as data
traffic. Acknowledgements inform a sender whether its packets
arrived, and whether they were ECN marked. Acks are transmitted as
reliably as the February 2004

like different congestion control mechanism in use requires,
possibly completely reliably. dynamics than TCP.

2. Design Rationale

DCCP is was intended to be used by applications that currently use UDP
without end-to-end congestion control. The desire is for many Most streaming UDP
applications to should have little reason not to use DCCP instead of UDP, switch to DCCP, once DCCP
it is deployed. Thus, DCCP was designed to have as little overhead
as possible, both in terms both of the size of the packet header size and in terms of
the state and CPU overhead required at the end hosts.

This desire for minimal overhead results in the design decision to
include only Only the minimal
necessary functionality was included in DCCP, leaving other
functionality, such as FEC or semi-reliability, forward error correction (FEC), semi-
reliability, and multiple streams, to be layered on top of DCCP as
desired. The This desire for minimal overhead is also one of the
reasons to propose DCCP instead of just avoid proposing an unreliable version variant of SCTP for applications currently using UDP. the Stream
Control Transmission Protocol (SCTP, [RFC 2960]).

Different forms of conformant congestion control are appropriate for
different applications. For example, applications such as on-line
games might want to make quick use of any available bandwidth.
Other applications, and such as streaming media, might trade off this
responsiveness for a second motivation behind steadier, less bursty rate, since sudden rate
changes cause unacceptable UI glitches (such as audible pauses or
clicks in the design of playout stream). Thus, DCCP is to allow allows applications to
choose between several forms of congestion control. One choice,
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 be able
to tolerate the abrupt changes in congestion window typical of TCP.
A second alternative, TCP-Friendly Rate Control (TFRC), a form of
equation-based congestion control, minimizes abrupt changes in the
sending rate while maintaining longer-term fairness with TCP. TCP-
like Congestion Control is appropriate for applications such as on-
line games that want to make use of all the available bandwidth
quickly, but can tolerate rapid reductions in rate without serious
consequences. TFRC is more appropriate for applications such as
streaming media, where rapid rate changes cause unacceptable UI
glitches (audible pauses or clicks in the playout stream, for
example). These applications would prefer to give up on rapid
consumption of available bandwidth must be able to tolerate the abrupt changes
in favor congestion window typical of TCP. A second alternative, TCP-
Friendly Rate Control (TFRC, [RFC 3448]), a steadier rate. form of equation-based
congestion control, minimizes abrupt changes in the sending rate
while maintaining longer-term fairness with TCP.

DCCP also allows lets unreliable traffic to safely use ECN safely. 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

Kohler/Handley/Floyd/Padhye Section 2. [Page 9]

INTERNET-DRAFT Expires: April 2004 October 2003
detect or respond to congestion. DCCP kernel APIs will have no such
issues, since DCCP itself implements congestion control.

In proposing a new transport protocol, it is necessary to justify
the design decision

We chose not to require the use of the Congestion
Manager, as well as the design decision to add a new transport
protocol to the current family of UDP, TCP, and SCTP. The
Congestion Manager [RFC 3124]
3124], which allows multiple concurrent streams between the same
sender and receiver to share congestion control.
However, the The current
Congestion Manager can only be used by applications that have their
own end-to-end feedback about packet losses, and 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 8]

INTERNET-DRAFT Expires: August 2004 February 2004

TFRC where the state about past packet drops or marks is maintained
at the receiver rather than at the sender. While 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.

3. Conventions and Terminology

Each DCCP connection runs between two endpoints, which we often name
DCCP A and DCCP B. Data may pass over the connection in either or
both directions.

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

Reserved bitfields in DCCP packet headers MUST be ignored by
receivers, and MUST be set to zero by senders, unless otherwise
specified.

3.1. Robustness Principle

DCCP implementations should follow TCP's "general principle of
robustness": be conservative in what you do, be liberal in what you
accept from others.

Kohler/Handley/Floyd/Padhye Section 3.1. [Page 10]

INTERNET-DRAFT Expires: April 2004 October 2003

3.2. Packet Types

DCCP has ten different packet types.

The DCCP-Request and DCCP-Response packets are used in connection
initiation, and the DCCP-CloseReq, DCCP-Close, and DCCP-Reset
packets are used in connection termination, as described in Section
4.1.

The other five packet types are as follows:

DCCP-Data
Used to transmit data. It carries no acknowledgement
information.

DCCP-Ack
Used for pure acknowledgements.

DCCP-DataAck
Used for piggybacked data-plus-acknowledgements.

DCCP-Move
Supports multihoming and mobility.

DCCP-Sync
Used to resynchronize sequence numbers after a large burst of
loss.

All of these packets except for DCCP-DataAck, DCCP-Move, and DCCP-
Sync are shown in the example diagram below.

3.3. States

DCCP endpoints progress through different states during the course
of a connection. The figure below shows the typical progress
through these states for a client and server.

Kohler/Handley/Floyd/Padhye Section 3.3. [Page 11]

INTERNET-DRAFT Expires: April 2004 October 2003

Client State: Server State:
------------- -------------
CLOSED LISTEN
REQUEST DCCP-Request ->
<- DCCP-Response RESPOND
OPEN DCCP-Ack ->
<- DCCP-Data OPEN
DCCP-Ack ->
<- DCCP-CloseReq CLOSEREQ
CLOSING DCCP-Close ->
<- DCCP-Reset CLOSED
TIME-WAIT
CLOSED
The client and server's typical progress through states.

CLOSED
Represents a nonexistent connection.

LISTEN
Represents a server socket in the passive listening state.
LISTEN and CLOSED are not associated with any particular DCCP
connection.

REQUEST
The client socket enters this state, from CLOSED, after sending
a DCCP-Request packet to try to initiate a connection.

RESPOND
A server socket enters this state, from LISTEN, after receiving
a DCCP-Request from a client.

OPEN
The central, data transfer portion of a DCCP connection. Client
and server enter into this state from REQUEST and RESPOND,
respectively. Sometimes we speak of SERVER-OPEN and CLIENT-OPEN
states, corresponding to the server's OPEN state and the
client's OPEN state.

CLOSEREQ
A server socket enters this state, from SERVER-OPEN,
network byte order (most significant byte first).

We occasionally refer to signal
that the connection is over, but "left" and "right" sides of a bit
field. "Left" means towards the client must hold Time-Wait
state.

CLOSING
Either server or client can enter this state to close most significant bit, and "right"
means towards the
connection.

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

INTERNET-DRAFT Expires: April 2004 October 2003

TIME-WAIT
A socket remains least significant bit.

Reserved bitfields in this state for 2MSL after the connection has
been torn down, DCCP packet headers MUST be ignored by
receivers, and MUST be set to prevent mistakes due zero by senders, unless otherwise
specified.

Random numbers in DCCP are used for their security properties, and
MUST be chosen according to the delivery of old
packets.

3.4. guidelines in [RFC 1750].

3.2. Parts of a Connection

The

Each DCCP connection runs between two endpoints, which we often name
DCCP A and DCCP B consists of four sets
of packets, as follows:

(1) Data packets from DCCP A to DCCP B.

(2) Acknowledgements from DCCP B to

DCCP A.

(3) Data packets from DCCP B to connections are actively initiated by one endpoint. The active
endpoint is called the client, and the passive endpoint is called
the server.

DCCP A.

(4) Acknowledgements connections are bidirectional; data may pass from DCCP A either
endpoint to the other. This means that data and acknowledgements
may be flowing in both directions simultaneously. Logically,
however, a DCCP B.

These four subflows are grouped into connection consists of two half-connections,
illustrated separate unidirectional
connections, called half-connections. Each half-connection consists
of the data packets sent by one endpoint and the corresponding
acknowledgements sent by the other endpoint. We can illustrate this
as follows:

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

INTERNET-DRAFT Expires: August 2004 February 2004

+--------+ A-to-B half-connection: +--------+
| | + - - - - - - - - - - - - - - - - - - - + | |
| | | (1) | | |
| | --> data packets --> | |
| | | (2) | | |
| | <-- acknowledgements | |
| | + - - - - - - - - - - - - - - - - - - - + <-- | |
| DCCP A | | DCCP B |
| | B-to-A half-connection: | |
| | + - - - - - - - - - - - - - - - - - - - + | |
| | | (3) | | |
| | <-- data packets <-- | |
| | | (4) | | |
| |
+--------+ --> 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 HC-Sender is the
endpoint sending data, while the HC-Receiver is the endpoint sending
acknowledgements. For example, in the A-to-B half-connection,
DCCP A is the HC-Sender and DCCP B is the HC-Receiver.

3.3. Features

A feature is a DCCP connection attribute, identified by a feature
number and an endpoint, 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, whether mobility is allowed, and whether ECN is
supported. The endpoints can achieve agreement by out-of-band
communication, or through the exchange of feature negotiation
options in DCCP headers.

The notation F/A represents the following terms to refer to subsets feature with feature number F
located at DCCP endpoint A; the feature F/B has the same feature
number, but is located at the other endpoint. Both DCCP A and endpoints
DCCP B know, and agree on, the values of a both F/A and F/B, but F/A
and F/B may have different values.

DCCP connection.

Subflows A subflow consists of either data or acknowledgement packets,
sent in one direction. Each of is called the four sets of packets above feature location for all features F/A, and the
feature remote for all features F/B.

3.4. Round-Trip Times

We sometimes refer to a round-trip time for setting timers, for
example. If no useful round-trip time estimate is available, a subflow. (Subflows may overlap to some extent, since
acknowledgements may DCCP
implementation SHOULD use 0.2 seconds instead.

3.5. Robustness Principle

DCCP implementations should follow TCP's "general principle of
robustness": be piggybacked on data packets.)

Kohler/Handley/Floyd/Padhye conservative in what you do, be liberal in what you

Kohler/Handley/Floyd Section 3.4. 3.5. [Page 13] 10]

INTERNET-DRAFT Expires: April August 2004 October 2003

Sequences
A sequence consists of all packets sent in one direction,
regardless of whether they are February 2004

accept from others.

4. Overview

DCCP's high-level connection dynamics should seem familiar to anyone
who knows TCP. DCCP connections, like TCP connections, progress
through three phases: initiation (including a three-way handshake),
data or acknowledgements. The
sets 1+4 transfer, and 2+3, above, are sequences. Each packet on a
sequence has a different sequence number.

Half-connections
A half-connection consists of termination. Data can flow both ways over the
connection. An acknowledgement framework lets senders discover how
much data packets sent in one
direction, plus has been lost; congestion control uses this information to
avoid unfairly congesting the corresponding acknowledgements. network. Of course, DCCP provides
unreliable datagram semantics, not TCP's reliable bytestream
semantics. The sets
1+2 and 3+4, above, are half-connections. Half-connections are
named after the direction of application must package its data flow, so the A-to-B half-
connection contains the into explicit
frames, and must retransmit its own data packets from A as necessary. It may be
useful to B think of DCCP either as TCP minus bytestream semantics and
reliability, or as UDP plus congestion control, handshakes, and
acknowledgements.

4.1. Packet Types

DCCP uses eleven packet types to implement various protocol
functions. For example, every new connection attempt begins with a
DCCP-Request packet sent by the
acknowledgements from B 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 A.

HC-Sender and HC-Receiver
In send an unexpected combination such as TCP's
SYN+FIN+ACK+RST.

Eight packet types occur during the context progress of a single half-connection, typical
connection---two only during the HC-Sender is initiation phase, three during the
endpoint sending data, while
data transfer phase, and three only during the HC-Receiver is termination phase:

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

Note the three-way handshakes during initiation and termination.
The three remaining packet types are used for special purposes: when
an endpoint
sending acknowledgements. moves, or to resynchronize after bursts of loss.

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

INTERNET-DRAFT Expires: August 2004 February 2004

Every DCCP packet starts with a common, 12-byte generic header, but
different packet types may include different amounts of additional
data. For example, in the A-to-B half-
connection, DCCP A is DCCP-Ack packet type includes an
Acknowledgement Number. Every packet type may also contain options,
up to around 1000 bytes' worth.

All of the HC-Sender and DCCP B is packet types are described below.

DCCP-Request
Sent by the HC-
Receiver.

4. Overview

4.1. Connection Initiation and Termination

Every DCCP client to initiate a connection is actively initiated (the first part of
the three-way handshake).

DCCP-Response
Sent by one DCCP, which
connects the server in response to a DCCP socket in DCCP-Request (the second
part of the passive listening state. We refer three-way handshake).

DCCP-Data
Used to the active endpoint as "the client" and the passive endpoint as
"the server".

Client Server
------ ------
DCCP-Request ->
[Ports, service, features]
<- DCCP-Response
[Features, cookie] transmit data.

DCCP-Ack ->
[Features, cookie]

DCCP connection initiation.

In
Used for pure acknowledgements.

DCCP-DataAck
Used for piggybacked data-plus-acknowledgements.

DCCP-CloseReq
Sent by the DCCP-Request message, server to request that the client tells close the server
connection.

DCCP-Close
Used to close the ports
it wants connection; elicits a DCCP-Reset in response.

DCCP-Reset
Used to communicate on and possibly terminate the Service Code connection, either normally or abnormally.

DCCP-Move
Supports multihoming and mobility.

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

4.2. Sequence Numbers

Each DCCP packet carries a sequence number, so that losses can be
detected and reported. But unlike TCP's byte-based sequence
numbers, DCCP sequence numbers are attached to talk to. The DCCP-Request message also starts
feature negotiation, which, for pedagogical reasons, we will present
separately in packets. Each packet
sent increments the next section.

Kohler/Handley/Floyd/Padhye sequence number by one. For example:

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

INTERNET-DRAFT Expires: April August 2004 October 2003

In the DCCP-Response message, the server tells the client February 2004

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)

Note that it is
willing to accept even DCCP-Ack pure acknowledgements increment the connection and continues feature negotiation.
In order to prevent SYN-flood style DOS attacks, DCCP incorporates a
cookie exchange: The server can provide sequence
number; after the client DCCP-Ack with a cookie
that contains all sequence number 10, the negotiation state. following
DCCP-Data packet uses the next sequence number, 11. This cookie must be echoed
by lets the client
endpoints tell when acknowledgements are lost in the DCCP-Ack, thus removing the need for the server network. It
also means that endpoints can get out of sync after a long burst of
loss. The DCCP-Sync and DCCP-SyncAck packet types let DCCP recover
from large loss bursts; see Section 7.5.

Also note that, since DCCP is an unreliable protocol, there are no
retransmissions, and it doesn't make sense to keep state.

In the DCCP-Ack message, have a cumulative
acknowledgement field. Acknowledgement Number (ackno) fields equal
the client acknowledges largest sequence number received, rather than the DCCP-Response
and returns TCP-style
smallest sequence number not received. Separate options indicate
any intermediate sequence numbers that weren't received.

4.3. States

DCCP endpoints progress through different states during the cookie course
of a connection, corresponding roughly to permit the server to complete its side three phases of
initiation, data transfer, and termination. The figure below shows
the connection. This message may also include feature negotiation
messages.

DCCP does not support TCP-style simultaneous open. In particular, a
host MUST NOT respond to typical progress through these states for a client and server.

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

INTERNET-DRAFT Expires: August 2004 February 2004

Client Server
------ ------
(0) No connection
CLOSED LISTEN

(1) Initiation
REQUEST DCCP-Request packet with a -->
<-- DCCP-Response
packet unless the destination port specified RESPOND
PARTOPEN DCCP-Ack or DCCP-DataAck -->

(2) Data transfer
OPEN <-- DCCP-Data, Ack, DataAck --> OPEN

(3) Termination
<-- DCCP-CloseReq CLOSEREQ
CLOSING DCCP-Close -->
<-- DCCP-Reset CLOSED
TIMEWAIT
CLOSED
The client and server's typical progress through states.

The states are as follows; Section 8 describes them in the DCCP-Request
corresponds to more detail.

CLOSED
Represents a nonexistent connection.

LISTEN
Represents a local server socket opened for listening. This preserves in the invariant that every connection has one client passive listening state.
LISTEN and one server. CLOSED are not associated with any particular DCCP
connection.

REQUEST
The server sends client socket enters this state, from CLOSED, after sending
a DCCP-CloseReq DCCP-Request packet to the client to ask it try to
close the connection with initiate a DCCP-Close. The connection.

RESPOND
A server sends DCCP-
CloseReq, rather than DCCP-Close, when it wants the socket enters this state, from LISTEN, after receiving
a DCCP-Request from a client.

PARTOPEN
The client to hold
Time-Wait socket enters this state, from REQUEST, after
receiving a DCCP-Response from the server. This state for
represents the connection. Only third phase of the server three-way handshake. The
client may generate send data in this state, but it MUST include an
Acknowledgement Number on all of its packets.

OPEN
The central, data transfer portion of a
DCCP-CloseReq packet. This means that the client cannot force the DCCP connection. Client

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

INTERNET-DRAFT Expires: August 2004 February 2004

and server enter into this state from PARTOPEN and RESPOND,
respectively. Sometimes we speak of SERVER-OPEN and CLIENT-OPEN
states, corresponding to maintain connection the server's OPEN state after and the connection is closed.

An endpoint sends a DCCP-Close packet
client's OPEN state.

CLOSEREQ
A server socket enters this state, from SERVER-OPEN, to request signal
that the other
endpoint tear down the connection via DCCP-Reset. Every explicitly-
terminated connection ends with a DCCP-Reset packet. The receiver
of DCCP-Reset holds Time-Wait is over, but the client must hold TIMEWAIT
state.

CLOSING
Either server or client can enter this state for to close the
connection. DCCP-Reset
is sent

TIMEWAIT
A socket remains in response to DCCP-Close during normal connection
termination, or due to some inappropriate protocol event.

Client Server
------ ------
<- DCCP-CloseReq
DCCP-Close ->
<- DCCP-Reset

DCCP this state for 2MSL after the connection termination.

DCCP shuts down both half-connections as a unit; it has no states
analogous
been torn down, to TCP's FINWAIT and CLOSEWAIT states, where one TCP
"half-connection" prevent mistakes due to the delivery of old
packets. One MSL, or Maximum Segment Lifetime, is closed and the other remains open. However,
DCCP implementations SHOULD allow applications to declare that they
are no longer interested maximum
length of time a packet could survive in receiving data. This would allow DCCP
implementations to streamline state for certain half-connections.

Kohler/Handley/Floyd/Padhye Section 4.1. [Page 15]

INTERNET-DRAFT Expires: April 2004 October 2003

See Section 8.7, on the Data Dropped option---and particularly its
Drop Code 1---for more information.

4.2. network.

4.4. Congestion Control

Each half-connection is managed by a

DCCP connections are congestion controlled. Unlike TCP, however,
DCCP supports multiple congestion control mechanism
named mechanisms for
applications to choose from. In fact, the two half-connections can
be governed by different mechanisms. Each mechanism corresponds to
a single-byte one-byte congestion control identifier, or CCID. The A CCID for a half-connection describes
how the HC-Sender limits data packet rates; how it maintains
necessary parameters, such as congestion windows; how the HC-Receiver HC-
Receiver sends congestion feedback via acknowledgements; and how it
manages the acknowledgement rate.

The endpoints negotiate their CCIDs at during connection setup; the initiation.
So far, CCIDs 2 and 3 have been defined for the two half-connections need not be the same. use with DCCP; CCID 0 is
reserved, and CCID 1 is used for special purposes (see Section 7 introduces the currently allocated CCIDs, which are
defined in separate profile documents.

4.2.1.
10.1).

CCID 2

CCID 2's congestion control corresponds to TCP-like Congestion Control, which is extremely similar
to that of TCP. The sender maintains a congestion window and sends
packets until that window is full. Packets are acknowledged by the
receiver. Dropped packets and ECN [RFC 3168] are used to indicate congestion.
The
congestion; the response to congestion is to halve the congestion
window. One
subtle diference between DCCP and TCP is that the acknowledgements Acknowledgements in DCCP CCID 2 contain the sequence numbers of
all received packets within
a given some window, not just the highest sequence number as in TCP's
cumulative ackowledgement.

4.2.2. CCID 3 similar to a super
selective-acknowledgement (SACK, [RFC 3517]).

CCID 3 is provides TFRC Congestion Control, an equation-based form of
congestion control which is intended to provide a smoother response

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

INTERNET-DRAFT Expires: August 2004 February 2004

to congestion than CCID 2. The sender maintains a "transmit rate".
The receiver sends acknowledgement packets which also contain containing information
about the receiver's estimate of packet loss. The sender uses this
information to update its transmit rate. Although CCID 3 behaves
somewhat differently from TCP in its short term congestion response,
it is designed to operate fairly with TCP over the long term.

4.3.

The behaviors of CCIDs 2 and 3 are fully defined in separate profile
documents [CCID 2 PROFILE] [CCID 3 PROFILE].

4.5. Features

In DCCP,

Agreement on DCCP feature negotiation values is performed achieved by attaching explicit
negotiation, using options to
other in DCCP packets. Thus feature packet headers. This generally
happens at connection startup, but negotiation can be piggybacked on begin at any other DCCP message. This allows feature negotiation during
connection initiation as well as feature renegotiation during data
flow.

Kohler/Handley/Floyd/Padhye Section 4.3. [Page 16]

INTERNET-DRAFT Expires: April 2004 October 2003

DCCP features are one-sided. Thus, it's possible to have a
different congestion control regime for data sent from client to
server than from server to client.
time. The endpoint in charge of a
particular feature is called its feature location; the other
endpoint is called the feature remote. Feature negotiation is done
with the relevant options are Change L, Confirm L, Change R, and
Confirm R options, R, with the "L" options sent by the feature location, location and the
"R" options sent by the feature remote.

A Change R message says to the peer peer, "change this option setting feature value on
your side". The peer responds with a Confirm L, meaning "I've
changed it". Some sample exchanges follow: The suggested option setting in Change R can sometimes
contain multiple values, which are sorted in preference order. For
example:

Client Server
------ ------
Change R(CCID, 2) ->
<- -->
<-- Confirm L(CCID, 2)
* agreement that (CCID,Server) CCID/Server = 2 *

Change R(CCID, 3 4) -->
<-- Confirm L(CCID, 4, 4 2)
* agreement that CCID/Server = 4 *

In this the second exchange, the peers agree to set client requests that the server's server use
either CCID 3 or CCID 4, with 3 preferred. The server chooses 4,
giving its preference list of "4 2".

A party that wants to 2. change a feature located at itself issues a
"Change L" option, which elicits a "Confirm R" in reply.

Client Server
------ ------
<-- Change R(CCID, L(CCID, 3 4) ->
<- 2)
Confirm L(CCID, 4, 4 R(CCID, 3, 3 2) -->
* agreement that (CCID,Server) CCID/Server = 4 3 *

Kohler/Handley/Floyd Section 4.5. [Page 16]

INTERNET-DRAFT Expires: August 2004 February 2004

In this example, the server requests CCID value 3 or 2 for the
server's CCID, with 3 preferred, and the client agrees.

Retransmissions make feature negotiation reliable. Section 6
describes these options further.

4.6. Other Differences from TCP

Interesting differences between DCCP and TCP, apart from those
discussed so far, include:

o Copious space for options (up to 1020 bytes).

o Different acknowledgement formats. The CCID for a connection
determines how much ack information needs to be transmitted. In
CCID 2 (TCP-like), this is about one ack per 2 packets, and each
ack must declare exactly which packets were received; in CCID 3
(TFRC), it's about one ack per RTT, and acks must declare at
minimum just the lengths of recent loss intervals.

o Denial-of-service (DoS) protection. Several DCCP mechanisms
attempt to let servers limit the amount of state possibly-
misbehaving clients can force them to maintain. An Init Cookie
option, analogous to TCP's SYN Cookies [SYNCOOKIES], avoids SYN-
flood-like attacks. Only one connection endpoint need hold
TIMEWAIT state; the DCCP-CloseReq packet, which may only be sent
by the server, passes that state to the client. Various rate
limits let servers avoid attacks that might force extensive
computation or packet generation.

o Distinguishing different kinds of loss. A Data Dropped option
(Section 11.7) lets an endpoint declare that a packet was dropped
because of corruption, because of receive buffer overflow, and so
on. This facilitates research into more appropriate rate-control
responses for these non-network-congestion losses (although
currently all losses will cause a congestion response).

o Acknowledgement readiness. In this exchange, TCP, a packet is acknowledged only
when the client requests CCID value 3 or 4 data is queued for delivery to the
server's CCID, with 3 preferred. Note that the client can offer
multiple values. The server chooses 4, giving its preference list of
"4 2".

If application. This
does not make sense in DCCP, where an application might request a party wants to change one of his own options, he issues
drop-from-front receive buffer, for example. We acknowledge a
"Change L", as shown below.

Client Server
------ ------
<- Change L(CCID, 3 2)
Confirm R(CCID, 3, 3 2) ->
* agreement
packet when its options have been processed. The Data Dropped
option may later say that (CCID, Server) = 3 *

In this example, the server requests CCID value 3 or 2 packet's payload was discarded.

o Integrated support for the
server's CCID, with 3 preferred, mobility and multihoming via the client agrees.

Retransmissions make feature negotiation reliable. Section 6.4
describes these options further.

Kohler/Handley/Floyd/Padhye DCCP-Move
packet type.

Kohler/Handley/Floyd Section 4.3. 4.6. [Page 17]

INTERNET-DRAFT Expires: April August 2004 October 2003

4.4. February 2004

o No receive window. DCCP is a congestion control protocol, not a
flow control protocol.

o No simultaneous open. Every connection has one client and one
server.

o No half-closed states. DCCP has no states corresponding to TCP's
FINWAIT and CLOSEWAIT, where one half-connection is explicitly
closed while the other is still active.

4.7. Example Connection

The progress of a typical DCCP connection is as follows. (This
description is informative, not normative.)

Client Server
------ ------
(1)
0. [CLOSED] [LISTEN]
1. DCCP-Request ->
<- (2) -->
2. <-- DCCP-Response
(3) DCCP-Ack ->
(5) DCCP-Data ->
<- (5)
3. DCCP-Ack
<- (5) DCCP-Data
(5) -->
<-- DCCP-Ack ->
<- (6)
4. DCCP-Data, DCCP-Ack, DCCP-DataAck -->
<-- DCCP-Data, DCCP-Ack, DCCP-DataAck
5. <-- DCCP-CloseReq
(7)
6. DCCP-Close ->
<- (8) -->
7. <-- DCCP-Reset

Typical DCCP Connection.

(1)
8. [TIMEWAIT]

1. The client sends the server a DCCP-Request packet specifying the
client and server ports, the service being requested, and any
features being negotiated, including the CCID that the client
would like the server to use. The client may optionally
piggyback some data on the DCCP-Request packet---an application-
level request, say---which the server may ignore.

(2)

2. The server sends the client a DCCP-Response packet indicating
that it is willing to communicate with the client. The response
indicates any features and options that the server agrees to,
begins or continues other feature negotiations if desired, and
optionally includes an Init Cookie that wraps up all this
information and which must be returned by the client for the
connection to complete.

(3)

3. The client sends the server a DCCP-Ack packet that acknowledges
the DCCP-Response packet. This acknowledges the server's
initial sequence number and returns the Init Cookie if there was

Kohler/Handley/Floyd Section 4.7. [Page 18]

INTERNET-DRAFT Expires: August 2004 February 2004

one in the DCCP-Response. It may also continue feature
negotiation.

(4) Next comes There might follow zero or more DCCP-Ack exchanges
as required to finalize feature negotiation. The client may
piggyback an application-level request on its final ack,
producing a DCCP-
DataAck DCCP-DataAck packet.

Kohler/Handley/Floyd/Padhye Section 4.4. [Page 18]

INTERNET-DRAFT Expires: April 2004 October 2003

(5)

4. The server and client then exchange DCCP-Data packets, DCCP-Ack
packets acknowledging that data, and, optionally, DCCP-DataAck
packets containing piggybacked data and acknowledgements. If
the client has no data to send, then the server will send DCCP-
Data and DCCP-DataAck packets, while the client will send DCCP-
Acks exclusively.

(6)

5. The server sends a DCCP-CloseReq packet requesting a close.

(7) The client sends a DCCP-Close packet acknowledging the close.

(8) The server sends a DCCP-Reset packet whose Reason field is set
to "Closed", and clears its connection state. In DCCP, unlike
TCP, Resets are part of normal connection termination; see
Section 5.9.

(9) The client receives the DCCP-Reset packet and holds state for a
reasonable interval of time to allow any remaining packets to
clear the network.

An alternative connection closedown sequence is initiated by the
client:

(6) The client sends a DCCP-Close packet closing the connection.

(7) The server sends a DCCP-Reset packet with Reason field set to
"Closed" and clears its connection state.

(8) The client receives the DCCP-Reset packet and holds state for a
reasonable interval of time to allow any remaining packets to
clear the network.

This arrangement of setup and teardown handshakes permits the server
to decline to hold any state until the handshake with the client has
completed, and ensures that the client must hold the Time-Wait state
at connection closedown.

4.5. Examples of DCCP Congestion Control

Before giving the detailed specifications of DCCP, we present two
more detailed examples showing DCCP congestion control in operation.
Again, these examples are informative, not normative.

4.5.1. DCCP with TCP-like Congestion Control

The first example is of a connection where both half-connections use
TCP-like Congestion Control, specified by CCID 2 [CCID 2 PROFILE].
In this example, the client sends an application-level request to

Kohler/Handley/Floyd/Padhye Section 4.5.1. [Page 19]

INTERNET-DRAFT Expires: April 2004 October 2003

the server, and the server responds with a stream of data packets.
This example is of a connection using ECN.

(1) close.

6. The client sends the DCCP-Request, which includes a Change R
option asking DCCP-Close packet acknowledging the close.

7. The server to use CCID 2 for sends a DCCP-Reset packet with Reset Code 1,
"Closed", and clears its connection state. In DCCP, unlike TCP,
Resets are part of normal connection termination; see Section
5.6.

8. The client receives the server's data
packets, DCCP-Reset packet and holds state for a Change L option informing
reasonable interval of time to allow any remaining packets to
clear the server that network.

An alternative connection closedown sequence is initiated by the
client:

5b. The client would like to use CCID 2 for sends a DCCP-Close packet closing the its data packets.

(2) connection.

6b. The server sends a DCCP-Response, including a Confirm L option
indicating that the server agrees to use CCID 2 for its data
packets, DCCP-Reset packet with Reset Code 1,
"Closed", and a Confirm R option indicating that the server
agrees to the client's suggestion of CCID 2 for the client's
data packets.

(3) clears its connection state.

7b. The client responds with a DCCP-DataAck acknowledging receives the
server's initial sequence number, DCCP-Reset packet and including an application-
level request holds state for data. We will not discuss a
reasonable interval of time to allow any remaining packets to
clear the client-to-
server half-connection further network.

5. Header Formats

The variable-length DCCP header appears first in this example.

(4) every DCCP packet.
A header can be from 12 to 1020 bytes long. The server sends DCCP-Data packets, where initial 12 bytes of
the number header are the same regardless of packets
sent is governed by packet type. Following this
comes optional additional fixed-length fields, depending on the
packet type, and then a congestion window, as in TCP. variable-length list of options. Finally,
some packet types include application data.

Kohler/Handley/Floyd Section 5. [Page 19]

INTERNET-DRAFT Expires: August 2004 February 2004

+---------------------------------------+ -.
| Generic Header | |
+---------------------------------------+ |
| Additional Fields (depending on type) | +- DCCP Header
+---------------------------------------+ |
| Options (optional) | |
+=======================================+ -'
| Application Data (optional) |
+=======================================+

5.1. Generic Header

The details DCCP generic header generally takes 12 bytes.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |X| Res | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Actually, there are two types of generic header, depending on the
value of X, the congestion window are defined in Extended Sequence Numbers bit. If X is zero, the profile for CCID 2,
which
Sequence Number field takes 24 bits, as above. If X is one, the
Sequence Number field extends for an additional 24 bits, for a separate document [CCID total
of 48:

Source and Destination Ports: 16 bits each
These fields identify the number
of server data packets connection, similar to be covered by an Ack packet from the
client.

Each DCCP-Data packet is sent as ECN-Capable, with either the
ECT(0) or the ECT(1) codepoint set, as described
corresponding fields in [ECN NONCE].

(5) TCP and UDP. The client sends a DCCP-Ack packet acknowledging the data
packets for every Ack Ratio data packets transmitted by Source Port represents
the
server. Each DCCP-Ack packet uses a sequence number and
contains an Ack Vector, as defined in Section 8 relevant port on
Acknowledgements. These packets also include Confirm L options
answering any Ack Ratio requests from the server.

The DCCP-Acks are also endpoint that sent as ECN-Capable, with either ECT(0)
or ECT(1). The client's Ack Vector echoes the accumulated ECN
Nonce for the server's packets.

(6) The server must occasionally acknowledge the client's
acknowledgements, so the client can clean its acknowledgement
state. It can do so by sending separate DCCP-Acks as allowed by
CCID 2, or by piggybacking acknowledgement information on its
data packets with this packet, the DCCP-DataAck packet type. The
acknowledgement information may contain detailed Ack Vectors,

Kohler/Handley/Floyd/Padhye

Kohler/Handley/Floyd Section 4.5.1. 5.1. [Page 20]

INTERNET-DRAFT Expires: April August 2004 October 2003

like the client's acknowledgements; but if February 2004

Destination Port the client is sending
nothing but acknowledgements, relevant port on the server's acks-of-acks can other endpoint.
Source Ports SHOULD be
more lightweight. See Section 8.1 for more information.

Like the server's DCCP-Data packets, chosen randomly, to reduce the server's DCCP-DataAck
and DCCP-Ack packets are sent as ECN-Capable.

(7) likelihood
of attack.

Data Offset: 8 bits
The server continues sending DCCP-Data packets as controlled by
the congestion window. Upon receiving DCCP-Ack packets, offset from the
server examines start of the Ack Vector DCCP header to learn about marked or dropped
data packets, and adjusts its congestion window accordingly, as
described the beginning of
the packet's application data, in [CCID 2 PROFILE]. Because this is unreliable
transfer, 32-bit words.

CCVal: 4 bits
Used by the server does not retransmit dropped packets.

(8) Because DCCP-Ack packets use sequence numbers, HC-Sender CCID. For example, the server has
direct A-to-B CCID's
sender, which is active at DCCP A, MAY send 4 bits of
information about per packet to its receiver by encoding that
information in CCVal. CCVal MUST be set to zero unless the fraction HC-
Sender CCID specifies a different value.

Checksum Coverage (CsCov): 4 bits
Checksum Coverage specifies what parts of loss or marked DCCP-Ack
packets. [CCID 2 PROFILE] defines how the server modifies packet are covered
by the
client's Ack Ratio in response to any congestion Checksum field. This always includes the DCCP header and
options, but if applications request it, some or all of the
application data may be excluded. This can improve performance
on noisy links, assuming the
acknowledgement stream.

(9) application can tolerate
corruption. See Section 9.

Checksum: 16 bits
The server estimates round-trip times and calculates Internet checksum of the packet's DCCP header (including
options), a TimeOut
(TO) value much as network-layer pseudoheader, and, depending on
Checksum Coverage, some or all of the RTO (Retransmit Timeout) is calculated in
TCP. Again, application data. See
Section 9.

Type: 4 bits
The Type field specifies the specification for this is in [CCID 2 PROFILE]. type of the packet. The TO following
values are defined:

Type Meaning
---- -------
0 DCCP-Request
1 DCCP-Response
2 DCCP-Data
3 DCCP-Ack
4 DCCP-DataAck
5 DCCP-CloseReq
6 DCCP-Close
7 DCCP-Reset
8 DCCP-Move
9 DCCP-Sync
10 DCCP-SyncAck
11-15 Reserved

Kohler/Handley/Floyd Section 5.1. [Page 21]

INTERNET-DRAFT Expires: August 2004 February 2004

Extended Sequence Numbers (X): 1 bit
This bit is used set to determine when a new DCCP-Data packet can be
transmitted when the server has been limited by one to indicate the congestion
window use of an extended
generic header with 48-bit Sequence and no feedback has been received from the client.

(10) Acknowledgement Numbers.
Very-high-rate connections SHOULD set X to one, and use 48-bit
sequence numbers, to gain increased protection against wrapped
sequence numbers and attacks. See Section 7.6.

Reserved (Res): 3 bits
The DCCP-CloseReq, DCCP-Close, version of DCCP specified here MUST ignore this field on
received packets, and DCCP-Reset packets MUST set it to close all zeroes on generated
packets.

Sequence Number: 24 or 48 bits
Identifies the connection are as packet uniquely in the example above.

4.5.2. DCCP with TFRC Congestion Control

This example is sequence of a connection where both half-connections use TFRC
Congestion Control, specified by CCID 3 [CCID 3 PROFILE].

(1) The DCCP-Request and DCCP-Response all packets specifying the use of
CCID 3 and
the initial DCCP-DataAck source sent on this connection. Sequence Number increases
by one with every packet are similar sent, including packets such as DCCP-
Ack that carry no application data. See Section 7.

Sequence Number Transition (T): 1 bit [X=1 only]
Set to those one to indicate an ongoing transition from 24-bit to
48-bit sequence numbers. See Section 7.6.

Many packet types also carry an Acknowledgement Number in the CCID 2 example above.

(2) four
or eight bytes immediately following the generic header. When X=0,
its format is:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And when X=1:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number (high bits) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Acknowledgement Number (low bits) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Acknowledgement Number: 24 or 48 bits
The server sends DCCP-Data packets, where Acknowledgement Number field generally acknowledges the
greatest valid sequence number received so far on this
connection. ("Greatest" is, of course, measured in circular
sequence space.) Acknowledgement numbers make no attempt to
provide precise information about which packets
sent is governed by an allowed transmit rate, have arrived;
options such as in TFRC. the Ack Vector do this.

Kohler/Handley/Floyd Section 5.1. [Page 22]

INTERNET-DRAFT Expires: August 2004 February 2004

Reserved: 8 bits
The
details version of the allowed transmit rate are defined in the profile
for CCID 3, which is DCCP specified here MUST ignore these fields on
received packets, and MUST set them to all zeroes on generated
packets.

5.2. DCCP-Request Header

A client initiates a separate document [CCID 3 PROFILE]. Each
DCCP-Data packet has DCCP connection by sending a sequence number DCCP-Request
packet.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (12 or 16 bytes) /
/ with Type=0 (DCCP-Request) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options / Padding |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Application Data |
| ... |

Service Code: 32 bits
Describes the service to which the client application wants to
connect. Examples might include RTSP and DOOM. Service Codes
are intended to make application protocols independent of well-
known ports, and help middleboxes identify the protocol used on
a window counter
value.

Kohler/Handley/Floyd/Padhye given connection. See Section 8.1.2.

5.3. DCCP-Response Header

The server responds to valid DCCP-Request packets with DCCP-Response
packets. This is the second phase of the three-way handshake.

Kohler/Handley/Floyd Section 4.5.2. 5.3. [Page 21] 23]

INTERNET-DRAFT Expires: April August 2004 October 2003

Some of these data packets are DCCP-DataAck packets
acknowledging packets from the client, but for simplicity we February 2004

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (12 or 16 bytes) /
/ with Type=1 (DCCP-Response) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number |
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)when
(. Acknowledgement Number (low bits) | Reserved |)X=1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options / Padding |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Application Data |
| ... |

Acknowledgement Number: 24 or 48 bits
The Acknowledgement Number field will not discuss generally equal the half-connection of data
Sequence Number from the client to DCCP-Request.

Service Code: 32 bits
Echoes the server in this example.

The use of ECN follows TCP-like Congestion Control, above, Service Code on the DCCP-Request.

5.4. DCCP-Data, DCCP-Ack, and
is described further in [CCID 3 PROFILE].

(3) DCCP-DataAck Headers

The receiver sends DCCP-Ack packets at least once per round-trip
time acknowledging the central data packets, unless the server is
sending at a rate transfer portion of less than one packet per RTT, as specified
by [CCID 3 PROFILE]. These acknowledgements may be piggybacked
on data packets, producing DCCP-DataAck packets. Each DCCP-Ack
packet every DCCP connection uses a sequence number
DCCP-Data, DCCP-Ack, and identifies the most recent
packet received from the server. Each DCCP-Ack packet includes
feedback about the loss event rate calculated by the client, as
specified by [CCID 3 PROFILE].

(4) The server continues sending DCCP-DataAck packets. DCCP-Data packets as controlled by
the allowed transmit rate. Upon receiving DCCP-Ack packets, the
server updates its allowed transmit rate as specified by [CCID
carry application data.

0 1 2 3
PROFILE].

(5) The server estimates round-trip times and calculates a TimeOut
(TO) value much as the RTO (Retransmit Timeout) is calculated in
TCP. Again, the specification for this is in [CCID
0 1 2 3 PROFILE].

(6) The DCCP-CloseReq, DCCP-Close, and DCCP-Reset 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (12 or 16 bytes) /
/ with Type=2 (DCCP-Data) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options / Padding |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Application Data |
| ... |

DCCP-Ack packets to close dispense with the connection data, but contain an
Acknowledgement Number. They are as in the examples above.

5. Packet Formats

5.1. used for pure acknowledgements.

Kohler/Handley/Floyd Section 5.4. [Page 24]

INTERNET-DRAFT Expires: August 2004 February 2004

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic Packet Header

All DCCP packets begin Header (12 or 16 bytes) /
/ with a generic DCCP packet header: Type=3 (DCCP-Ack) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number |
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)when
(. Acknowledgement Number (low bits) | Reserved |)X=1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options / Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DCCP-DataAck packets carry both application data and an
Acknowledgement Number: acknowledgement information is piggybacked
on a data packet.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (12 or 16 bytes) /
/ with Type=4 (DCCP-DataAck) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Reserved | Dest Port Acknowledgement Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)when
(. Acknowledgement Number (low bits) | Data Offset Reserved |)X=1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CCVal Options / Padding | CsCov
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Checksum Application Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |X|# NDP| Sequence Number ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Kohler/Handley/Floyd/Padhye Section 5.1. [Page 22]

INTERNET-DRAFT Expires: April 2004 October 2003

Source and Destination Ports: 16 bits each
These fields identify the connection, similar to the
corresponding fields in TCP and UDP. The Source Port represents
the relevant port on the endpoint that sent this packet, the
Destination Port the relevant port on the other endpoint.

Data Offset: 8 bits
The offset from the start of the DCCP header to the beginning of
the packet's payload, measured in 32-bit words.

CCVal: 4 bits
This field is reserved for use by the sending CCID. In
particular, the A-to-B CCID's sender, which is active at DCCP A,
MAY send information to the receiver at DCCP B by encoding that
information in CCVal. If the relevant CCID does not specify its
value, it MUST be set to zero.

Checksum Coverage (CsCov): 4 bits
The Checksum Coverage field specifies what parts of the packet
are covered by the Checksum field, as follows:

CsCov = 0
Checksum covers the DCCP header, DCCP options, network-layer
pseudoheader (described below), and the entire DCCP payload,
possibly padded on the right with zeros to an even number of
bytes.

CsCov = 1-15
Checksum covers the DCCP header, DCCP options, network-layer
pseudoheader, and the initial (CsCov-1)*4 bytes of the DCCP
payload.

Thus, if CsCov is 1, none of the DCCP payload is protected by
the header checksum. The value (CsCov-1)*4 MUST be less than or
equal to the length of the DCCP payload. Packets with invalid
CsCov values MUST be ignored; in particular, their options MUST
NOT be processed. The meanings of values other than 0 and 1
should be considered experimental.

Values other than 0 specify that corruption is acceptable in
some or all of the DCCP packet's payload. In fact, DCCP cannot
even detect corruption in areas not covered by the header
checksum, unless the Payload Checksum option is used (Section
8.8). Applications should not make any assumptions about the
correctness of received data not covered by the checksum, and
should if necessary introduce their own appropriate validity
checks.

Kohler/Handley/Floyd/Padhye Section 5.1. [Page 23]

INTERNET-DRAFT Expires: April 2004 October 2003

A DCCP application interface should let sending applications
suggest a value for CsCov for sent packets, defaulting to 0
(full coverage). It should also let receiving applications
refuse delivery of packets with checksum coverage less than a
value provided by the application; by default, only packets with
fully-covered payloads should be accepted. Lower layers that
support partial error detection MAY use the Checksum Coverage
field as a hint of where errors do not need to be detected.
Lower layers MUST use a strong error detection mechanism to
detect at least errors that occur in the sensitive part of the
packet, and discard damaged packets. The sensitive part
consists of the bytes between the first byte of the IP header

DCCP-Data and DCCP-DataAck packets may contain zero application data
bytes if the last byte identified by Checksum Coverage. For more
details on application and lower-layer interface issues relating
to partial checksumming, see [UDP-LITE], from which this text
was summarized.

See Appendix B.1 for further motivation of partial checksums and
discussion of partial checksumming issues. Partial checksums
introduce some security considerations, which are described sends a zero-length datagram. Also, a
DCCP-Ack packet need not have a zero-length application data area.
The receiver MUST ignore any "application data" in
Section 16.2. DCCP partial checksumming was inspired by UDP-Lite
[UDP-LITE].

Checksum: 16 bits
DCCP uses the TCP/IP checksum algorithm. a DCCP-Ack
packet. The Checksum field
equals the 16 bit one's complement sender will not generally send such data, but it may
occasionally do so---to perform PMTU discovery without risking loss
of user data, for example.

DCCP-Ack and DCCP-DataAck packets often include additional
acknowledgement options, such as Ack Vector, as required by the one's complement sum
of all 16 bit words
congestion control mechanism in use.

5.5. DCCP-CloseReq and DCCP-Close Headers

DCCP-CloseReq and DCCP-Close packets begin the DCCP header, DCCP options, handshake that
normally terminates a
pseudoheader taken from the network-layer header, and, depending
on the value of the Checksum Coverage field, some connection. Either client or all of the
payload. When calculating server may send

Kohler/Handley/Floyd Section 5.5. [Page 25]

INTERNET-DRAFT Expires: August 2004 February 2004

a DCCP-Close packet, which will elicit a DCCP-Reset packet (see the checksum,
next section). Only the Checksum field
itself is treated as 0. If server can send a packet contains an odd number of
header and text bytes DCCP-CloseReq packet,
which indicates that the server wants to be checksummed, 8 zero bits are added
on close the right connection, but
does not want to form a hold its TIMEWAIT state.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (12 or 16 bit word for checksum purposes. bytes) /
/ with Type=5 (DCCP-CloseReq) or 6 (DCCP-Close) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number |
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)when
(. Acknowledgement Number (low bits) | Reserved |)X=1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options / Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The
pad byte is not transmitted as part of the receiver MUST ignore any "application data" in a DCCP-CloseReq
or DCCP-Close packet.

The pseudoheader is calculated as

5.6. DCCP-Reset Header

DCCP-Reset packets unconditionally shut down a connection.
Connections normally terminate with a DCCP-Reset, but resets may be
sent for TCP. For IPv4, it is 96
bits long, other reasons, including bad port numbers, bad option
behavior, incorrect ECN Nonce Echoes, and consists of so forth.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (12 or 16 bytes) /
/ with Type=7 (DCCP-Reset) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number |
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)when
(. Acknowledgement Number (low bits) | Reserved |)X=1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reset Code | Data 1 | Data 2 | Data 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options / Padding |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Error Text |
| ... |

Reset Code: 8 bits
Represents the reason that the IPv4 source and destination
addresses, sender reset the IP protocol number for DCCP (padded on the left
with 8 zero bits), connection.

Kohler/Handley/Floyd Section 5.6. [Page 26]

INTERNET-DRAFT Expires: August 2004 February 2004

Data 1, Data 2, and Data 3: 8 bits each
The Data fields provide additional information about why the DCCP length as a 16-bit quantity (the
length of
sender reset the DCCP header with options, plus the length connection. The meanings of any
data); see Section 3.1 these fields
depend on the value of [RFC 793]. For IPv6, it Reason.

Error Text (application data area)
If present, Error Text is 320 bits
long, and consists of the IPv6 source a human-readable text string,
preferably in English and destination addresses, encoded in Unicode UTF-8, that
describes the DCCP length as error in more detail. For example, a 32-bit quantity, and DCCP-Reset
with Reset Code 12, "Aggression Penalty", might contain Error
Text such as "Aggression Penalty: Received 3 bad ECN Nonce
Echoes, assuming misbehavior".

The following Reset Codes are currently defined. The "Data" columns
describe what the IP protocol number Data fields contain for DCCP (padded on a given Code. N/A means
the left with 24 zero bits); see Section 8.1
of [RFC 2460].

Packets with invalid header checksums MUST be ignored. In
particular, their options Data field MUST NOT be processed.

Kohler/Handley/Floyd/Padhye Section 5.1. [Page 24]

INTERNET-DRAFT Expires: April 2004 October 2003

Type: 4 bits
The type field specifies set to 0 by the type sender of the DCCP message. The
following values are defined: DCCP-Reset and
ignored by its receiver.

Reset Section
Code Name Data 1 Data 2 Data 3 Reference
----- ---- ------ ------ ------ ---------
0 DCCP-Request packet. Unspecified N/A N/A N/A
1 DCCP-Response packet. Closed N/A N/A N/A 8.3
2 DCCP-Data packet. Aborted N/A N/A N/A 8.1.1
3 DCCP-Ack packet. No Connection N/A N/A N/A 8.3.1
4 DCCP-DataAck packet. Packet Error packet N/A N/A 8.3.1
type
5 DCCP-CloseReq packet. Option Error option option data
number (if any)
6 DCCP-Close packet. Mandatory Error option option data 5.9.2
number (if any)
7 DCCP-Reset packet. Extended Seqnos N/A N/A N/A 7.6
8 DCCP-Move packet. Connection Refused N/A N/A N/A 8.1.3
9 DCCP-Sync packet.

10-15
Reserved.

Extended Sequence Numbers (X): 1 bit
This bit Bad Service Code N/A N/A N/A 8.1.3
10 Too Busy N/A N/A N/A 8.1.3
11 Bad Init Cookie N/A N/A N/A 8.1.4
12 Aggression Penalty N/A N/A N/A 12.2
13 Move Refused N/A N/A N/A 14.4
13-127 Reserved
128-255 CCID-specific codes ... variable ... 10.4

5.7. DCCP-Move Header

The DCCP-Move packet type is set to one to indicate the use part of an extended
generic header with 48-bit Sequence DCCP's support for multihoming
and Acknowledgement Numbers.
The format mobility, which is described further in the section has X set to zero. Section
5.3 describes the extended generic header.

Number of Non-Data Packets (# NDP): 3 bits 14. DCCP sets this field to the number of non-data packets it has
sent so far on its sequence, modulo 8 A non-data packet is
simply any packet not containing user data; DCCP-Ack, DCCP-
Close, DCCP-CloseReq, and DCCP-Reset are always non-data
packets, while DCCP-Request, DCCP-Response, and DCCP-Move might
or might not be. When sending a non-data packet, DCCP
increments the # NDP counter before storing its value in the
packet header.

This field can help the receiving DCCP decide whether sends
a lost DCCP-Move packet contained any user data. (An application may want to
know when it has lost data. DCCP could report every B after changing its address and/or port
number. The DCCP-Move packet loss
as a potential data loss, but that would cause false loss
reports when non-data packets were lost.) For example, say requests that

Kohler/Handley/Floyd/Padhye DCCP B start sending

Kohler/Handley/Floyd Section 5.1. 5.7. [Page 25] 27]

INTERNET-DRAFT Expires: April August 2004 October 2003

packet 10 had # NDP set February 2004

packets to 5; packet 11 was lost; a new address and packet 12
had # NDP set to 5. Then port number, which are read off the receiving
packet's network header and generic DCCP could deduce that
packet 11 contained data, since # NDP did not change. Likewise,
if # NDP had gone up to 6 (and packet 12 contained user data),
then packet 11 must not have contained any data.

# NDP can overflow, causing ambiguities. For example, if 8
packets header. The old address
and port are dropped in defined through a row but # NDP does not change, the
receiver will not be able to tell whether Mobility ID, which provides some
protection against hijacked connections.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (12 or not any 16 bytes) /
/ with Type=8 (DCCP-Move) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number |
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)when
(. Acknowledgement Number (low bits) | Reserved |)X=1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility ID (high bits) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Mobility ID (bits 64-95) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Mobility ID (bits 32-63) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Mobility ID (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options / Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Mobility ID: 128 bits
The value of the lost
packets contained data. Thus, applications SHOULD NOT depend on receiver's Mobility ID feature. This value
uniquely identifies the availability of unambiguous # NDP information. DCCP itself
uses # NDP only as a hint of when a current connection has left
unidirectional mode; potential ambiguities are not harmful
there.

Sequence Number: 24 bits
The sequence number field is initialized by a DCCP-Request or
DCCP-Response packet, and increases by one (modulo 16777216)
with every packet sent. The receiver uses this information to
determine whether packet losses have occurred. Even packets
containing no data update among the sequence number. Sequence numbers
also provide some protection against old and malicious packets
and half-open connections; see Section 5.2 on sequence number
validity.

The two subflows' initial sequence numbers are set by of
connections terminating at the first
DCCP-Request and DCCP-Response packets sent, and SHOULD be
chosen as for TCP. In particular, initial sequence number
choice MUST include a random or pseudorandom component to make receiver (meaning, the stationary
endpoint); it harder for attackers to complete sequence number attacks [RFC
1948]. MUST have been set in an earlier exchange. See
Section 14.2.

The initial sequence number chosen for receiver MUST ignore any "application data" in a given connection
identifier (source address and port plus destination address DCCP-Move
packet.

5.8. DCCP-Sync and
port) SHOULD increase over time, as TCP suggests [RFC 793], to
prevent inappropriate delivery of old packets.

If the header's X bit equals one, the Sequence Number field
extends for another 24 bits for a total DCCP-SyncAck Headers

DCCP-Sync packets help DCCP endpoints recover synchronization after
bursts of 48. Very-high-rate
connections SHOULD use these extended 48-bit sequence numbers to
protect against wrapped sequence numbers; see loss, or recover from half-open connections. Each valid
DCCP-Sync received immediately elicits a DCCP-SyncAck.

Kohler/Handley/Floyd Section 5.3.

Many packet types also carry an Acknowledgement Number in the four
bytes following the generic header. Its format is as follows: 5.8. [Page 28]

INTERNET-DRAFT Expires: August 2004 February 2004

Kohler/Handley/Floyd/Padhye Section 5.1. [Page 26]

INTERNET-DRAFT Expires: April 2004 October 2003
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)when
(. Acknowledgement Number: 24 bits Number (low bits) | Reserved |)X=1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options / Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Acknowledgement Number field acknowledges on DCCP-Sync and DCCP-SyncAck packets
need not equal the generating endpoint's greatest valid sequence
number received so far (GSR). This differs from Acknowledgement Numbers on this connection. ("Greatest"
is, of course, measured
all other packet types. If a DCCP-Sync was generated in circular response to
a packet with invalid sequence space.) numbers, then the DCCP-Sync's
Acknowledgement numbers make no attempt to provide precise
information about which packets have arrived; options such as Number will equal the Ack Vector do this. invalid packet's sequence
number. The Acknowledgement Number on any DCCP-SyncAck packet MUST
correspond to a "received"
packet, where a packet is classified as "received" if and only
if its options were processed by received, valid DCCP-Sync's Sequence Number; in the receiving DCCP. (This
means, for example, that received packets must be both header-
checksum-valid and sequence-valid.) Even "received" packets may
have their payloads dropped, due to receive buffer overflow or
payload corruption, for instance. The HC-Receiver will send
Data Dropped options when
presence of reordering, this happens (see Section 8.7); the
HC-Sender will reduce its sending rate or congestion window as
appropriate. This issue is discussed further might not equal GSR.

The receiver MUST ignore any "application data" in Sections 8.5
and 8.7.

If a DCCP-Sync or
DCCP-SyncAck packet.

5.9. Options

All DCCP packets may contain options, which occupy space at the header's X bit equals one, end
of the Acknowledgement Number
field extends for another 24 bits for DCCP header. Each option is a total multiple of 48. Again, see
Section 5.3.

Reserved: 8 bits in length.
The version combination of DCCP specified here MUST ignore this field on
received packets, and MUST set it to all zeroes on generated
packets.

5.2. Sequence Number Synchronization

DCCP implementations must react options MUST add up to packets that a multiple of 32 bits.
Individual options are not intended for
the current connection. This can happen if the network delivers an
old packet, if an attacker attempts padded to hijack a connection, during
the cleanup multiples of a half-open connection, or for other reasons. DCCP,
like TCP, uses sequence number checks and Reset packets to defend
against these packets. Every DCCP packet sent uses a new sequence
number, 32 bits, however; thus, given large enough bursts
any option may begin on any byte boundary. All options are always
included in the checksum.

The first byte of loss, an option is the option type. Options with types
0 through 31 are single-byte options. Other options are followed by
a
connection's endpoints might get out byte indicating the option's length. This length value includes
the two bytes of sync relative to option-type and option-length as well as any window,
requiring a mechanism
option-data bytes, and must therefore be greater than or equal to restore synchronization. This section
describes the algorithms that determine when DCCP packets
two.

Options are
intended for the current connection, and processed sequentially, starting at the actions taken on
unintended packets.

5.2.1. Variables

DCCP sequence number synchronization depends on first option in
the packet header.

The following
variables, which options are maintained by each endpoint.

Kohler/Handley/Floyd/Padhye currently defined:

Kohler/Handley/Floyd Section 5.2.1. 5.9. [Page 27] 29]

INTERNET-DRAFT Expires: April August 2004 October 2003

GSS The Greatest Sequence Number Sent by this endpoint so far.
("Greatest" is of course measured in circular sequence space.)

GSR The Greatest Sequence Number Received from the other endpoint so
far.

GAR (Optional) The Greatest Acknowledgement Number Received from the
other endpoint so far.

Some other variables are derived from these primitives.

SWL and SWR
(Sequence Number Window Left and Right) The February 2004

Option Section
Type Length Meaning Reference
---- ------ ------- ---------
0 1 Padding 5.9.1
1 1 Mandatory 5.9.2
2 1 Slow Receiver 11.6
3-31 1 Reserved
32 variable Change L 6.1
33 variable Confirm L 6.2
34 variable Change R 6.1
35 variable Confirm R 6.2
36 variable Init Cookie 8.1.4
37 4-5 NDP Count 7.7
38 variable Ack Vector [Nonce 0] 11.4
39 variable Ack Vector [Nonce 1] 11.4
40 variable Data Dropped 11.7
41 6 Timestamp 13.1
42 6-10 Timestamp Echo 13.3
43 4-6 Elapsed Time 13.2
44 4 Data Checksum 9.3
45-127 variable Reserved
128-255 variable CCID-specific options 10.4

This section describes two endpoints of
the window within which Sequence Numbers are appropriate.

AWL and AWR
(Acknowledgement Number Window Left generic options, Padding and Right) The two
endpoints of the window within which Acknowledgement Numbers Mandatory.
Other options are
appropriate.

5.2.2. Appropriate Sequence Numbers

A sequence number S is appropriate iff SWL <= S <= SWR in circular
sequence space. This resembles TCP's receive window. However, in
DCCP, sequence numbers change described later.

5.9.1. Padding Option

The Padding option, with each packet sent, even pure
acknowledgements. Thus, type 0, is a loss event that dropped many consecutive
packets could cause two DCCPs single byte option used to get out pad
between or after options. It either ensures the application data
begins on a 32-bit boundary (as required), or ensures alignment of sync relative to any
window, and
following options (not mandatory).

+--------+
|00000000|
+--------+
Type=0

5.9.2. Mandatory Option

The Mandatory option, with type 1, is a packet beyond single byte option that
indicates that the window immediately following option is mandatory. If
the receiving DCCP does not necessarily a hard
error. DCCP-Sync packets help in this situation. understand that following option, it
MUST reset the connection, generally using Reset Code 6, "Mandatory
Failure". For instance, say DCCP A sets SWL and SWR to receives a loss window of W consecutive sequence
numbers containing GSR. ("Consecutive", like "greatest", is
measured in circular sequence space.) One-third of the loss window,
rounded down, is placed at and before GSR, packet with two-thirds after
GSR. Sequence numbers outside this loss window are inappropriate.

During connection startup, two
options: a Mandatory option, and immediately following, another
option O. Then DCCP A MUST adjust SWL so that would reset the connection if it is did not
less than DCCP B's initial sequence number.

DCCP B informs

Kohler/Handley/Floyd Section 5.9.2. [Page 30]

INTERNET-DRAFT Expires: August 2004 February 2004

understand O's type; if it understood O's type, but not O's data; if
O's data was invalid for O's type; if O was a feature negotiation
option, and DCCP A of W, did not understand the loss window width enclosed feature number;
if DCCP A should use,
via the Loss Window feature (Section 6.10). W defaults to 1000, understood O, but

Kohler/Handley/Floyd/Padhye chose not to perform the action O
implies; and so forth. Section 5.2.2. [Page 28]

INTERNET-DRAFT Expires: April 2004 October 2003

a proper value should reflect how many packets 6.6.8 describes the sender expects to
be behavior of
Mandatory feature negotiation options in flight. Only more detail.

+--------+
|00000001|
+--------+
Type=1

6. Feature Negotiation

Four DCCP options, Change L, Confirm L, Change R, and Confirm R,
implement in-band feature negotiation. Change options initiate a
negotiation; Confirm options complete that negotiation. The "L"
options are sent by the sender can anticipate this number. Too-
small values increase feature location, and the risk of "R" options are
sent by the endpoints getting out sync
after bursts of loss; too-large values increase feature remote. Change options are retransmitted to
ensure reliability.

All these options have the risk same format. The first byte of
connection hijacking. One good guideline option
data is to set it to about 3 or
4 times the maximum number of packets feature number, and the sender expects to send second and subsequent data bytes
hold one or more feature values. The feature values are generally
arranged in a round-trip time. This value may not be available at connection
initiation, when linear preference list, where the round-trip time first value is unknown, but most
preferred.

+--------+--------+--------+--------+--------
| Type | Length |Feature#| Value(s) ...
+--------+--------+--------+--------+--------

Together, the sender can
always send updates as feature number and the connection progresses.

5.2.3. Appropriate Acknowledgement Numbers option type ("L" or "R")
uniquely identify the feature to which an option applies. The Acknowledgement Number exact
format of the Value(s) area depends on a packet from DCCP B is appropriate
iff it lies within the window [AWL, AWR], where AWR = GSS, feature number.

6.1. Change Options

Change L and the
window is W' packets wide. W' is the value of DCCP A's Loss Window
feature, which it defined in its role as HC-Sender Change R options initiate feature negotiation. Either
endpoint can start a negotiation for the other
half-connection.

During connection startup, any feature; if DCCP A MUST adjust AWL so that wants to
start a negotiation for feature F/A, it is not
less than its initial sequence number.

5.2.4. Sequence-Validity By State

A packet is called sequence-valid when its sequence numbers indicate
that will send a Change L option,
while to start a negotiation for F/B, it will send a Change R
option. Change options are retransmitted until some response is intended for the current connection.
received. Normal Change options contain at least one Value, and
thus have length at least 4.

Kohler/Handley/Floyd Section 6.1. [Page 31]

INTERNET-DRAFT Expires: August 2004 February 2004

+--------+--------+--------+--------+--------
Change L: |00100000| Length |Feature#| Value(s) ...
+--------+--------+--------+--------+--------
Type=32

+--------+--------+--------+--------+--------
Change R: |00100010| Length |Feature#| Value(s) ...
+--------+--------+--------+--------+--------
Type=34

The rules for
sequence-validity depend on the state of endpoint may check a feature's current value without attempting
to change it by sending an empty Change option, containing just the connection.
feature number. Such options have length 3. The
baseline rules for sequence-validity endpoints must
agree on feature values anyway, so these options are useful in
practice only in special situations, such as follows:

CLOSED when a middlebox
introduced in the middle of a connection wants to check a feature
value.

6.2. Confirm Options

Confirm L and Confirm R options complete feature negotiation, and LISTEN states
All packets
are sequence-valid (but most packet types will cause
a Reset sent in response to Change R and Change L options, respectively.
Confirm options MUST NOT be generated except in response to Change
options. Confirm options need not be retransmitted, since Change
options are retransmitted as necessary. Normal Confirm options
contain the selected Value, possibly followed by later validity checks).

REQUEST state
A packet is sequence-valid if and only if the sender's
preference list.

+--------+--------+--------+--------+--------
Confirm L: |00100001| Length |Feature#| Value(s) ...
+--------+--------+--------+--------+--------
Type=33

+--------+--------+--------+--------+--------
Confirm R: |00100011| Length |Feature#| Value(s) ...
+--------+--------+--------+--------+--------
Type=35

If an endpoint receives an invalid Change option -- with an unknown
feature number, or an invalid value -- it has will respond with an appropriate
Acknowledgement Number.

All other states

(1) DCCP-Data packets empty
Confirm option containing no value. Such options have length 3.

6.3. Reconciliation Rules

Reconciliation rules determine how the two sets of preferences for a
given feature are sequence-valid if and resolved into a unique result. The reconciliation
rule depends only if their
Sequence Numbers are appropriate.

Kohler/Handley/Floyd/Padhye on the feature number. Each reconciliation rule
must have the property that the result is uniquely determined given

Kohler/Handley/Floyd Section 5.2.4. 6.3. [Page 29] 32]

INTERNET-DRAFT Expires: April August 2004 October 2003

(2) DCCP-Sync and DCCP-Reset packets are sequence-valid if and
only if their Acknowledgement Numbers are appropriate.

(3) The sequence-validity February 2004

the contents of DCCP-Move packets is discussed in
Section 5.10.

(4) Change options sent by the two endpoints.

All other packets are sequence-valid if and only if both
their Sequence and Acknowledgement Numbers are appropriate. current DCCP implementations MAY implement additional checks to protect
against packets that have valid sequence numbers, but are not part features use one of this connection. two reconciliation rules,
server-priority ("SP") and non-negotiable ("NN").

6.3.1. Server-Priority

The additional checks provide an incremental
security advantage at feature value is a moderate complexity cost.

o DCCP-Reset packets may not have valid Sequence Numbers because
they might be generated fixed-length byte string (length determined
by the feature number). Each Change option contains a closed connection preference
list of values, with the most preferred value coming first. Each
Confirm option contains the confirmed value, followed by the
confirmer's preference list. Thus, the feature's current value will
generally appear twice in response to
DCCP-Data packets, which have no Acknowledgement Number. However,
DCCP implementations MUST supply a valid Sequence Number when one
is available (either from connection information or Confirm options' data, once as the
Acknowledgement Number), current
value and use Sequence Number 0 otherwise.
Thus, valid DCCP-Reset packets fall into two categories: Either
they once in the confirmer's preference list. Even responses
to empty Change options contain an appropriate Sequence Number, or they have Sequence
Number 0 the whole preference list.

To reconcile the preference lists, select the first entry in the
server's list that also occurs in the client's list. If there is no
shared entry, the feature's value MUST NOT change, and the Confirm
option will confirm the feature's previous value (unless the Change
option was Mandatory; see Section 6.6.8).

DCCP endpoints need not calculate their Acknowledgement Number corresponds to value preference lists
before feature negotiation begins. Thus, a DCCP-
Request or DCCP-Data packet. Implementations that check this
invariant MUST ignore DCCP-Resets that don't fit. (Do not, server might adjust its
preference list based on the client's preference list, assuming the
client opened the negotiation. Once a negotiation for
example, send a DCCP-Sync in response to such feature has
begun, however, the preference lists MUST remain stable until the
negotiation has closed.

6.3.2. Non-Negotiable

The feature value is a Reset.)

o DCCP implementations transition to CLOSED state after sending byte string. Each option contains exactly
one feature value. The feature location signals a
DCCP-Reset packet, and will not send further non-Reset packets on
that connection. Therefore, value change by
sending Change L options. The feature remote MUST accept any valid DCCP-Reset packets have
Sequence Numbers greater than GSR (except for those
value, responding with Sequence
Number 0, as mentioned above), a Confirm R option containing the new value,
and Acknowledgement Numbers greater
than or equal to GAR. Again, implementations that check this
invariant it MUST ignore DCCP-Resets that don't fit.

o Implementations that can detect duplicate sequence numbers within
the current Loss Window should ignore duplicate packets. (Of
course, sequence number space can wrap; this refers send empty Confirm R options in response to packets
whose sequence numbers have recently been seen.)

o DCCP-Sync packets with Sequence Number less than GSR, or with
Acknowledgement Number less than GAR, are stale invalid
values. Non-negotiable features aren't really negotiated; they use
feature negotiation as a mechanism for achieving reliability.
Change R and Confirm L options MUST NOT be
ignored when detected.

Implementing these checks should not cause interoperability
problems, but augmenting sent for non-negotiable
features.

6.4. Feature Numbers

This document defines the list with additional ad-hoc checks is
NOT RECOMMENDED.

Kohler/Handley/Floyd/Padhye following feature numbers.

Kohler/Handley/Floyd Section 5.2.4. 6.4. [Page 30] 33]

INTERNET-DRAFT Expires: April August 2004 October 2003

5.2.5. Handling Sequence-Invalid Packets

Sequence-invalid DCCP-Move, DCCP-Reset, and DCCP-Sync packets MUST
be ignored.

Otherwise, on receiving a sequence-invalid packet, a DCCP endpoint
(say DCCP A) MUST reply with a DCCP-Sync packet, as allowed by the
congestion control mechanism in use. This packet MUST acknowledge
the packet's Sequence February 2004

Rec'n Initial Section
Number (not GSR!). Any DCCP-Sync MUST use a
new Meaning Rule Value Req'd Reference
------ ------- ----- ----- ----- ---------
0 Reserved
1 Congestion Control ID (CCID) SP 2 Y 10
2 ECN Capable SP 1 Y 12.1
3 Sequence Number, Window NN 100 Y 7.5.4
4 Sequence Transition Capable SP 0 N 7.6.4
5 Mobility Capable SP 0 N 14.1
6 Mobility ID NN 0 N 14.2
7 Ack Ratio NN 2 N 11.3
8 Send Ack Vector SP 0 N 11.5
9 Send NDP Count SP 0 N 7.7.2
10 Check Data Checksum SP 0 N 9.3.1
11-127 Reserved
128-255 CCID-specific features ? ? ? 10.4

Rec'n Rule The reconciliation rule used for the feature. SP is
server-priority and thus will increase GSS; GSR will not
change, however, since NN is non-negotiable.

Initial Value The initial value for the packet was sequence-invalid. feature. Every feature has
a known initial value.

Req'd This column is "Y" iff every DCCP A implementation MUST
NOT otherwise process sequence-invalid packets.

On receiving
understand the DCCP-Sync, DCCP B will update its GSR variable and
reply with a DCCP-Sync of its own. When DCCP A receives this DCCP-
Sync, which acknowledges its DCCP-Sync (and is therefore sequence-
valid), feature. If it will update its GSR variable, thus getting the endpoints
back into sync. Alternatively, if is "N", then the connection was half-open,
DCCP B will send a Reset.

To protect itself against denial-of-service attacks (where
feature behaves like an
attacker sends purposefully invalid packets, thereby forcing the
receiver extension (see Section 16),
and it is safe to send DCCP-Syncs), a DCCP implementation MAY ignore
packets respond to Change options for the
feature with inappropriate Sequence Numbers if empty Confirm options. Of course, a
CCID might require the connection is
still active. By "ignore", we mean feature; a DCCP that
implements CCID 2 MUST support Ack Ratio and Send Ack
Vector, for example.

6.5. Examples
Here are three example feature negotiations for features located at
the packet is discarded
without sending a DCCP-Sync. A connection is "active" when
appropriate Sequence Numbers have been recently received; "recently"
might mean within server, the last second or first two for the Congestion Control ID feature, the
last RTT, whichever for the Ack Ratio:

Client Server
1. Change R(CCID, 2 3 1) -->
("2 3 1" is client's value preference list)
2. <-- Confirm L(CCID, 3, 3 2 1)
(3 is
shorter.

Similarly, a DCCP MAY rate-limit the DCCP-Syncs sent in response to
sequence-invalid packets.

5.2.6. Examples

In this first example, DCCP A and DCCP B recover from a large burst
of loss negotiated value;
"3 2 1" is server's pref list)
* agreement that runs DCCP A's sequence numbers out of DCCP B's
appropriate sequence number window.

Kohler/Handley/Floyd/Padhye CCID/Server = 3 *

Kohler/Handley/Floyd Section 5.2.6. 6.5. [Page 31] 34]

INTERNET-DRAFT Expires: April August 2004 October 2003

Recovery from Burst of Loss
DCCP A DCCP B
(GSS=1,GSR=10) (GSS=10,GSR=1)
---> DCCP-Data(seq 2) XXX
...
---> DCCP-Data(seq 100) February 2004

1. XXX
---> DCCP-Data(seq 101) ---> ???
seqno out of range;
send Sync
OK <--- DCCP-Sync(seq 11, ack 101) <---
(GSS=11,GSR=1)
---> DCCP-Sync(seq 102, ack 11) ---> OK
(GSS=102,GSR=11) (GSS=11,GSR=102)

In this example, a DCCP connection recovers from <-- Change L(CCID, 3 2 1)
2. Retransmission:
<-- Change L(CCID, 3 2 1)
3. Confirm R(CCID, 3, 2 3 1) -->
* agreement that CCID/Server = 3 *

1. <-- Change L(Ack Ratio, 3)
2. Confirm R(Ack Ratio, 3) -->
* agreement that Ack Ratio/Server = 3 *

This example shows a simple attack.
The attacker cannot guess sequence numbers. (DCCP simultaneous negotiation.

Client Server
1a. Change R(CCID, 2 3 1) -->
b. <-- Change L(CCID, 3 2 1)
(both endpoints in CHANGING)
2a. <-- Confirm L(CCID, 3, 3 2 1)
b. Confirm R(CCID, 3, 2 3 1) -->
(both endpoints in STABLE)
* agreement that CCID/Server = 3 *

Example Change and Confirm options follow, with their byte
encodings. Each option is not robust to
attackers who can guess sequence numbers.)

Recovery from Attack
DCCP A sent by DCCP B
(GSS=1,GSR=10) (GSS=10,GSR=1)
*ATTACKER* ---> DCCP-Data(seq 10^6) ---> ???
seqno out of range;
send Sync
??? <--- DCCP-Sync(seq 11, ack 10^6) <---
ackno out of range; ignore
(GSS=1,GSR=10) (GSS=11,GSR=1)

The final example demonstrates recovery from a half-open connection.

Recovery from A.

Change L(CCID, 2 3) = 32,5,1,2,3
I want to change CCID/A's value (feature number 1, a Half-Open Connection
DCCP A DCCP B
(GSS=1,GSR=10) (GSS=10,GSR=1)
(Crash)
CLOSED OPEN
REQUEST ---> DCCP-Request(seq 400) ---> ???
!! <--- DCCP-Sync(seq 11, ack 400) <--- OPEN
REQUEST ---> DCCP-Reset(seq 401, ack 11) ---> (Abort)
REQUEST CLOSED
REQUEST ---> DCCP-Request(seq 402) ---> ...

5.3. Extended Sequence Numbers

A 10 Gb/s flow of 1500-byte DCCP packets will send 2^24 packets server-
priority feature); my preferred values are 2 and 3, in
about 20 seconds. This is that
preference order.

Change L(Sequence Window, 1024) = 32,6,3,0,4,0
Change Sequence Window/A's value (feature number 3, a long time, non-
negotiable feature) to the 3-byte string 0,4,0 (the value 1024).

Empty Change L(CCID) = 32,3,1
Tell me CCID/A's value using a Confirm R option.

Confirm L(CCID, 2, 2 3) = 33,6,1,2,2,3
I've changed CCID/A's value to 2; my preferred values are 2 and
3, in that preference order.

Empty Confirm L(126) = 33,3,126
I don't implement feature number 126, or your proposed value for
feature 126/A was invalid.

Change R(CCID, 3 2) = 34,5,1,3,2
Please change CCID/B's value; my preferred values are 3 and 2,
in terms of likely round-

Kohler/Handley/Floyd/Padhye that preference order.

Kohler/Handley/Floyd Section 5.3. 6.5. [Page 32] 35]

INTERNET-DRAFT Expires: April August 2004 October 2003

trip times February 2004

Empty Change R(CCID) = 34,3,1
Tell me CCID/B's value using a Confirm L option.

Confirm R(CCID, 2, 3 2) = 35,6,1,2,3,2
I've changed CCID/B's value to 2; my preferred values were 3 and
2, in that could possibly achieve such preference order.

Confirm R(Sequence Window, 1024) = 35,6,3,0,4,0
I've changed Sequence Window/B's value to the 3-byte string
0,4,0 (the value 1024).

Empty Confirm R(126) = 35,3,126
I don't implement feature number 126, or your proposed value for
feature 126/B was invalid.

6.6. Option Exchange

A few basic rules govern feature negotiation option exchange.

1. Every non-reordered Change option gets a sustained rate, but it Confirm option in
response.

2. Change options are retransmitted until some response is not without risk. DCCP's current congestion control mechanisms
received.

3. Preference lists don't change during a negotiation.

4. Feature negotiation options are designed for congestion windows (or equivalents) processed in strictly increasing
order by Sequence Number.

The rest of at most a
few hundred thousand packets, leaving at least 32 RTTs before 24-bit
sequence numbers wrap. However, very-high rate connections SHOULD
use extended sequence numbers to gain this section describes the consequences of these rules
in more protection.

DCCP extended sequence numbers detail.

6.6.1. Normal Exchange

Change options are activated generated when the header's X bit
is set to one. This extends the Sequence Number and Acknowledgement
Number fields by an additional 24 bits, for a total of 48 bits. A
flow of 1500-byte DCCP packets would have to send more than 28
petabits per second endpoint wants to overflow 48-bit sequence numbers within change
the
2-minute maximum segment lifetime. The 48-bit numbers are stored in
network order, with most significant bit first.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|# NDP| Sequence Number (high bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (low bits) | Reserved |T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

All packet types except for DCCP-Data and DCCP-Request will follow value of some feature. Generally, this generic header with an extended Acknowledgement Number:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number (high bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgement Number (low bits) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Once an endpoint has sent any packet with 48-bit sequence numbers
(X=1), will happen at the
beginning of a connection, although it MUST send all succeeding packets with 48-bit sequence
numbers. Furthermore, once an endpoint has received may happen at any packet with
48-bit sequence numbers, it MUST either send all succeeding packets
with 48-bit sequence numbers, time. We
say the endpoint "generates" or reset "sends" a Change L or Change R
option; but, of course, the connection with Reason
set option must be attached to "Extended Sequence Numbers" (15).

Clients SHOULD decide whether a packet.
The endpoint may attach the option to use extended sequence numbers
before sending their DCCP-Requests. That is, connections SHOULD NOT
transition from 24-bit a packet it would have
generated anyway (such as a DCCP-Request), or it may create a new
packet just to 48-bit sequence numbers; they SHOULD
contain only 24-bit sequence numbers, carry the options (often a DCCP-Sync). If it does
create a new packet, it MUST NOT create more than one such packet
per round-trip time (or 0.2 seconds, if no RTT is available).

On receiving a Change L or only 48-bit sequence

Kohler/Handley/Floyd/Padhye Change R option, a DCCP endpoint examines
the included preference list, reconciles that with its own

Kohler/Handley/Floyd Section 5.3. 6.6.1. [Page 33] 36]

INTERNET-DRAFT Expires: April August 2004 October 2003

numbers. The Transition bit (T) supports transitioning to extended
sequence numbers during an active connection, however, in case this
proves necessary; see below.

Extended sequence numbers are treated simply as longer sequence
numbers. For instance, the sequence-validity mechanisms work February 2004

preference list, calculates the
same way whether new value, and sends back a
Confirm R or not sequence numbers are extended. Care Confirm L option, respectively, informing its partner
of the new value. The rule for reconciling the two preference lists
is
required when comparing feature-specific; see Section 6.3. Every non-reordered Change
option MUST result in a 24-bit sequence number with corresponding Confirm option. Any packet
including a Confirm option MUST carry an 48-bit
sequence number; see below.

Extended sequence numbers improve security against attackers by
making it harder Acknowledgement Number;
thus, Confirm options are not allowed on DCCP-Request and DCCP-Data
packets. Again, generated Confirm options may be attached to guess
packets that would have been sent anyway (such as DCCP-Response or
DCCP-SyncAck), or to new packets (usually DCCP-Ack).

The Change-sending endpoint MUST wait to receive a valid sequence number, corresponding
Confirm option before changing its stored feature value. The
Confirm-sending endpoint changes its stored feature value as well soon as
protecting against benign wrapping.

5.3.1. Transitioning
it sends the Confirm.

DCCP endpoints effectively exist in one of two states, STABLE and
CHANGING, relative to Extended Sequence Numbers

The Transition bit (T) following each feature. STABLE is the extended Sequence Number field
makes normal state,
where the endpoint knows the feature's value and thinks the other
endpoint agrees. An endpoint enters the CHANGING state when it possible to transition
first sends a Change for the feature, and returns to 48-bit sequence numbers in STABLE once it
receives a corresponding Confirm.

6.6.2. Loss and Retransmission

Packets containing Change and Confirm options might be lost or
delayed by the
middle of network. Therefore, Change options are retransmitted
to achieve reliability.

A CHANGING endpoint retransmits a connection. T Change option once it realizes
that it has not heard back from the other endpoint. Each
retransmitted Change option MUST contain exactly the same payload as
the original. The endpoint may piggyback its Change options on
packets it would have sent anyway. If it generates new packets for
feature negotiation, it MUST use an exponential-backoff timer. The
timer's initial value is set to approximately one only during such a
transition. When DCCP or two round-trip
times (or 0.2-0.4 seconds, if no RTT is available), and it is pinned
at roughly 32 RTTs.

A switches CHANGING endpoint MUST continue retransmitting Change options
until it gets some response. Its only recourse is to 48-bit sequence numbers, reset the
connection, which it SHOULD NOT do until at least 12 transmissions
have failed.

Change options SHOULD NOT be transmitted more frequently than once
per RTT, or the reordering protection below would prevent any
Confirm option from being accepted (since no Confirm would
acknowledge the most recently transmitted Change).

Kohler/Handley/Floyd Section 6.6.2. [Page 37]

INTERNET-DRAFT Expires: August 2004 February 2004

Confirm options are never retransmitted, but the Confirm-sending
endpoint MUST generate a new Confirm option for every non-reordered
Change it receives.

6.6.3. Reordering

Reordering might cause packets containing Change and Confirm options
to arrive in an unexpected order. Endpoints MUST set the T bit be robust to one on all of its packets for some period.
This period SHOULD last on the
reordering, by ignoring feature negotiation options that do not
arrive in strictly-increasing order of a few round trip times, or
until DCCP A receives by Sequence Number.

The most straightforward way to implement this requirement is for an acknowledgement from DCCP B proving that
one of its 48-bit-sequence-number packets has been received,
whichever comes later.

Each DCCP MUST choose its first 48-bit sequence number
endpoint to have its
lower 24 bits equal the 24-bit associate two sequence number it expected to send
(GSS+1). If DCCP A sends an extended variables with every
feature F/X, as follows.

F/X.GSR The Greatest Sequence Number Received from the other
endpoint on a packet containing an
Acknowledgement Number before DCCP B sends it a 48-bit Sequence
Number, DCCP A may send any value Change or Confirm option
for the upper 24 bits of that
Acknowledgement Number, but the lower 24 bits MUST equal the
expected 24-bit Acknowledgement feature F/X.

F/X.GSS The Greatest Sequence Number (GSR). Furthermore, DCCP A
MUST leave GSR as Sent by this endpoint on a 24-bit number until receiving an extended
packet
from DCCP B. If containing a Change option for feature F/X.

Then DCCP B transitions A will check options relating to extended sequence numbers
because it receives a valid feature F/A as follows:

1. Ignore any received Change R(F) option whose packet's Sequence
Number is not greater than F/A.GSR.

2. Ignore any received Confirm R(F) option whose packet's Sequence
Number is not greater than F/A.GSR, or whose packet with extended sequence numbers,
it MAY set the upper 24 bits of its extended sequence number based
on the upper 24 bits of could not
have acknowledged F/A.GSS. Specifically, if the received Acknowledgement Number, but it
can also choose a different upper 24 bits.

Switching to 48-bit sequence numbers in
Number is less than F/A.GSS, the middle of a connection
raises endpoint MUST ignore the issue of comparing a 24-bit sequence number with a 48-bit
sequence number. (This may also occur
Confirm; and if the network delivers a packet from has an old connection, or given a malicious attacker.) Let
P be Ack Vector indicating that
F/A.GSS was not received, the packet sequence number received from DCCP B, and E be endpoint MAY ignore the
sequence number DCCP Confirm.

A expects. During sequence-validity
computations, for example, P might similar procedure applies options relating to feature F/B, namely
Change L(F) and Confirm L(F), except that F/B.GSR and F/B.GSS are
checked.

A less state-intensive way to implement this requirement would be to
share the packet's Acknowledgement
Number F.GSR and E might be AWL, F.GSS variables among all features, rather than
keeping one pair per feature. Then the left edge of feature negotiation options
on any received packet would be treated as a unit (either all
accepted or all rejected).

Checking Confirm options is easier if the appropriate

Kohler/Handley/Floyd/Padhye endpoint only sends Change
options on packet types that will be acknowledged immediately,
namely DCCP-Request, DCCP-Response, and DCCP-Sync. Then there is
never any need to check Ack Vectors, although checking Ack Vectors

Kohler/Handley/Floyd Section 5.3.1. 6.6.3. [Page 34] 38]

INTERNET-DRAFT Expires: April 2004 October 2003

acknowledgement number window. Then DCCP A should perform the
comparison as follows.

o If P and E are both 24 bits, compare them modulo 2^24.

o If P and E are both 48 bits, August 2004 February 2004

is NOT MANDATORY anyway.

6.6.4. Preference Changes

Endpoints MUST NOT change their preference lists in the packet's Transition bit middle of a
negotiation. This is set, because, if a preference list changed in the
middle of a negotiation and the last packet sent by DCCP A right packets were lost, the
negotiation could terminate with the endpoints thinking the feature
had different values. In particular, an endpoint MUST NOT change
its Transition bit set,
then compare P and E modulo 2^24. This covers preference list while in the case where both CHANGING state; this ensures that
every Change option sent during that negotiation will contain the
same data.

6.6.5. Simultaneous Negotiation

The two endpoints transitioned simultaneously, so P and E's upper 24 bits might disagree.

o Otherwise, if P and E are both 48 bits, compare them modulo 2^48.

o If P is 48 bits but E is 24, simultaneously open negotiation for the remote DCCP may want to
transition same
feature, after which an endpoint in the CHANGING state will receive
a Change option for the same feature. Such received Change options
can act as responses to extended sequence numbers. If the packet's
Transition bit is not set, original Change options. The CHANGING
endpoint MUST examine the packet is definitely sequence-
invalid; otherwise, compare P received Change's preference list,
reconcile that with E modulo 2^24. If its own preference list (as expressed in its
generated Change options), and generate the packet
proves sequence-valid, corresponding Confirm
option. It can then it is OK; transition to extended
sequence numbers, and set E according to the full 48 bits of P.
If the packet does not prove sequence-valid, send an (extended)
DCCP-Sync as required (with T set STABLE state.

6.6.6. Unknown Features

An endpoint may receive a Change option referring to one), but do some feature
number it does not yet
transition understand. This is particularly likely to
happen when an extended sequence numbers.

o If P is 24 bits but E is 48, there may have been benign packet
reordering. DCCP converses with a non-extended DCCP.
The correct action depends on whether the last packet
seen from receiving endpoint MUST respond to such Change options with
corresponding empty Confirm options (that is, Confirm options
containing no data), which inform the remote DCCP had CHANGING endpoint that the Transition bit set.

o If Transition
feature was not set, then understood. However, if the packet is sequence-invalid;
send an (extended) DCCP-Sync as required.

o If Transition Change option was set, extend P to
preceded by a 48-bit value P'. First,
let EH equal Mandatory option, the upper 24 bits of E, and EL equal connection MUST be reset; see
Section 6.6.8.

On receiving an empty Confirm option for some feature, the lower 24
bits of E. Then:

If EL > P, set P' = (EH << 24) | P.
Otherwise, set P' = (((EH - 1) mod 2^24) << 24) | P.

If CHANGING
endpoint MUST transition back to the packet proves sequence-valid when comparing with P'
modulo 2^48, then it is OK; STABLE state, leaving the packet was reordered from before
feature's value unchanged. Section 16 suggests that the transition. If it does not, default
value for any extension feature should correspond to "extension not
available".

An endpoint will also send an (extended) DCCP-Sync
(with T set to one) as required.

DCCP implementations can, of course, avoid most of this complexity
by disallowing transitions to extended sequence numbers (and by
resetting the connection empty Confirm option when it
understood the other endpoint attempts such a
transition). Connections that use 48-bit sequence numbers
throughout, starting with Change's feature number, but considered the DCCP-Request, MUST have T set to zero
on all their packets.

Kohler/Handley/Floyd/Padhye Change's
value invalid or inappropriate for the feature. The next section
describes this further.

Kohler/Handley/Floyd Section 5.3.1. 6.6.6. [Page 35] 39]

INTERNET-DRAFT Expires: April August 2004 October 2003

5.4. DCCP State Diagram

In this section we present a DCCP state diagram showing how a DCCP
connection should progress, and the proper responses for packets or
timeout events in various connection states. The state diagram is
illustrative; the text should February 2004

Some features are required to be considered definitive.

+----------------------------------+
| Figure omitted from text version |
+----------------------------------+

All receive events on understood by all DCCPs (see
Section 6.4); the diagram represent receipt of sequence-
valid packets with correct header checksums. For example, receiving
a CHANGING endpoint SHOULD reset the connection
(with Reset with Code 5, "Option Error") if it receives an empty Confirm
option for such a bad Acknowledgement Number MUST NOT cause DCCP to
transition to the TIME-WAIT state. DCCP implementations SHOULD send
Acks as described above feature.

Since Confirm options are generated only in response to sequence-invalid packets.

Otherwise-valid packets without explicit transitions in the state
diagram SHOULD be treated according Change
options, an endpoint should never receive a Confirm option referring
to the table below. Particular
actions are "OK", meaning the packet a feature number it does not understand. Endpoints MUST be processed according to
this document; "Rst", meaning either
reset the receiver SHOULD respond with a
(possibly rate-limited) Reset; and "-", meaning connection on receiving such options, or just ignore the packet SHOULD be
ignored. Entries may take
options.

6.6.7. Invalid Options

A DCCP endpoint might receive a Change or Confirm option that lists
one or more values that it does not understand. Some, but not all,
such options are invalid, depending on the form "Old/New", where "Old" applies
to old packets relevant reconciliation
rule (Section 6.3). For instance:

o All features have length limitiations, and "New" to new packets (whose sequence numbers options with invalid
lengths are
greater than GSR, invalid. For example, the greatest Mobility ID feature takes
128-bit values, so valid sequence number seen "Confirm R(Mobility ID)" options have
option length 19.

o Some non-negotiable features have value limitations. The Ack
Ratio feature takes two-byte, non-zero integer values, so far).

Data/Ack/
DataAck/ Reset/
State Request Response Move CloseReq Close Sync
------------- -------- -------- -------- -------- -------- --------
CLOSED Rst Rst Rst Rst Rst OK
LISTEN OK Rst Rst(1) Rst Rst OK
REQUEST Rst OK Rst Rst Rst OK
RESPOND -/OK Rst Rst/OK Rst OK OK
SERVER-OPEN -/Rst Rst OK Rst OK OK
CLIENT-OPEN Rst -/Rst OK OK OK OK
CLOSEREQ -/Rst Rst OK Rst OK OK
CLOSING Rst -/Rst OK OK OK OK
TIME-WAIT Rst Rst Rst Rst Rst OK

Again, we note a
"Change L(Ack Ratio, 0)" option is never valid. Note that the table only applies to valid packets.
Sequence-invalid packets SHOULD be treated server-
priority features do not have value limitations, since unknown
values are handled as described above.

A DCCP endpoint a matter of course.

o Any Confirm option that implements selects the Init Cookie option (Section 6.6)
may change wrong value, based on the Reset action marked (1). Init Cookie lets two
preference lists and the server

Kohler/Handley/Floyd/Padhye Section 5.4. [Page 36]

INTERNET-DRAFT Expires: April 2004 October 2003

package all state for a requested connection into relevant reconciliation rule, is invalid.

An endpoint receiving an invalid Change option MUST respond with the
corresponding empty Confirm option. An endpoint receiving an
invalid Confirm option MUST reset the connection, with Reset Code 5,
"Option Error".

6.6.8. Mandatory Feature Negotiation

Change options may be preceded by Mandatory options (Section 5.9.2).
Mandatory Change options are processed like normal Change options,
except that the
client various failure cases will echo. A server with Init Cookie need not implement cause the
RESPOND state. Instead, it may reply receiver to each DCCP-Request packet reset
the connection with Reset Code 6, "Mandatory Failure", rather than
send a DCCP-Response containing an Init Cookie. When a DCCP-Data,
Ack, or DataAck packet carrying a valid Init Cookie arrives from Confirm option. Specifically, the
client, connection MUST be reset
if:

o The Change option's feature number was not understood;

Kohler/Handley/Floyd Section 6.6.8. [Page 40]

INTERNET-DRAFT Expires: August 2004 February 2004

o The Change option's value was invalid, and the server will move directly from LISTEN to OPEN. Like TCP
SYN cookies [SYNCOOKIES], Init Cookies let servers avoid keeping any
state for clients whose addresses receiver would
normally have not been verified.

A DCCP endpoint sent an empty Confirm option in the CLOSED response; or LISTEN state may not have a proper
sequence number available to send a Reset. In these cases, it MUST
set

o For server-priority features, there was no shared entry in the Reset's Sequence Number two
endpoints' preference lists.

There's no reason to zero. Resets mark Confirm options as Mandatory in this
version of DCCP, since Confirm options are sent only in the CLOSED,
LISTEN, response to
Change options and TIME-WAIT states SHOULD use Reset Reason "No
Connection"; other Resets SHOULD use Reason "Invalid Packet". A
DCCP MAY send Resets not listed in therefore can't mention potentially-invalid
values or unexpected feature numbers.

6.6.9. Out-of-Band Agreement

An endpoint MUST NOT unilaterally change the diagram if it detects an
inconsistency---for example, if it receives two value of any DCCP packets with
the same sequence number, but different packet types.

The Open state does not signify that a
feature. However, endpoints MAY cooperatively change DCCP connection is ready for
data transfer. In particular, incomplete feature negotiations might
prevent data transfer. Feature
values without using in-band feature negotiation takes place in parallel
with the state transitions on this diagram.

Only the server may take the transition from the OPEN options---by using
a separate signalling channel, for example.

6.6.10. State Diagram

This diagram illustrates feature-related state to the
CLOSEREQ state. (The server is transitions, ignoring
sequence number and option validity issues, for the DCCP endpoint that began in the
LISTEN state.) Similarly, only the client must transition to CLOSE
after receiving a CloseReq packet.

5.5. DCCP-Request Packet Format

A DCCP connection is initiated by sending a DCCP-Request packet.
The format of
the feature location. For a DCCP request packet is:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (12 or 16 bytes) /
/ with Type=0 (DCCP-Request) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ feature remote state transition
diagram, switch the "L"s and "R"s.

rcv Confirm R app/protocol evt : snd Change L
: ignore +--------------------------------------------+
+----+ | Service Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options / [padding] v |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ rcv Change R v
+------------+ rcv Confirm R : calc new value, +------------+
| data | : accept value snd Confirm L | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Kohler/Handley/Floyd/Padhye Section 5.5. [Page 37]

INTERNET-DRAFT Expires: April 2004 October 2003

Service Code: 32 bits
| STABLE |<------------------------------------| CHANGING |
| | rcv empty Confirm R | |
+------------+ : revert to old value +------------+
| ^ | ^
+----+ +----+
rcv Change R timeout/rcv non-ack
: calc new value, snd Confirm L : snd Change L

This state diagram corresponds to the following procedure for
reacting to received packets with feature negotiation options. The Service Code field describes the service
procedure refers to "P.seqno", "P.ackno", "P.optiontype", and
"P.optionlen", which are properties of the sender
is trying to connect. Service Codes packet; "F.GSR" and
"F.GSS", which are 32-bit the variables mentioned in Section 6.6.3;
"F.state", which is the feature's state (STABLE or CHANGING); and
"F.value", which is the feature's value.

Kohler/Handley/Floyd Section 6.6.10. [Page 41]

INTERNET-DRAFT Expires: August 2004 February 2004

If F.state == STABLE:
If P.optiontype == Change R && P.seqno > F.GSR:
Calculate new value
Send Confirm L on next packet
F.GSR := P.seqno
Otherwise:
Ignore option

If F.state == CHANGING:
If P.optiontype == Confirm R && P.ackno >= F.GSS
&& P potentially acknowledges F.GSS:
If P.optionlen == 3:
/* empty Confirm R option */
Retain old value
Otherwise:
Check new value
F.value := new value
F.state := STABLE
Otherwise, if P.optiontype == Change R && P.seqno > F.GSR:
Calculate new value
Send Confirm L on next packet
F.GSR := P.seqno
Otherwise:
Ignore option

7. Sequence Numbers

DCCP uses 24- or 48-bit sequence numbers
allocated by IANA; they are meant to correspond to application
services arrange packets into
sequence, detect losses and protocols, such as FTP network duplicates, and HTTP, protect against
attackers, half-open connections, and are not
intended to be DCCP-specific. With Service Codes, stateful
middleboxes, such as firewalls, can identify the application
running on a nonstandard port (assuming the DCCP header has not
been encrypted). A Service Code delivery of zero is very old
packets. Every packet carries a wildcard, matching
any service. The host operating system MAY force every Sequence Number; most packet types
carry an Acknowledgement Number as well.

DCCP
socket, both actively and passively opened, to specify a nonzero
Service Code. Connection requests MUST fail if the Destination
Port on the receiver has a different Service Code from that
given in the packet, and both Service Codes sequence numbers are nonzero. In
this case, per-packet. Thus, each endpoint
increments the receiver will respond DCCP Sequence Number field by one (modulo 2^24 or
2^48) with a DCCP-Reset every packet
(with Reason set to "Bad Service Code"). A server or stateful
middlebox MAY also send a "Bad Service Code" DCCP-Reset in
response to sent. Even DCCP-Ack and DCCP-Sync packets,
and other packets whose Service Code that don't carry user data, increment the Sequence
Number. Since DCCP is considered unsuitable.

Options an unreliable protocol, there are no true
retransmissions; but effective retransmissions, such as
retransmissions of DCCP-Request packets will usually include a "Change R(Connection
Nonce)" option, to inform packets, also increment the server Sequence
Number. This lets DCCP implementations detect network duplication,
retransmissions, and acknowledgement loss, and is a significant
departure from TCP practice.

7.1. Variables

DCCP endpoints maintain a set of the client's connection
nonce; see sequence number variables for each
connection.

Kohler/Handley/Floyd Section 6.5. 7.1. [Page 42]

INTERNET-DRAFT Expires: August 2004 February 2004

ISS The client MAY send new Initial Sequence Number Sent by this endpoint. This
equals the Sequence Number of the first DCCP-Request packets if no response is
received after some timeout. or
DCCP-Response sent.

ISR The retransmission strategy SHOULD be
similar to that for retransmitting TCP SYNs; for instance, a first
timeout on Initial Sequence Number Received from the order other
endpoint. This equals the Sequence Number of a second, with an exponential backoff timer.
Each retransmission MUST increment the first
DCCP-Request or DCCP-Response received.

GSS The Greatest Sequence Number, and possibly
# NDP, Number Sent by one.

A client MAY decide to give up after some number this endpoint.
("Greatest" is of DCCP-Requests.
If so, it SHOULD send a DCCP-Reset packet to the server, to clean up
state course measured in case one or more circular sequence
space.)

GSR The Greatest Sequence Number Received from the other
endpoint on an acknowledgeable packet. (Section 7.4 defines
"acknowledgeable" packets.)

GAR The Greatest Acknowledgement Number Received from the other
endpoint on an acknowledgeable packet.

Some other variables are derived from these primitives.

SWL and SWH
(Sequence Number Window Low and High) The extremes of the Requests actually arrived.
validity window for received packets' Sequence Numbers.

AWL and AWH
(Acknowledgement Number Window Low and High) The
DCCP-Reset SHOULD have Reason set to "Aborted".

5.6. DCCP-Response Packet Format

In the second phase extremes
of the three-way handshake, validity window for received packets' Acknowledgement
Numbers.

7.2. Initial Sequence Numbers

The endpoints' initial sequence numbers are set by the server sends a first DCCP-
Request and DCCP-Response message packets sent. Initial sequence numbers
MUST be chosen to avoid two problems:

o Delivery of old packets, where packets lingering in the client. In this phase, network
from an old connection are delivered to a server will
often specify new connection with the options it would like to use, either from among
those
same addresses and port numbers.

o Sequence number attacks, where an attacker can guess the client requested, or in addition to those. Among sequence
numbers that a future connection would use [M85].

DCCP implementations may use TCP's strategies for avoiding these
options is
problems [RFC 793] [RFC 1948].

To address the congestion control mechanism first problem, an implementation MUST ensure that the server expects to
use.

Kohler/Handley/Floyd/Padhye
initial sequence number for a given <source address, source port,

Kohler/Handley/Floyd Section 5.6. 7.2. [Page 38] 43]

INTERNET-DRAFT Expires: April August 2004 October 2003

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 February 2004

destination address, destination port> 4-tuple doesn't overlap with
recent sequence numbers on connections with the same 4-tuple
("recent" meaning sent within 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (12 or 16 bytes) /
/ maximum segment lifetimes). If the
implementation has state for a recent connection with Type=1 (DCCP-Response) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number |
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)Iff
(| Acknowledgement Number (low bits) | Reserved |)X=1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options / [padding] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Acknowledgement Number: 24 bits
In the case of same
4-tuple, it can simply pick a DCCP-Response packet, good initial sequence number;
otherwise, it could tie initial sequence number selection to some
clock, such as the Acknowledgement
Number field will equal 4-microsecond clock used by TCP [RFC 793].

To address the second problem, an implementation MUST provide each
4-tuple with an independent initial sequence number from space; then an
attacker can't learn anything about anyone else's initial sequence
numbers. RFC 1948 achieves this by adding a cryptographic hash, of
the
corresponding DCCP-Request.

Options
The Data Dropped and Init Cookie options are particularly useful
for DCCP-Response packets (Sections 8.7 and 6.6). In addition,
DCCP-Response, or early DCCP-Data or DCCP-Ack packets, may
include "Confirm L(Connection Nonce)" and "Change R(Connection
Nonce)" options, to negotiate connection nonces (Section 6.5),
as well as options to negotiate CCIDs 4-tuple and other relevant
features.

The receiver MAY respond to a DCCP-Request packet with a DCCP-Reset
packet secret, to refuse any initial sequence number. For the connection. Relevant Reset Reasons for
refusing
secret, RFC 1948 recommends a connection include "Connection Refused", combination of some truly-random data
[RFC 1750], an administratively-installed passphrase, the endpoint's
IP address, and the endpoint's boot time, but truly-random data is
sufficient. Care should be taken when changing the DCCP-
Request's Destination Port did not correspond to secret; such a DCCP port open
change alters all initial sequence number spaces, which might make
an initial sequence number for some 4-tuple equal a recently sent
sequence number for the same 4-tuple. To avoid this problem around
such a change, the endpoint might remember dead connection state for listening; "Bad Service Code",
each 4-tuple or stay quiet for 2 maximum segment lifetimes.

7.3. Quiet Time

DCCP endpoints, like TCP endpoints, must take care before initiating
connections when the DCCP-Request's Service
Code did not correspond they boot. In particular, they MUST NOT send
packets whose sequence numbers are close to the service code registered with sequence numbers of
packets lingering in the
Destination Port; and "Too Busy", when network from before the server is currently too
busy boot. The simplest
way to respond enforce this rule is for DCCP endpoints to requests. The server SHOULD limit the rate at
which it generates these resets.

The receiver SHOULD NOT retransmit DCCP-Response packets; the sender
will retransmit avoid sending any
packets until one maximum segment lifetime (2 minutes) after boot.
Other enforcement mechanisms include remembering recent sequence
numbers across boots, or reserving the DCCP-Request if necessary. (Note upper 8 or so bits of initial
sequence numbers for a persistent boot counter that decrements by
two each boot (this would require the
"retransmitted" DCCP-Request will have, at least, a different use of extended sequence number from
numbers).

7.4. Acknowledgement Numbers

DCCP has no cumulative acknowledgement field; cumulative
acknowledgements would be meaningless in an unreliable protocol.
Therefore, the "original" DCCP-Request; Acknowledgement Number field has a different meaning
in DCCP than in TCP.

A packet is classified as "acknowledgeable" if and only if its
options were processed by the receiver can
thus distinguish true retransmissions from network duplicates.) The
responder will detect receiving DCCP. This means, for
example, that the retransmitted DCCP-Request applies to
an existing connection because of its Source all acknowledgeable packets have valid header
checksums and Destination Ports.

Kohler/Handley/Floyd/Padhye sequence numbers. The Acknowledgement Number for most

Kohler/Handley/Floyd Section 5.6. 7.4. [Page 39] 44]

INTERNET-DRAFT Expires: April August 2004 October 2003

Every valid DCCP-Request received while the server is in the RESPOND
state MUST elicit a new DCCP-Response. Each new DCCP-Response February 2004

packet types MUST
increment equal GSR, the responder's Greatest Sequence Number, and possibly # NDP, by
one.

The responder SHOULD NOT accept any Number Received
on an acknowledgeable packet.

Note that "acknowledgeable" refers to option processing, not data accompanying a
retransmitted DCCP-Request. In particular, the DCCP-Response sent
processing. Even acknowledgeable packets may have their application
data dropped, due to receive buffer overflow or corruption, for
instance. Data Dropped options report these data losses when
necessary, letting congestion control mechanisms distinguish between
network losses and endpoint losses. This issue is discussed further
in reply Sections 11.4 and 11.7.

DCCP-Sync and DCCP-SyncAck packets are a special case to this rule.
The Acknowledgement Number on a retransmitted DCCP-Request with data SHOULD contain DCCP-Sync packet corresponds to a
Data Dropped option,
received packet, but not necessarily an acknowledgeable packet; in which the retransmitted DCCP-Request is
reported as "data dropped due
particular, it might correspond to protocol constraints" (Drop Code
0). an out-of-sync packet whose
options were not processed. The original DCCP-Request SHOULD also Acknowledgement Number on a DCCP-
SyncAck packet always corresponds to an acknowledgeable DCCP-Sync
packet; if there was reordering, that Acknowledgement Number might
be reported in less than GSR.

7.5. Validity and Synchronization

Any DCCP endpoint might receive packets that are not actually part
of the Data
Dropped option, either in current connection. For instance, the network might deliver
an old packet, an attacker might attempt to hijack a connection, or
the other endpoint might crash, causing a half-open connection.

DCCP, like TCP, uses sequence number checks to detect these cases
Packets whose Sequence and/or Acknowledgement Numbers are out of
range are called sequence-invalid, and are not processed normally.

Unlike TCP, DCCP requires a Normal Block (if the responder accepted
the data, or there was no data), or in synchronization mechanism to recover
from large bursts of loss. One endpoint might send so many packets
during a Drop Code 0 Drop Block (if burst of loss that when one of its packets finally got
through, the responder refused other endpoint would label its Sequence Number as
invalid. A handshake involving DCCP-Sync and DCCP-SyncAck packets
recovers from this case.

7.5.1. Sequence-Validity Rules

Sequence-validity depends on the data received packet's type. This table
shows the first time as well).

5.7. DCCP-Data, DCCP-Ack, sequence and DCCP-DataAck Packet Formats

The payload of acknowledgement number checks applied to each
packet; a DCCP connection packet is sent in DCCP-Data and DCCP-
DataAck packets, sequence-valid if it passes both tests, and DCCP-Ack packets are used for acknowledgements
when there is no payload
sequence-invalid if it does not. Many of the checks refer to be sent. DCCP-Data packets look like
this:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (12 or 16 bytes) /
/ with Type=2 (DCCP-Data) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options / [padding] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DCCP-Ack packets dispense with the data, but contain an
sequence and acknowledgement number:

Kohler/Handley/Floyd/Padhye number windows, [SWL, SWH] and [AWL,
AWH], defined below in Section 5.7. 7.5.3.

Kohler/Handley/Floyd Section 7.5.1. [Page 40] 45]

INTERNET-DRAFT Expires: April August 2004 February 2004 October 2003

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (12 or 16 bytes) /
/ with Type=3 (DCCP-Ack) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |

Acknowledgement Number |
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)Iff
(| Acknowledgement
Packet Type Sequence Number (low bits) | Reserved |)X=1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options / [padding] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Check Check
----------- --------------------- ----------------------
DCCP-Request SWL <= seqno <= SWH (*) N/A
DCCP-Response SWL <= seqno <= SWH (*) AWL <= ackno <= AWH
DCCP-Data SWL <= seqno <= SWH N/A
DCCP-Ack SWL <= seqno <= SWH AWL <= ackno <= AWH
DCCP-DataAck packets contain both data and an acknowledgement
number: acknowledgement information is piggybacked on a data packet.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 SWL <= seqno <= SWH AWL <= ackno <= AWH
DCCP-CloseReq SWL <= seqno <= SWH AWL <= ackno <= AWH
DCCP-Close SWL <= seqno <= SWH AWL <= ackno <= AWH
DCCP-Reset seqno == 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (12 or 16 bytes) /
/ with Type=4 (DCCP-DataAck) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number |
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)Iff
(| Acknowledgement Number (low bits) | Reserved |)X=1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options / [padding] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A DCCP-Data seqno > GSR GAR <= ackno <= AWH
DCCP-Move seqno >= SWL ISS <= ackno <= AWH
DCCP-Sync seqno >= SWL AWL <= ackno <= AWH
DCCP-SyncAck seqno >= SWL AWL <= ackno <= AWH

(*) Check not applied if connection is in LISTEN or DCCP-DataAck packet REQUEST state.

In general, packets are sequence-valid if their Sequence and
Acknowledgement Numbers lie within the corresponding valid windows,
[SWL, SWH] and [AWL, AWH]. The exceptions to this rule are as
follows:

o DCCP-Reset Sequence Numbers may contain no data bytes if be zero. This is because during
the
application sends cleanup of a zero-length datagram.

DCCP A sends DCCP-Data and DCCP-DataAck packets to DCCP B due half-open connection, an endpoint might generate
a DCCP-Reset in response to
application events on host A. These packets are congestion-
controlled by a DCCP-Request or DCCP-Data packet
with no Acknowledgement Number; the CCID resetting endpoint would then
use zero for the A-to-B half-connection. In contrast,
DCCP-Ack packets sent by DCCP A Reset's Sequence Number, since it has no valid
Sequence Number available.

DCCP-Reset Acknowledgement Numbers, and non-zero Sequence Numbers,
are controlled by the CCID for the
B-to-A half-connection. Generally, DCCP A will piggyback
acknowledgement information checked more stringently than those on data packets when acceptable,
creating DCCP-DataAck packets. DCCP-Ack packets are used when there other packet types,
however. This is because DCCP-Reset always ends a connection: no data to
endpoint will send from DCCP A to DCCP B, a non-Reset packet on a connection after it has
sent a Reset. Thus, a Reset packet whose Sequence Number is less
than GSR, or when the congestion
state of whose Acknowledgement Number is less than GAR, must
be sequence-invalid.

o DCCP-Move Sequence and Acknowledgement Numbers are not strongly
checked because moves might likely happen after long loss periods,
and the A-to-B CCID will mandatory Mobility ID provides good protection against
unexpected packets.

o DCCP-Sync and DCCP-SyncAck Sequence Numbers are not allow data strongly
checked. These packet types exist specifically to be sent.

Kohler/Handley/Floyd/Padhye get the
endpoints back into sync after bursts of loss; checking their
Sequence Numbers would eliminate their usefulness.

Kohler/Handley/Floyd Section 5.7. 7.5.1. [Page 41] 46]

INTERNET-DRAFT Expires: April August 2004 October 2003

DCCP-Ack and DCCP-DataAck packets often include additional
acknowledgement options, February 2004

These lenient checks all allow continued operation after unusual
events, such as Ack Vector, as required by the
congestion control mechanism in use.

Section 8, below, describes acknowledgements in DCCP.

5.8. DCCP-CloseReq and DCCP-Close Packet Format

The DCCP-CloseReq endpoint crashes and DCCP-Close large bursts of loss. There's
no need for leniency when the endpoints are actively sending packets have
to one another. Therefore, a DCCP endpoint SHOULD implement the same format except
following, tighter constraints for Type. However, only the server can send active connections. An endpoint
considers a DCCP-CloseReq packet.
Either client connection active if it has received valid packets from
the other endpoint within the last several round-trip times, or server may send
1 second, if the RTT is not known.

Acknowledgement Number
Packet Type Sequence Number Check Check
----------- --------------------- ----------------------
DCCP-Reset GSR < seqno <= SWH GAR <= ackno <= AWH
DCCP-Move SWL <= seqno <= SWH AWL <= ackno <= AWH
DCCP-Sync SWL <= seqno <= SWH AWL <= ackno <= AWH
DCCP-SyncAck SWL <= seqno <= SWH AWL <= ackno <= AWH

Note that sequence-validity is only one of the validity checks
applied to received packets.

7.5.2. Handling Sequence-Invalid Packets

Sequence-invalid DCCP-Move, DCCP-Reset, DCCP-Sync, and DCCP-SyncAck
packets MUST be ignored.

When DCCP A receives any other sequence-invalid packet, it MUST
reply with a DCCP-Close DCCP-Sync packet. This packet MUST acknowledge the
packet's Sequence Number (not GSR!). The receiver
of DCCP-Sync MUST use a valid DCCP-Close new
Sequence Number, and thus will increase GSS; GSR will not change,
however, since the received packet SHOULD respond with a DCCP-Reset
packet, with Reason set to "Closed"; was sequence-invalid. DCCP A
MUST NOT otherwise process sequence-invalid packets. For instance,
it MUST NOT process their options.

When the DCCP B endpoint that originally
sent receives the DCCP-Close will hold Time-Wait state. The receiver of a
valid DCCP-CloseReq packet SHOULD respond (sequence-valid) DCCP-Sync, it
MUST update its GSR variable and reply with a DCCP-Close packet;
that DCCP-SyncAck packet
acknowledging the DCCP-Sync (not necessarily GSR!). Upon receiving endpoint
this DCCP-SyncAck, which will expect to hold Time-Wait state after
later receiving a DCCP-Reset.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (12 or 16 bytes) /
/ with Type=5 or 6 (DCCP-CloseReq or Close) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number |
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)Iff
(| Acknowledgement Number (low bits) | Reserved |)X=1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options / [padding] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.9. DCCP-Reset Packet Format

DCCP-Reset packets unconditionally shut down a connection. Every
normal connection ends with a DCCP-Reset, but resets may be sent for
other reasons, including bad port numbers, bad option behavior,
incorrect ECN Nonce Echoes, sequence-valid since it
acknowledges the DCCP-Sync, DCCP A will update its GSR variable, and so forth. The reason for a reset
the endpoints will be back in sync. Alternatively, if the
connection was half-open (DCCP B is
represented by an eight-bit number, in CLOSED or REQUEST state),
DCCP B will send a Reset.

A DCCP endpoint MAY temporarily preserve sequence-invalid packets in
case they become valid later. This can reduce the Reason field, and 24 bits impact of
additional data. The bursts
of loss by delivering more packets to the application. In
particular, an endpoint that receives MAY preserve a valid DCCP-Reset sequence-invalid packet will hold Time-Wait state for the connection. The optional
DCCP-Reset payload,
up to 2 round-trip times (or 1 second, if present, the RTT is a human-readable text string,
preferably in English and encoded in Unicode UTF-8, unknown); if,
within that describes time, the error in more detail. DCCP-Reset packets MUST NOT be generated

Kohler/Handley/Floyd/Padhye relevant sequence windows change so that the

Kohler/Handley/Floyd Section 5.9. 7.5.2. [Page 42] 47]

INTERNET-DRAFT Expires: April August 2004 October 2003 February 2004

packet becomes sequence-valid, the endpoint MAY process the packet
again.

To protect itself against denial-of-service attacks (where an
attacker sends many sequence-invalid packets, trying to force the
receiver to send many DCCP-Syncs), a DCCP implementation MAY rate-
limit the DCCP-Syncs sent in response to received DCCP-Reset sequence-invalid packets.

7.5.3. Sequence and Acknowledgement Number |
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)Iff
(| Windows

Reason: 8 bits
The Reason field represents spaces. These
windows correspond to packets the reason that endpoint expects to receive in the sender reset
next few round-trip times. The Sequence and Acknowledgement Number
windows always contain GSR and GSS, respectively; the window widths
are controlled by Sequence Window features.

The Sequence Number validity window for packets from DCCP B is [SWL,
SWH]. This window always contains GSR, the Greatest Sequence Number
Received on a sequence-valid packet from DCCP connection.

Data 1, Data 2, and Data 3: 8 bits each
The Data fields provide additional information about why B. It is W packets
wide, where W is the
sender reset value of the DCCP connection. The meanings Sequence Window/B feature. One-
fourth of these fields
depend on the value sequence window, rounded down, is placed at and before
GSR, with three-fourths after GSR. (This asymmetric placement
assumes that bursts of Reason.

The following Reasons loss are currently defined. The "Data" columns
describe what more common in the Data fields should contain network than
significant reordering.)

The Acknowledgement Number validity window for a given Reason. In
those columns, N/A means packets from DCCP B
is [AWL, AWH]. The high end of the Data field SHOULD be set to 0 window, AWH, always equals GSS,
the Greatest Sequence Number Sent by DCCP A; the
sender window is W'
packets wide, where W' is the value of the DCCP-Reset, Sequence Window/A
feature.

SWL and ignored by its receiver.

Kohler/Handley/Floyd/Padhye AWL are initially adjusted so that they don't go below the
initial Sequence Numbers received and sent, respectively:
SWL := max(GSR + 1 - floor(W/4), ISR),
AWL := max(GSS - W' + 1, ISS).
Of course, these adjustments MUST NOT be applied after the relevant

Kohler/Handley/Floyd Section 5.9. 7.5.3. [Page 43] 48]

INTERNET-DRAFT Expires: April August 2004 October 2003

Section
Reason Name Data 1 Data 2 Data 3 Reference
------ ---- ------ ------ ------ ---------
0 Unspecified N/A N/A N/A
1 Closed N/A N/A N/A 3.2
2 Invalid Packet packet N/A N/A 5.4
type
3 Option Error option option data
number (if any)
4 February 2004

sequence numbers wrap.

7.5.4. Sequence Window Feature Error

The Sequence Window/A feature determines the width of the Sequence
Number validity window used by DCCP B, and the width of the
Acknowledgement Number validity window used by DCCP A. DCCP A sends
a "Change L(Sequence Window, W)" option to notify DCCP B that the
Sequence Window/A value is W.

Sequence Window has feature data number (if any)
5 Connection Refused N/A N/A N/A 5.6 3, and is non-negotiable. It
takes 3- or 6-byte integer values, like DCCP sequence numbers.
Change and Confirm options for Sequence Window are therefore either
6 Bad Service Code N/A N/A N/A 5.5
7 Too Busy N/A N/A N/A 5.6
8 Bad Init Cookie N/A N/A N/A 6.6
10 Unanswered Challenge N/A N/A N/A 6.5.4
11 Fruitless Negotiation feature feature data 6.4.8
number (optional)
12 Aggression Penalty N/A N/A N/A 9.2
13 No Connection N/A N/A N/A 5.4
14 Aborted N/A N/A N/A 5.4
15 Extended Seqnos N/A N/A N/A 5.3
16 Mandatory Failure option option data 6.3
number (if any)
17-127 Reserved
128-255 CCID-specific reasons ... variable ... 7.4 or 9 bytes long. New connections start with Sequence Window 100
for both endpoints.

A DCCP-Reset packet completes every proper Sequence Window/A value should reflect how many packets
DCCP connection, whether A expects to be in flight. Only DCCP A can anticipate this
number. Too-small values increase the risk of the endpoints getting
out sync after bursts of loss; too-large values increase the risk of
connection hijacking. (The next section quantifies this risk.) One
good guideline is for each endpoint to set Sequence Window to a
small multiple of the
termination is clean (due maximum number of packets it expects to application close; Reset Reason
"Closed") or unclean. Unlike TCP, which has two distinct
termination mechanisms (FIN and RST), DCCP ends all connections send
in a
uniform manner. round-trip time. This is justified because some responses to value may not be available at connection termination close are
initiation, when the same no matter whether
termination was clean. For instance, round-trip time is unknown, but the endpoint
can always send updates as the connection progresses.

7.5.5. Sequence Number Attacks

Sequence and Acknowledgement Numbers form DCCP's main line of
defense against attackers. An attacker that receives cannot guess sequence
numbers cannot easily manipulate or hijack a
valid DCCP-Reset should hold Time-Wait state for DCCP connection, and
requirements like careful initial sequence number choice eliminate
the connection.
Processors that must distinguish between clean most serious attacks.

An attacker might still send many packets with randomly chosen
Sequence and unclean
termination can examine Acknowledgement Numbers, however. If one of those
probes ends up sequence-valid, it may shut down the Reset Reason.

DCCP implementations MUST transition connection or
otherwise cause problems. The easiest such attacks to execute are:

o Send DCCP-Sync packets with random Sequence and Acknowledgement
Numbers. If one of these packets hits the CLOSED state after
sending a DCCP-Reset packet.

5.10. DCCP-Move Packet Format

The DCCP-Move packet type is part valid acknowledgement
number window, the receiver will shift its sequence number window
accordingly, getting out of DCCP's support for multihoming sync with the correct
endpoint---perhaps permanently.

o Send DCCP-Reset packets with Sequence Number zero and mobility, which is described further in Section 10. DCCP A sends
a DCCP-Move packet to DCCP B after changing its address and/or port
number. The DCCP-Move packet requests that DCCP B start sending

Kohler/Handley/Floyd/Padhye random
Acknowledgement Numbers. If one of these packets hits the valid

Kohler/Handley/Floyd Section 5.10. 7.5.5. [Page 44] 49]

INTERNET-DRAFT Expires: April August 2004 October 2003 February 2004

acknowledgement number window, the connection will be shut down.

o Send DCCP-Data packets to with random Sequence Numbers. If one of
these packets hits the new address and port number. The new address and
port come from valid sequence number window, the attack
packet's network header and generic DCCP header; application data may be inserted into the old address and port are defined through a Mobility ID, which
must have been set earlier via a Mobility ID feature. data stream.

The Mobility
ID attacker has to guess both Source and a mandatory Identification option provide some protection
against hijacked connections. See Section 10 Destination Ports for more on security
and DCCP's mobility support.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (12 or 16 bytes) /
/ with Type=8 (DCCP-Move) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number |
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)Iff
(| Acknowledgement Number (low bits) | Reserved |)X=1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility ID (high bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility ID (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options, including Identification / [padding] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Mobility ID: 64 bits
The value any
of these attacks to succeed. Additionally, the sender's Mobility ID feature. This value
uniquely identifies the current connection among would
have to be inactive for the set of
connections terminating at DCCP-Sync and DCCP-Reset packets to
succeed, assuming the receiver; it MUST have been set
by victim implemented the receiver more stringent checks
for active connections recommended in an earlier exchange.

Options
Every DCCP-Move packet MUST include a valid Identification
option (see Section 6.5).

DCCP B MUST ignore 7.5.1.

To quantify the DCCP-Move if it has no record for probability of success, let N be the
packet's Mobility ID; if number of
attack packets the Identification option attacker is not present or
invalid; if willing to send, W be the Sequence Number is not greater than GSR; or if relevant
sequence window width, and L be the
Acknowledgement Number length of sequence numbers (24
or 48). The attacker's best strategy is greater than GSS. DCCP B SHOULD NOT
respond to invalid Moves space the attack packets
evenly over sequence space. Then one of these attacks will succeed
with DCCP-Reset or DCCP-Ack packets, since
any such response would leak information probability P = WN/2^L. For N = 1000, W = 100, and L = 24,
this probability is about 0.006. (For reference, the connection, such
as the current easiest TCP
attack---sending a SYN with a random sequence number, to which will
cause a possibly malicious host. After
receiving an invalid DCCP-Move, DCCP B MAY ignore subsequent DCCP-
Move packets, valid or not, connection reset if it falls within the window---will
succeed with probability 0.002 for a short period N = 1000, W = 8760 [a common
default], and L = 32.) Connections with sequence windows much
larger than 100 SHOULD use extended sequence numbers to reduce the
probability of time, such as one

Kohler/Handley/Floyd/Padhye Section 5.10. [Page 45]

INTERNET-DRAFT Expires: April 2004 October 2003

second or one round-trip time. This protects attack success.

7.5.6. Examples

In the following example, DCCP A and DCCP B against denial-
of-service attacks recover from floods a large
burst of invalid DCCP-Moves.

DCCP-Move packets do not follow the usual sequence-validity rules.
This is to support endpoints loss that react to long bursts runs DCCP A's sequence numbers out of loss by
moving. Such moves will often happen after the endpoints get DCCP B's
appropriate sequence number window.

Recovery from Burst of Loss
DCCP A DCCP B
(GSS=1,GSR=10) (GSS=10,GSR=1)
--> DCCP-Data(seq 2) XXX
...
--> DCCP-Data(seq 100) XXX
--> DCCP-Data(seq 101) --> ???
seqno out of
sync, causing DCCP-Move packets to frequently have inappropriate
Sequence Numbers. But range;
send Sync
OK <-- DCCP-Sync(seq 11, ack 101) <--
(GSS=11,GSR=1)
--> DCCP-SyncAck(seq 102, ack 11) --> OK
(GSS=102,GSR=11) (GSS=11,GSR=102)

In the usual DCCP-Sync mechanism next example, a DCCP connection recovers from a simple
attack. The attacker cannot guess sequence numbers. (DCCP is
inappropriate in response not

Kohler/Handley/Floyd Section 7.5.6. [Page 50]

INTERNET-DRAFT Expires: August 2004 February 2004

robust to Moves, since it could leak attackers who can guess sequence
numbers to possibly malicious hosts. numbers.)

Recovery from Attack
DCCP A DCCP B MUST set its GSR
variable to the Sequence Number on
(GSS=1,GSR=10) (GSS=10,GSR=1)
*ATTACKER* --> DCCP-Data(seq 10^6) --> ???
seqno out of range;
send Sync
??? <-- DCCP-Sync(seq 11, ack 10^6) <--
ackno out of range; ignore
(GSS=1,GSR=10) (GSS=11,GSR=1)

The final example demonstrates recovery from a valid DCCP-Move. half-open connection.

Recovery from a Half-Open Connection
DCCP B SHOULD acknowledge valid DCCP-Move packets with DCCP-Ack or
DCCP-DataAck packets. If A DCCP B accepts the move, it MUST send this
acknowledgement to the packet's network source address and DCCP
Source Port; if it rejects the move, which it MAY do for any reason,
it MUST send this acknowledgement to
(GSS=1,GSR=10) (GSS=10,GSR=1)
(Crash)
CLOSED OPEN
REQUEST --> DCCP-Request(seq 400) --> ???
!! <-- DCCP-Sync(seq 11, ack 400) <-- OPEN
REQUEST --> DCCP-Reset(seq 401, ack 11) --> (Abort)
REQUEST CLOSED
REQUEST --> DCCP-Request(seq 402) --> ...

7.6. Extended Sequence Numbers

Extended 48-bit sequence numbers increase the old address and old port.
The moving endpoint, rate DCCP A, connections
can determine whether or not its move
was accepted by checking the acknowledgement's destination address achieve without wrapping sequence numbers, and Port.

If the acknowledgement is lost, DCCP A might resend provide
additional protection against the DCCP-Move
packet (using a new sequence number). number attacks described
above. Very-high-rate DCCP B will detect this case
because the network source address connections, and Source Port correspond to a
valid connection, for which connections with large
sequence windows, SHOULD therefore use extended sequence numbers
rather than the default 24-bit sequence numbers.

7.6.1. When to Use Extended Sequence Number and Acknowledgement
Number fields are appropriate; Numbers

The sequence-validity mechanism protects against the Identification option is valid
for network
delivering old data, but it assumes that connection; and the Mobility ID refers to network does not
deliver extremely old data. In particular, it assumes that connection.
It SHOULD respond by sending another acknowledgement, as allowed by the congestion control mechanism in use.

Once DCCP B receives a non-Move
network must have dropped any packet from DCCP A, it MUST choose a
new Mobility ID for by the time the connection
wraps around and send a new Change R(Mobility
ID) option to DCCP A. This reduces the risk of replay.

We note that DCCP mobility, as provided by DCCP-Move, may not be
useful in the context of IPv6, with uses its mandatory support for Mobile
IP.

5.11. DCCP-Sync Packet Format

DCCP-Sync packets are sent when the sequence numbers of number again. We can easily
calculate the
endpoints of a maximum connection appear to have gotten out of sync. On
receiving a valid DCCP-Sync packet, DCCP will update its GSR
variable, thus restoring synchronization, and possibly send another
DCCP-Sync packet to acknowledge the synchronization. DCCP-Sync
packets look like this:

Kohler/Handley/Floyd/Padhye Section 5.11. [Page 46]

INTERNET-DRAFT Expires: April 2004 October 2003

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (12 or 16 bytes) /
/ with Type=9 (DCCP-Sync) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number |
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)Iff
(| Acknowledgement Number (low bits) | Reserved |)X=1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options / [padding] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6. Options and Features

All DCCP packets may contain options, which occupy space at rate that can be safely achieved
given this constraint. Let MSL equal the end
of maximum segment lifetime,
P equal the average DCCP header. Each option is a multiple of 8 bits packet size in length.
The combination of all options MUST add up to a multiple of 32 bits.
Individual options are not padded to multiples of 32 bits, however;
any option may begin on any byte boundary. All options are always
included in the checksum.

The first byte of an option is the option type. Options with types
0 through 31 are single-byte options. Other options are followed by
a byte indicating the option's length. This length value includes
the two bytes of option-type and option-length as well as any
option-data bytes, and MUST therefore be greater than or L equal to
two.

Options are processed sequentially, starting at the earliest option
in the packet header.

The following options are currently defined:

Kohler/Handley/Floyd/Padhye length
of sequence numbers (24 or 48 bits). Then the maximum safe rate, in
bits per second, is R = P*(2^L)/2MSL.

Kohler/Handley/Floyd Section 6. 7.6.1. [Page 47] 51]

INTERNET-DRAFT Expires: April August 2004 October 2003

Option Section
Type Length Meaning Reference
---- ------ ------- ---------
0 1 Padding 6.1
1 1 Mandatory 6.3 February 2004

For the default MSL of 2 1 Slow Receiver 8.6
32 variable Ignored 6.2
33 variable Change L 6.4
34 variable Confirm L 6.4
35 variable Change R 6.4
36 variable Confirm R 6.4
37 variable Init Cookie 6.6
38 variable Ack Vector [Nonce 0] 8.5
39 variable Ack Vector [Nonce 1] 8.5
40 variable Data Dropped 8.7
41 6 Timestamp 6.7
42 6-10 Timestamp Echo 6.9
43 variable Identification 6.5.3
44 variable Challenge 6.5.4
45 4 Payload Checksum 8.8
46 4-6 Elapsed Time 6.8
128-255 variable CCID-specific options 7.4

6.1. Padding Option minutes, 1500-byte DCCP packets, and 24-bit
sequence numbers, the safe rate is therefore approximately 800 Mb/s.
Of course, 2 minutes is a very large MSL for any networks that could
sustain that rate with such small packets. Nevertheless, 48-bit
sequence numbers allow much higher rates, up to 14 petabits a second
for 1500-byte packets and the default MSL.

The Padding option, probability of sequence number attack success P = WN/2^L,
discussed in Section 7.5.5, may also be relevant when deciding
whether to use extended sequence numbers. A fast connection will
generally have a relatively high W (sequence window size),
increasing the attack success probability for fixed N (number of
attack packets); if the probability gets uncomfortably high with type 0, L =
24, the connection should use 48-bit sequence numbers instead.

7.6.2. Header Processing

Extended sequence numbers are activated when the header's X bit is a single byte option used
set to pad
between or after options. It either ensures one (see Section 5.1). This extends the payload begins on Sequence Number and
Acknowledgement Number fields by an additional 24 bits, for a
32-bit boundary (as required), or ensures alignment total
of following
options (not mandatory).

+--------+
|00000000|
+--------+
Type=0

6.2. Ignored Option 48 bits. The Ignored option, 48-bit numbers are stored in network order, with type 32, signals that a DCCP did not
understand some option. This can happen,
most significant bit first. All packet types except for example, when one DCCP
converses DCCP-Data
and DCCP-Request will follow this generic header with another, an extended DCCP. Each Ignored option
48-bit Acknowledgement Number.

Once an endpoint has one transitioned to 48-bit sequence numbers (X=1),
it MUST send all succeeding packets with 48-bit sequence numbers.
Furthermore, once an endpoint has received a sequence-valid packet
with 48-bit sequence numbers, it MUST either send all succeeding
packets with 48-bit sequence numbers, or more bytes of data. The first byte contains reset the offending option
type; connection with
Reset Code 7, "Extended Sequence Numbers". (But note that an
endpoint may send extended DCCP-Sync packets before transitioning to
extended sequence numbers.)

Clients SHOULD decide whether to use extended sequence numbers
before sending their DCCP-Requests. However, the second Transition bit (T)
and subsequent, if present, contain the first bytes
of the offending option's data. If the offending option had data,
the Ignored option MUST include at least one byte of Sequence Transition Capable feature support transitioning to
extended sequence numbers during an active connection, in case this
proves necessary; see below. A client that data, but sends an extended DCCP-
Request might receive a DCCP-Reset in response with Reset Code 7,
"Extended Sequence Numbers"; the client SHOULD respond by sending
another Request using 24-bit sequence numbers.

Extended sequence numbers are treated simply as longer sequence
numbers. For instance, the Ignored option MUST NOT carry more Opt Data than sequence-validity mechanisms work the offending
option had data.

Kohler/Handley/Floyd/Padhye
same way whether or not sequence numbers are extended. Care is
required when comparing a 24-bit sequence number with an 48-bit
sequence number, however; see the next section.

Kohler/Handley/Floyd Section 6.2. 7.6.2. [Page 48] 52]

INTERNET-DRAFT Expires: April August 2004 October 2003

Ignored options should preferably concern options sent on the packet
acknowledged by the Acknowledgement Number. Packets without
Acknowledgement February 2004

7.6.3. Transitioning to Extended Sequence Numbers (that is, DCCP-Request and DCCP-Data) SHOULD
NOT carry Ignored options.

+--------+--------+--------+
|00100000|00000011|Opt Type|
+--------+--------+--------+
Type=32 Length=3

+--------+--------+--------+--------+--------
|00100000| Length |Opt Type| Opt Data ...
+--------+--------+--------+--------+--------
Type=32

6.3. Mandatory Option

The Mandatory option, with type 1, is a single byte option that
indicates that the immediately Transition bit (T) following option is mandatory. If the receiving DCCP does not understand that following option, extended Sequence Number field
makes it
MUST reset possible to transition to 48-bit sequence numbers in the connection with Reset Reason
middle of a connection. T is set to "Mandatory
Failure". For instance, say DCCP A receives a packet with two
options: one only during such a Mandatory option, and immediately following, another
option O. Then
transition. When DCCP A would reset the connection (rather than, for
example, sending an Ignored(O) option) if it did not understand O's
type; if switches to 48-bit sequence numbers, it understood O's type, but not O's data; if O's data was
invalid for O's type; if O was a feature negotiation option, and
DCCP A did not understand
MUST set the enclosed feature number; if DCCP A
understood O, but chose not T bit to perform the action O implies; and so
forth.

+--------+
|00000001|
+--------+
Type=1

6.4. Feature Negotiation

DCCP contains a mechanism one on all of its packets for reliably negotiating features, notably
the congestion control mechanism in use some period.
This period SHOULD last on each half-connection.
The motivation is to implement reliable feature negotiation once, so
that different options need not reinvent that wheel.

Features are identified by feature number and owning endpoint. The
notation (F,E) represents the feature with feature number F that is
owned by DCCP E. A connection generally has two features for each

Kohler/Handley/Floyd/Padhye Section 6.4. [Page 49]

INTERNET-DRAFT Expires: April 2004 October 2003

feature number, one per endpoint (or, equivalently, one per half-
connection). Given order of a feature owned by DCCP A, we call few round trip times, or
until DCCP A the
feature location and receives an acknowledgement from DCCP B the feature remote. Both endpoints keep
track of the values of all features, since the point proving that
one of feature
negotiation is its 48-bit-sequence-number packets has been received,
whichever comes later.

Each DCCP MUST choose its first 48-bit sequence number to ensure agreement.

Four options, Change L, Confirm L, Change R, and Confirm R,
implement feature negotiation. The "L" options are sent by the
feature location, the "R" options are sent by the feature remote.
Change options initiate a negotiation, Confirm options complete have its
lower 24 bits equal the
negotiation. Change options are retransmitted 24-bit sequence number it expected to ensure
reliability.

Feature values MUST NOT change apart from feature negotiation. send
(GSS+1). The upper 24 bits may be chosen arbitrarily. This
property, retransmissions, and applies
to Acknowledgement Numbers as well as Sequence Numbers; if DCCP A
sends an extended packet containing an Acknowledgement Number before
DCCP B sends it a 48-bit Sequence Number, DCCP A can choose any
value priority rules ensure that both
endpoints eventually agree on every feature's value.

Negotiations for multiple features may take place simultaneously.
For instance, the upper 24 bits of the Acknowledgement Number, but the
lower 24 bits MUST equal the expected 24-bit Acknowledgement Number
(GSR). Furthermore, DCCP A MUST leave GSR as a 24-bit number until
receiving an extended packet may contain multiple Change options that
refer from DCCP B.

Switching to different features. The endpoints may also simultaneously
open negotiations for 48-bit sequence numbers in the same feature; they will still agree on middle of a
single value.

Feature negotiation generally takes place using packet types connection
complicates sequence number comparison. Endpoints must compare
48-bit sequence numbers with 24-bit sequence numbers, and compare
48-bit sequence numbers that
carry no user data, such as DCCP-Ack, particularly when might have different, arbitrary values
in the relevant
feature may affect upper 24 bits, while remaining robust to reordering and to
old or malicious packets. The following procedure describes how data will
sequence numbers should be treated.

Here are three example feature negotiations for features located at compared during and immediately after a
transition.

Let P be the packet sequence number received from DCCP B, and E be
the first two sequence number DCCP A expects. During sequence-validity
computations, for example, P might be the Congestion Control ID feature, packet's Acknowledgement
Number and E might be AWL, the
last for left edge of the Ack Ratio:

Kohler/Handley/Floyd/Padhye Section 6.4. [Page 50]

INTERNET-DRAFT Expires: April 2004 October 2003 appropriate
acknowledgement number window. Then DCCP A DCCP B
1. Change R(CCID, 2 3 1) --->
("2 3 1" is DCCP A's value preference list)
2. <--- Confirm L(CCID, 3, 3 2 1)
(3 is should perform the negotiated value;
"3 2 1" is B's pref list)
* agreement that (CCID,B) = 3 *

1. XXX <--- Change L(CCID, 3 2 1)
2. Retransmission:
<--- Change L(CCID, 3 2 1)
3. Confirm R(CCID, 3, 2 3 1) --->
* agreement that (CCID,B) = 3 *

1. Change R(Ack Ratio, 3) --->
2. <--- Confirm L(Ack Ratio, 3)
* agreement that (Ack Ratio,B) = 3 *

6.4.1. Value Types

The feature negotiation options
comparison as follows.

o If P and E are the same for every feature
number, but the format for feature values, both 24 bits, compare them modulo 2^24.

o If P and the value priority
rules E are both 48 bits, you generally compare them modulo
2^48, except that determine the result of during a negotiation, differ from
feature to feature. All current DCCP features fit one of transition, the two value
types, non-negotiable ("NN") or server-priority ("SP"), although
other value types are possible.

o Non-negotiable features: The feature value values might have
arbitrary values in the upper 24 bits.

- If the packet's Transition bit is a byte string. Each
option contains exactly one feature value. The feature remote
changes set, and the value last packet sent
by sending Change R options. The feature
location has no preferred value for the feature, DCCP A had its Transition bit set, then compare P and MUST accept E
modulo 2^24.

Kohler/Handley/Floyd Section 7.6.3. [Page 53]

INTERNET-DRAFT Expires: August 2004 February 2004

- Otherwise, compare them modulo 2^48.

o If P is 48 bits but E is 24, the remote DCCP may want to
transition to extended sequence numbers.

- If the proposed value (as long as it packet's Transition bit is valid), responding set, compare P with a
Confirm L option containing E modulo
2^24. If the new value. Change L packet proves sequence-valid, then it is OK;
transition to extended sequence numbers, and Confirm R
options MUST NOT set E according to
the full 48 bits of P.

- Otherwise, the packet is sequence-invalid.

Either way, if the packet proves to be sent for non-negotiable features. sequence-invalid, send an
extended DCCP-Sync if required (with T set to one), but do not yet
transition to extended sequence numbers.

o Server-priority features: The feature value If P is a fixed-length byte
string (length determined by 24 bits but E is 48, there may have been benign packet
reordering. The correct action depends on whether the feature number). Each Change
option contains a prioritized list of values, with last
sequence-valid packet received from DCCP B had the most
preferred Transition bit
set.

- If Transition was set, extend P to a 48-bit value coming first. Each Confirm option contains P'. First,
let EH equal the
confirmed value, followed by upper 24 bits of E, and EL equal the confirmer's value preference
list. lower 24
bits of E. Then:

If EL > P, set P' = (EH << 24) | P.
Otherwise, set P' = (((EH - 1) mod 2^24) << 24) | P.

The value priority rule is server priority: Given both
preference lists, select the first entry in the server's list that
also occurs in "EL > P" test uses arithmetic comparison, NOT circular
comparison. Compare P' with E modulo 2^48.

- Otherwise, the client's list. If there packet is no shared entry, sequence-invalid.

Either way, if the connection MUST packet proves to be reset sequence-invalid, send an
extended DCCP-Sync if required, with Reason T set to Fruitless
Negotiation. All four option types are meaningful for server-
priority features.

Kohler/Handley/Floyd/Padhye Section 6.4.1. [Page 51]

INTERNET-DRAFT Expires: April 2004 October 2003 one.

DCCP endpoints need not calculate their value preference lists
before feature negotiation begins. Thus, a server might adjust
its preference list based on the client's preference list,
assuming implementations can, of course, avoid most of this complexity
by disallowing transitions to extended sequence numbers (and by
resetting the client opened connection when the negotiation. Once a negotiation
for other endpoint attempts such a feature has begun, however,
transition). Connections that feature's preference lists
MUST remain stable until use 48-bit sequence numbers
throughout, starting with the negotiation has closed.

6.4.2. DCCP-Request, MUST have T set to zero
on all their packets.

7.6.4. Sequence Transition Capable Feature Numbers

The first data byte of every Change or Confirm option is a feature
number, defining the type of Sequence Transition Capable feature being negotiated. The remainder expresses whether DCCP
endpoints are capable of the data gives one or more values for the feature, and is
interpreted according transitioning to extended sequence numbers
in the feature. The current set course of feature
numbers is as follows:

Value Initial Section
Number Meaning Type Value Reference
------ ------- ----- ----- ---------
1 Congestion Control ID (CCID) SP 2 7
2 ECN Capable SP 1 9.1
3 Ack Ratio NN 2 8.3
4 Use Ack Vector SP 0 8.4
5 Mobility Capable SP 0 10.1
6 Loss Window NN 1000 6.10
7 Connection Nonce NN random 6.5.2
8 Identification Regime SP 1 6.5.1
9 Mobility ID NN 0 10.2
128-255 CCID-specific features ? ? 7.4

6.4.3. Change L Option an active connection. DCCP A sends a Change L

Kohler/Handley/Floyd Section 7.6.4. [Page 54]

INTERNET-DRAFT Expires: August 2004 February 2004

"Change R(Sequence Transition Capable, 1)" option to DCCP B to initiate a negotiation
for a
discover whether B can transition to extended sequence numbers.

Sequence Transition Capable has feature located at DCCP A. number 4, and is server-
priority. It takes one-byte Boolean values. DCCP B SHOULD respond MUST allow
transitions to a Change
option for a known feature with a Confirm R option. In special
circumstances, such as a Change option whose value extended sequence numbers when Sequence Transition
Capable/B is inappropriate
for one. It MUST NOT reset the listed feature number, connection with Reset Code
7, "Extended Sequence Numbers", under those circumstances. However,
DCCP B MAY respond instead by
ignoring the Change (with or without sending an Ignored option), allow such transitions even when Sequence Transition
Capable/B is zero. Values of two or
by resetting the connection more are reserved. New
connections start with Reason set to "Fruitless
Negotiation" or "Feature Error". Sequence Transition Capable 0 (that is, not
capable) for both endpoints.

7.7. NDP Count and Detecting Application Loss

DCCP's sequence numbers increment by one on every packet, including
non-data packets (packets that don't carry application data). This
makes DCCP A SHOULD retransmit sequence numbers suitable for detecting any network loss,
but not for detecting the
Change L option until it receives one loss of those responses. It could
send at least one application data. The NDP Count
option per round-trip time, reports the length of each burst of non-data packets. This
lets the receiving DCCP determine, for instance, every burst of loss, whether
or it
could add the Change L not application data was lost.

+--------+--------+-------- ... --------+
|00100101| Length | NDP Count |
+--------+--------+-------- ... --------+
Type=37 Len=3-5

If a DCCP endpoint's Send NDP Count feature is one (see below), then
that endpoint MUST send an NDP Count option to on every Kth packet whose
immediate predecessor was a non-data packet. Non-data packets
consist of DCCP A MAY reset packet types DCCP-Ack, DCCP-Close, DCCP-CloseReq,
DCCP-Reset, DCCP-Move, DCCP-Sync, and DCCP-SyncAck. All other
packet types are considered data packets, although not all DCCP-
Request and DCCP-Response packets will actually carry application
data.

The value stored in NDP Count equals the connection number of consecutive non-
data packets in the run immediately previous to the current packet.
Packets with Reason set no NDP Count option are considered to "Fruitless Negotiation" or
"Feature Error" if retransmission fails (no meaningful response is
received after 10 attempts or more). have NDP Count
zero.

The format NDP Count option can carry one to three bytes of data. The
smallest option format that can hold the option's
data ("Value or Values") depends on the feature's value type.
Change L options are invalid for non-negotiable features.

Kohler/Handley/Floyd/Padhye NDP Count SHOULD be used.

Kohler/Handley/Floyd Section 6.4.3. 7.7. [Page 52] 55]

INTERNET-DRAFT Expires: April August 2004 October 2003

+--------+--------+--------+--------+--------+--------
|00100001| Length |Feature#| Value or Values ...
+--------+--------+--------+--------+--------+--------
Type=33

An example Change L option follows.

33,5,1,2,3
I want to change my CC feature (feature number 1, a server-
priority feature); my preferred values February 2004

7.7.1. Usage Notes

Say that K consecutive sequence numbers are 2 and 3, missing in some burst of
loss, and the Send NDP Count feature is on. Then some application
data was lost within those sequence numbers unless the packet
following the hole contains an NDP Count option whose value is
greater than or equal to K.

For example, say that
preference order.

6.4.4. Confirm L Option the following sequence of non-data packets
(Nx) and data packets (Dx) were sent.

N0 N1 D2 N3 D4 D5 N6 D7 D8 D9 D10 N11 N12 D13

Those packets would have NDP Counts as follows.

N0 N1 D2 N3 D4 D5 N6 D7 D8 D9 D10 N11 N12 D13
- 1 2 - 1 - - 1 - - - - 1 2

NDP Count is not useful for applications that include their own
sequence numbers with their packet headers.

7.7.2. Send NDP Count Feature

The Send NDP Count feature lets DCCPs negotiate whether they should
send NDP Count options on their packets. DCCP A sends a Confirm L
"Change R(Send NDP Count, 1)" option to ask DCCP B in response to send NDP Count
options.

Send NDP Count has feature number 9, and is server-priority. It
takes one-byte Boolean values. DCCP B MUST send NDP Count options
on its non-data packets (and some of its data packets) when Send NDP
Count/B is one, although it MAY send NDP Count options even when
Send NDP Count/B is zero. Values of two or more are reserved. New
connections start with Send NDP Count 0 for both endpoints.

8. Event Processing

This section describes how DCCP connections move between states, and
which packets are sent when. Note that feature negotiation takes
place in parallel with the connection-wide state transitions
described here.

8.1. Connection Establishment

DCCP connections' initiation phase consists of a valid
Change R option three-way
handshake: an initial DCCP-Request packet sent by DCCP B. The Confirm L option will complete the negotiation for client, a feature located at DCCP A. Confirm L need not
be retransmitted, since Change R will be retransmitted as necessary.
Again,
DCCP-Response sent by the format of "Value or Values" depends on server in reply, and finally an
acknowledgement from the feature's
value type.

+--------+--------+--------+--------+--------+--------
|00100010| Length |Feature#| Value or Values ...
+--------+--------+--------+--------+--------+--------
Type=34

Example Confirm L options follow.

34,6,1,2,2,3
I have changed my CC feature (feature number 1, client, usually via a server-
priority feature) DCCP-Ack or DCCP-

Kohler/Handley/Floyd Section 8.1. [Page 56]

INTERNET-DRAFT Expires: August 2004 February 2004

DataAck packet. The client moves from the REQUEST state to value 2; my preferred values are 2
PARTOPEN, and 3,
in that preference order.

34,9,7,239,48,2,188
I have changed my Connection Nonce feature (feature number 7, a
non-negotiable feature) finally to OPEN; the 4-byte string 239,48,2,188.

6.4.5. Change R Option

DCCP A sends a Change R option server moves from LISTEN to DCCP B
RESPOND, and finally to OPEN.

Client State Server State
CLOSED LISTEN
1. REQUEST --> Request -->
2. <-- Response <-- RESPOND
3. PARTOPEN --> Ack, DataAck -->
4. <-- Data, Ack, DataAck <-- OPEN
5. OPEN <-> Data, Ack, DataAck <-> OPEN

8.1.1. Client Request

When a client decides to initiate a negotiation
for connection, it enters the
REQUEST state, chooses an initial sequence number (Section 7.2), and
sends a DCCP-Request packet using that sequence number to the
intended server.

DCCP-Request packets will commonly carry feature located at DCCP B. negotiation options
that open negotiations for various connection parameters, such as
preferred congestion control IDs for each half-connection. They may
also carry application data, but the client should be aware that the
server may not accept such data.

A client in the REQUEST state SHOULD send new DCCP-Request packets
after some timeout if no response is received. The possible responses to Change R
are analogous retransmission
strategy SHOULD be similar to those that for Change L (Confirm L, Ignored, or Reset).
As retransmitting TCP SYNs; for
instance, a first timeout on the order of a second, with Change L, DCCP an
exponential backoff timer. Each new DCCP-Request MUST increment the
Sequence Number by one, and MUST contain the same Service Code and
application data as the original DCCP-Request.

A client MAY give up after some number of DCCP-Requests. If so, it
SHOULD retransmit send a DCCP-Reset packet to the server with Reset Code 2,
"Aborted", to clean up state in case one or more of the Change R option until Requests
actually arrived.

The client leaves the REQUEST state for PARTOPEN when it receives a response, or
DCCP-Response from the retransmission times out. Again, server.

8.1.2. Service Codes

Each DCCP-Request contains a 32-bit Service Code, which identifies
the
format of "Value or Values" depends on service to which the feature's value type.

Kohler/Handley/Floyd/Padhye client application is trying to connect.
Service Codes should correspond to application services and
protocols. For example, there might be a Service Code for HTTP

Kohler/Handley/Floyd Section 6.4.5. 8.1.2. [Page 53] 57]

INTERNET-DRAFT Expires: April August 2004 October 2003

+--------+--------+--------+--------+--------+--------
|00100011| Length |Feature#| Value or Values ...
+--------+--------+--------+--------+--------+--------
Type=35

Example Change R options follow.

35,5,1,3,2
Please change your CC feature (feature number 1, a server-
priority feature); my preferred values are 3 February 2004

connections, one for FTP control connections, and 2, in that
preference order.

35,9,7,239,48,2,188
Change your Connection Nonce feature (feature number 1, a non-
negotiable feature) one for FTP data
connections. Middleboxes, such as firewalls, can use the Service
Code to identify the 4-byte string 239,48,2,188.

6.4.6. Confirm R Option

DCCP A sends application running on a Confirm R option to nonstandard port
(assuming the DCCP B in response to header has not been encrypted).

Endpoints MUST associate a valid
Change L option sent by Service Code with every DCCP B. socket, both
actively and passively opened. The Confirm R option application will complete generally
supply this Service Code. Each active socket MUST have exactly one
Service Code, while passive sockets MAY have more than one; this
might let multiple applications listen on the negotiation same port,
differentiated by Service Code. If the DCCP-Request's Service Code
doesn't match any of the server's Service Codes for the given port,
the server MUST reject the request by sending a feature located at DCCP B. Confirm R need not DCCP-Reset packet
with Reset Code 9, "Bad Service Code". A middlebox MAY also send
such a DCCP-Reset in response to packets whose Service Code is
considered unsuitable.

Service Codes should be retransmitted, since Change L will allocated by IANA. We intend for Service
Code allocation to be retransmitted as necessary.
Again, allocated to anyone who asks, first-come
first-serve, subject to the format following guidelines.

o Service Codes should be allocated one at a time, or in small
blocks. A short English description of "Value the intended service is
required to obtain a Service Code assignment, but no
specification, standards-track or Values" depends on otherwise, is necessary. IANA
should maintain an association of Service Codes to the feature's
value type.

+--------+--------+--------+--------+--------+--------
|00100100| Length |Feature#| Value
corresponding phrases.

o Users may request specific Service Code values, which should be
assigned first-come first-serve. We suggest that users request
Service Codes that can be interpreted as meaningful four-byte
ASCII strings. Thus, the "Frobodyne Plotz Protocol" might
correspond to "fdpz", or Values ...
+--------+--------+--------+--------+--------+--------
Type=36

An example Confirm R option follows.

36,6,1,2,3,2
Change your CC feature (feature the number 1, 1717858426. The canonical
interpretation of a server-priority
feature) to 2; my preferred Service Code field is numeric.

o Service Codes whose bytes each have values are 3 and 2, in that
preference order.

6.4.7. Unknown Features

If a DCCP receives a Change option referring to a feature number it
does not understand, it SHOULD respond with an Ignored option. This
informs the remote DCCP that the local DCCP does not implement set {32, 45-57,
65-90} should be reserved for international standard or standards-
track specifications, IETF or otherwise. (This set consists of
the
feature. No other action need ASCII digits, uppercase letters, and characters space, '-',
'.', and '/'.)

o Service Codes whose high-order byte equals 63 (ASCII '?') should
never be taken. (Ignored may also indicate
that allocated. These Service Codes are reserved for private
use.

o Service Code 0 should never be allocated. It represents the DCCP endpoint could not respond to
absence of a CCID-specific feature
request because the CCID was in flux; see Section 7.4.)

Kohler/Handley/Floyd/Padhye meaningful Service Code.

Kohler/Handley/Floyd Section 6.4.7. 8.1.2. [Page 54] 58]

INTERNET-DRAFT Expires: April August 2004 October 2003

6.4.8. State Diagram

These state diagrams present February 2004

This design for Service Code allocation is based on the legal transitions in a DCCP feature
negotiation. They define a DCCP's states allocation
of 4-byte identifiers for Macintosh resources, PNG chunks, and transitions with
respect to
TrueType and OpenType tables.

8.1.3. Server Response

In the negotiation second phase of a single feature it understands. There
are two diagrams, corresponding to the two endpoints: three-way handshake, the feature
location, DCCP A, and server moves
from the feature remote, DCCP B.

Each endpoint can be in one of three states, STABLE, CHANGING, and
FAILED. The STABLE LISTEN state means that a value is known for the
feature to RESPOND, and no negotiation is in progress. Every feature starts out
in the STABLE state. The CHANGING state means that sends a negotiation
started by DCCP-Response message
to the client. In this endpoint is in progress for phase, a server will often specify the feature. This is
features it would like to use, either from among those the only state client
requested, or in which retransmissions happen. Finally, the FAILED
state means that addition to those. Among these options is the other endpoint does not understand
congestion control mechanism the feature
in question.

Transitions between states are triggered by receiving server expects to use.

The receiver MAY respond to a valid DCCP-Request packet
containing some valid negotiation option, or by an application or
protocol event. Receiving with a Change option causes the new feature
value DCCP-Reset
packet to be calculated, and a Confirm option sent. The details of
this calculation, and the contents of Confirm, depend on the value
type of the feature in question. Endpoints that receive valid
Confirm options can simply trust refuse the values they contain, or they
could redo connection. Relevant Reset Codes for refusing
a connection include 8, "Connection Refused", when the feature value calculation; again, this is feature-
specific.

Kohler/Handley/Floyd/Padhye Section 6.4.8. [Page 55]

INTERNET-DRAFT Expires: April 2004 October 2003

FEATURE LOCATION STATE DIAGRAM (DCCP A)

rcv Confirm R app/protocol evt : snd Change L
: ignore +---------------------------+
+----+ | |
| v | rcv Confirm R v
+------------+ : accept value +------------+
| |<-------------------| |
| STABLE | | CHANGING |------+
| |<-------------------| | |
+------------+ rcv Change R +------------+ |
| ^ : calc new value, | ^ |
+-----+ snd Confirm L +-----+ |
rcv Change R timeout/rcv non-ack |
: calc new value, : snd Change L |
snd Confirm L |
rcv Ignored/timeout fails |
: snd Reset/ignore/other v
+----------+
| FAILED |
+----------+

FEATURE REMOTE STATE DIAGRAM (DCCP B)

rcv Confirm L app/protocol evt : snd Change R
: ignore +---------------------------+
+----+ | |
| v | rcv Confirm L v
+------------+ : calc new value +------------+
| |<-------------------| |
| STABLE | | CHANGING |------+
| |<-------------------| | |
+------------+ rcv Change L +------------+ |
| ^ : calc new value, | ^ |
+-----+ snd Confirm R +-----+ |
rcv Change L timeout/rcv non-ack |
: calc new value, : snd Change R |
snd Confirm R |
rcv Ignored/timeout fails |
: snd Reset/ignore/other v
+----------+
| FAILED |
+----------+ DCCP-
Request's Destination Port did not correspond to a DCCP implementations MUST sanity-check options' data as appropriate port open
for listening; 9, "Bad Service Code", when the feature before acting according DCCP-Request's
Service Code did not correspond to the diagram. For

Kohler/Handley/Floyd/Padhye Section 6.4.8. [Page 56]

INTERNET-DRAFT Expires: April 2004 October 2003

example, Ack Ratio takes two-byte, non-zero integer values, so a
"Confirm(Ack Ratio, 0)" option is never valid. Server-priority
features can tolerate some unknown values in service code registered with
the priority list, as
long as Destination Port; and 10, "Too Busy", when the selected value server is understood. Invalid options SHOULD
cause a transition
currently too busy to respond to requests. The server SHOULD limit
the FAILED state, with an appropriate
accompanying action, such as sending rate at which it generates these resets.

The receiver SHOULD NOT retransmit DCCP-Response packets; the sender
will retransmit the DCCP-Request if necessary. (Note that the
"retransmitted" DCCP-Request will have, at least, a reset with Reason set to
"Feature Error". different
sequence number from the "original" DCCP-Request; the receiver can
thus distinguish true retransmissions from network duplicates.) The "snd" actions request
responder will detect that the sending retransmitted DCCP-Request applies to
an existing connection because of its Source and Destination Ports.
Every valid DCCP-Request received while the server is in the RESPOND
state MUST elicit a negotiation option. They
do not force DCCP new DCCP-Response. Each new DCCP-Response MUST
increment the responder's Sequence Number by one, and MUST include
the same application data, if any, as the original DCCP-Response.

The responder MUST accept at most one piece of DCCP-Request data per
connection. In particular, the DCCP-Response sent in reply to immediately generate a packet; rather, they say
retransmitted DCCP-Request with data SHOULD contain a Data Dropped
option, in which feature option the retransmitted DCCP-Request is reported as "data
dropped due to protocol constraints" (Drop Code 0). The original
DCCP-Request SHOULD also be sent on reported in the next packet generated. A
DCCP MAY choose to generate Data Dropped option,
either in a packet, such Normal Block (if the responder accepted the data, or
there was no data), or in a Drop Code 0 Drop Block (if the responder
refused the data the first time as well).

The Data Dropped and Init Cookie options are particularly useful for
DCCP-Response packets (Sections 11.7 and 8.1.4).

Kohler/Handley/Floyd Section 8.1.3. [Page 59]

INTERNET-DRAFT Expires: August 2004 February 2004

The server leaves the RESPOND state for OPEN when it receives a DCCP-Ack, in
response to some "snd" action, rather than piggyback on another
packet. In some cases, this may be required---if adding an
valid DCCP-Ack from the client, completing the three-way handshake.

8.1.4. Init Cookie Option

+--------+--------+--------+--------+--------+--------
|00100100| Length | Init Cookie Value ...
+--------+--------+--------+--------+--------+--------
Type=36

The Init Cookie option
would bump lets a packet over DCCP server avoid having to hold any
state until the PMTU, for instance. However, three-way connection setup handshake has completed.
The server wraps up the service code, server port, and any options
it MUST
NOT generate cares about from both the DCCP-Request and DCCP-Response in an
opaque cookie. Typically the cookie will be encrypted using a packet if doing
secret known only to the server and include a cryptographic checksum
or magic value so would violate that correct decryption can be verified. When the congestion
control mechanism
server receives the cookie back in use.

Retransmissions of Change options happen according to an
exponential-backoff timer, and/or when the CHANGING DCCP realizes
that response, it can decrypt the
cookie and instantiate all the packet containing a Change option was state it avoided keeping. In the
meantime, it need not received. A
Change move from the LISTEN state.

This option is permitted in DCCP-Response, DCCP-Data, DCCP-Ack,
DCCP-DataAck, DCCP-Sync, and DCCP-SyncAck packets. The server MAY additionally be piggybacked on other packets sent
during the negotiation. After too many timer backoff events, or
when
include an explicit Ignored Init Cookie option is received, in its DCCP-Response. If so, then the CHANGING DCCP
client MUST
transition to echo the FAILED state, as shown. The CHANGING same Init Cookie option in each succeeding DCCP MUST
NOT transition to
packet until one of those packets is acknowledged, meaning the FAILED state simply because
three-way handshake has completed, or the other DCCP
seems to be ignoring connection is reset. The
server SHOULD design its Change options (for example, Init Cookie format so that Init Cookies can
be checked for tampering; it SHOULD respond to a tampered Init
Cookie option by
acknowledging resetting the packet containing connection with Reset Code 11, "Bad
Init Cookie".

The precise implementation of the options, but Init Cookie does not including a
Confirm); reordering can cause this behavior even if the endpoint
understands the options. The timeout value might initially need to be set
specified here; since Init Cookies are opaque to a small multiple of round-trip times (or 0.2 seconds, if the client, there
are no RTT
is available). Backoff should be pinned at roughly 32 RTTs; timer
failure should occur after interoperability concerns.

Init Cookies are limited to at least 12 retransmissions.

Feature negotiation options for a given feature MUST be processed most 253 bytes in
increasing order by Sequence Number. Say that length.

8.1.5. Handshake Completion

When the last processed
negotiation option for client receives a feature (F,X) came on DCCP-Response from the server, it moves
from the REQUEST state to PARTOPEN, and completes three-way
handshake by sending a DCCP-Ack packet with
sequence number S. Then any negotiation options on received packets
with Sequence Number less than or equal to S the server. The PARTOPEN
state represents that the client isn't sure whether the server has
received any of its DCCP-Acks. The client MUST be ignored. NOT send DCCP-Data
packets while it remains in PARTOPEN. This
requirement MAY be implemented per-feature, or implementations MAY
compare against a single Sequence Number---the most recent
negotiation option processed for any feature. Feature negotiation
options on safely reordered is because DCCP-Data
packets (with last-negotiation-seqno < S
< GSR) SHOULD be accepted, to provide some robustness against
reordering.

Simultaneous negotiation problems can arise if value preferences
change too frequently, particularly for server-priority features. A

Kohler/Handley/Floyd/Padhye lack Acknowledgement Numbers, so the server can't tell from

Kohler/Handley/Floyd Section 6.4.8. 8.1.5. [Page 57] 60]

INTERNET-DRAFT Expires: April August 2004 October 2003

DCCP endpoint MUST NOT change February 2004

a DCCP-Data packet whether the client saw its value preferences while in DCCP-Response.
Furthermore, if the
CHANGING state: it DCCP-Response included an Init Cookie, that Init
Cookie MUST instead complete any extant negotiation,
then open a new one.

If be included on every packet sent in PARTOPEN.

The single DCCP-Ack sent when entering the result PARTOPEN state might, of some feature negotiation is
course, be dropped by the network. The client SHOULD ensure that
some packet gets through eventually. The preferred mechanism would
be a feature has an
unacceptable value---for example, for delayed-ack-like 200-millisecond timer, set every time a server-priority feature,
none of the client's choices were acceptable to the server, packet
is transmitted in PARTOPEN. If this timer goes off and the
prior value client
is unacceptable to still in PARTOPEN, the client---a DCCP endpoint MAY client generates another DCCP-Ack and
backs off the timer. If the client remains in PARTOPEN for more
than 4MSL, it SHOULD reset the connection, connection with DCCP-Reset Reason set to "Fruitless
Negotiation". Reset Code 2,
"Aborted".

The CHANGING client leaves the PARTOPEN state signals that for OPEN when it receives a
packet other than DCCP-Response or DCCP-Reset from the relevant feature's value is server.

8.2. Data Transfer

In the central, data transfer phase of the connection, both server
and client are in
flux. the OPEN state.

DCCP MAY change its behavior when certain features are
CHANGING---for example, by refusing to send data until reentering
STABLE.

6.4.9. Streamlined Negotiation

This section provides guidance for implementations that do not wish A sends DCCP-Data and DCCP-DataAck packets to implement full feature negotiation, although general-purpose DCCP
implementations SHOULD implement negotiation fully.

Minimal DCCP implementations, such as those for embedded devices,
might force all negotiation B due to take place
application events on host A. These packets are congestion-
controlled by the first packet
exchange. The DCCP-Request would contain Change R options CCID for all
server-located features, and Change L options the A-to-B half-connection. In contrast,
DCCP-Ack packets sent by DCCP A are controlled by the CCID for all client-located
features; the DCCP-Response would Confirm each of these requests,
B-to-A half-connection. Generally, DCCP A will piggyback
acknowledgement information on DCCP-Data packets when acceptable,
creating DCCP-DataAck packets. DCCP-Ack packets are used when there
is no data to send from DCCP A to DCCP B, or
reset when the connection if any Change was unexpected or unacceptable.
Changes for CCID-specific features MUST follow Changes for congestion
state of the
Congestion Control ID feature A-to-B CCID will not allow data to be sent.

The DCCP-Move, DCCP-Sync, and DCCP-SyncAck packets will also occur
in the option list, since options data transfer phase. DCCP-Move handling is discussed in
Section 14, and some cases causing DCCP-Sync generation are
processed
discussed in order. Once the connection Section 7.5. One important distinction between DCCP-
Sync packets and other packet types is set up, minimal
implementations that DCCP-Sync elicits an
immediate acknowledgement. On receiving a valid DCCP-Sync packet, a
DCCP endpoint MUST immediately generate and send a DCCP-SyncAck in
response; and the Acknowledgement Number on that DCCP-SyncAck MUST
equal the Sequence Number of the DCCP-Sync.

A particular DCCP implementation might respond decide to all initiate feature
negotiation options
with Ignored, except only once the OPEN state was reached, in which case it
might not allow data transfer until some time later. Data received
during that even minimal implementations time SHOULD
support "Change R(Ack Ratio)" be rejected and "Confirm L(Ack Ratio)".

Even general-purpose implementations might refuse reported using a Data
Dropped Drop Block with Drop Code 0.

Kohler/Handley/Floyd Section 8.2. [Page 61]

INTERNET-DRAFT Expires: August 2004 February 2004

8.3. Termination

DCCP connection termination uses a handshake consisting of an
optional DCCP-CloseReq packet, a DCCP-Close packet, and a DCCP-Reset
packet. The server moves from the OPEN state, possibly through the
CLOSEREQ state, to CLOSED; the client moves from OPEN through
CLOSING to TIMEWAIT, and after 2MSL wait time, to CLOSED.

The sequence DCCP-CloseReq, DCCP-Close, DCCP-Reset is used when the
server decides to close the connection, but doesn't want to hold
TIMEWAIT state:

Client State Server State
OPEN OPEN
1. <-- CloseReq <-- CLOSEREQ
2. CLOSING --> Close -->
3. <-- Reset <-- CLOSED
4. TIMEWAIT
5. CLOSED

A shorter sequence occurs when the client decides to renegotiate close the
connection.

Client State Server State
OPEN OPEN
1. CLOSING --> Close -->
2. <-- Reset <-- CLOSED
3. TIMEWAIT
4. CLOSED

Finally, the
Congestion Control ID feature in server can decide to hold TIMEWAIT state:

Client State Server State
OPEN OPEN
1. <-- Close <-- CLOSING
2. CLOSED --> Reset -->
3. TIMEWAIT
4. CLOSED

In all cases, the middle receiver of the connection, by
responding to "Change(CCID)" options with Ignored.

6.5. Identification Options

The Identification options provide DCCP-Reset packet holds TIMEWAIT
state for the connection. As in TCP, TIMEWAIT state, where an
endpoint quietly preserves a way socket for DCCP endpoints to
confirm each others' identities, even 2MSL (4 minutes) after changes of address
(Section 10) or long bursts of loss its
connection has closed, ensures that get no connection duplicating the endpoints out of
sync (Section 5.2). Again, DCCP as specified here does not provide
cryptographic security guarantees,
current connection's source and attackers that destination addresses and ports can see every
packet are still capable of manipulating DCCP connections
inappropriately, but
start up while old packets might remain in the Identification options make it more

Kohler/Handley/Floyd/Padhye network.

Kohler/Handley/Floyd Section 6.5. 8.3. [Page 58] 62]

INTERNET-DRAFT Expires: April August 2004 October 2003

difficult for some kinds February 2004

The termination handshake proceeds as follows. The receiver of attacks a
valid DCCP-CloseReq packet MUST respond with a DCCP-Close packet;
that receiving endpoint will expect to succeed. hold TIMEWAIT state after
later receiving a DCCP-Reset. The Identification option is used to prove an endpoint's identity,
while receiver of a Challenge option elicits an Identification from the other
endpoint. An Identification Regime determines how the
Identifications are calculated. In valid DCCP-Close
packet MUST respond with a DCCP-Reset packet, with Reset Code 1,
"Closed"; the default MD5 Regime, endpoint that originally sent the
calculation involves an MD5 hash over DCCP-Close will hold
TIMEWAIT state. The endpoint that receives a valid DCCP-Reset
packet data and two Connection
Nonces, either exchanged at will hold TIMEWAIT state for the beginning of connection.

A DCCP-Reset packet completes every DCCP connection, whether the connection
termination is clean (due to application close; Reset Code 1,
"Closed") or
implicitly agreed upon.

6.5.1. Identification Regime Feature

Identification Regime unclean. Unlike TCP, which has feature number 8. The ID Regime feature
located at two distinct
termination mechanisms (FIN and RST), DCCP B specifies ends all connections in a
uniform manner. This is justified because some responses to
connection termination close are the algorithm same no matter whether
termination was clean. For instance, the endpoint that DCCP B will use receives a
valid DCCP-Reset should hold TIMEWAIT state for
its Identification options, and the connection.
Processors that DCCP A will use for its
Challenge options. Each endpoint must keep track of both its ID
regime and, via the ID Regime feature, distinguish between clean and unclean
termination can examine the regime used by Reset Code. DCCP-Reset packets MUST NOT
be generated in response to received DCCP-Reset packets. DCCP
implementations generally transition to the other
endpoint. ID Regime is a server-priority feature.

The value of ID Regime is CLOSED state after
sending a two-byte number, so valid Confirm DCCP-Reset packet.

Endpoints in the CLOSEREQ and
Change(ID Regime) options take at least five bytes. Change options
MAY list multiple ID Regimes CLOSING states MUST retransmit DCCP-
CloseReq and DCCP-Close packets, respectively, until leaving those
states. The retransmission timer should initially be set to go off
in descending order of preference.
This document defines two ID Regimes:

ID Regime Meaning
--------- -------
0 Null Regime
1 MD5 Regime (default)

In the Null Regime, every Identification RTTs, or Challenge option 0.4 seconds if the RTT is
invalid. The Null Regime makes it impossible for endpoints to get not known, and should back into sync after bursts of loss larger
off to not less than two-thirds of the
Loss Window (Section In the MD5 Regime, which once every 64 RTTs if no relevant response is
received.

Only the default, valid
Identification and Challenge options contain an MD5 hash of server can send a DCCP-CloseReq packet or enter the
Connection Nonce feature values with some
CLOSEREQ state.

8.3.1. Abnormal Termination

DCCP endpoints generate DCCP-Reset packets to terminate connections
abnormally; a DCCP-Reset packet data. Applications
preferring different security guarantees, particularly around
mobility issues, may prefer be generated from any state.
However, a DCCP endpoint in the CLOSED or LISTEN state may not have
a proper sequence number available to implement another identification
algorithm and allocate send a new ID Regime value for it.

If Reset. In these cases,
it MUST set the endpoints cannot agree on mutually acceptable ID Regimes, Reset's Sequence Number to zero. Resets sent in the
connection SHOULD
CLOSED, LISTEN, and TIMEWAIT states often use Reset Code 3, "No
Connection". Resets sent in the REQUEST or RESPOND states often use
Reset Code 4, "Packet Error".

8.4. DCCP State Diagram

The most common state transitions discussed above can be reset due to "Fruitless Negotiation".

6.5.2. Connection Nonce Feature

Connection Nonce has feature number 7. summarized
in the following state diagram. The Connection Nonce feature
located at DCCP B diagram is illustrative; the value of DCCP A's connection nonce, a value
used by Identification Regime 1. Each endpoint SHOULD keep track of

Kohler/Handley/Floyd/Padhye

Kohler/Handley/Floyd Section 6.5.2. 8.4. [Page 59] 63]

INTERNET-DRAFT Expires: April August 2004 October 2003

its own nonce and, via the Connection Nonce feature, the other
endpoint's nonce. Connection Nonce is a non-negotiable feature.

The Connection Nonce feature takes arbitrary values of at least 4
bytes long. A Change or Confirm(Connection Nonce) option therefore
takes at least 7 bytes.

Connection Nonce defaults to a random 8-byte string. To prevent
spoofing, this string MUST NOT have any trivially predictable value. February 2004

text in Section 8.5 and elsewhere should be considered definitive.
For example, it MUST NOT be set deterministically there are arcs (not shown) from every state except
CLOSED to zero, and it
SHOULD change TIMEWAIT, contingent on every connection. DCCP endpoints MAY, however,
exchange Connection Nonces via some mechanism other than the
plaintext, snoopable Connection Nonce option. For example, two
DCCPs might exchange nonces over a secure channel; or, assuming
neither endpoint is behind a network address translator, they might
encrypt the source and destination ports with a shared secret key.

6.5.3. Identification Option

The Identification option serves as confirmation that receipt of a valid DCCP-Reset.

+---------------------------+ +---------------------------+
| v v |
| +----------+ |
| +-------------+ CLOSED +------------+ |
| | +----------+ active | |
| | passive open | |
| | open snd Request | |
| v v |
| +----------+ +----------+ |
| | LISTEN | | REQUEST | |
| +----+-----+ +----+-----+ |
| | rcv Request rcv Response | |
| | snd Response snd Ack | |
| v v |
| +----------+ +----------+ |
| | RESPOND | | PARTOPEN | |
| +----+-----+ +----+-----+ |
| | rcv Ack/DataAck rcv packet was
sent by | |
| | | |
| | +----------+ | |
| +------------>| OPEN |<-----------+ |
| +--+-+--+--+ |
| server active close | | | active close |
| snd CloseReq | | | or rcv CloseReq |
| | | | snd Close |
| | | | |
| +----------+ | | | +----------+ |
| | CLOSEREQ |<---------+ | +--------->| CLOSING | |
| +----+-----+ | +----+-----+ |
| | rcv Close | | |
| | snd Reset | rcv Reset | |
|<---------+ | v |
| rcv Close | +----+-----+ |
| snd Reset | | TIMEWAIT | |
| | +----+-----+ |
+-----------------------------+ | |
+-----------+
2MSL timer expires

8.5. Pseudocode

This section presents an endpoint involved in the initiation of algorithm describing the processing steps a
DCCP
connection. It is permitted in any DCCP packet, but endpoint must go through when it might receives a packet. A DCCP

Kohler/Handley/Floyd Section 8.5. [Page 64]

INTERNET-DRAFT Expires: August 2004 February 2004

implementation need not be
useful until implement the endpoints have exchanged security information such algorithm as connection nonces. The option takes the following form:

+--------+--------+--------+--------+--------+--------
|00101011| Length | Identification Data ...
+--------+--------+--------+--------+--------+--------
Type=43

The particular data included in an Identification option sent by
DCCP A depends on the ID Regime in force for the A-to-B sequence,
which it is the value of the ID Regime feature located at DCCP B. The
remainder described
here, but any implementation MUST generate observable effects
(meaning packets) exactly as indicated by this pseudocode, except
where allowed otherwise by another part of this section describes ID Regime 1, the default MD5
Regime. document.

The Identification data provided for received packet is written as P, the MD5 Regime consists of a
16-byte MD5 digest of: socket as S. Socket variables:
S.SWL - sequence number window low
S.SWH - sequence number window high
S.AWL - acknowledgement number window low
S.AWH - acknowledgement number window high
S.ISS - initial sequence number sent
S.ISR - initial sequence number received
S.OSR - first OPEN sequence number received
S.GSS - greatest sequence number sent
S.GSR - greatest valid sequence number received
S.GAR - greatest acknowledgement number received; initialized to S.ISS
"Send packet" actions always use, and increment, S.GSS.

First, check the 32-bit words in header basics;
If the DCCP header that
include checksum is incorrect, drop packet and return.
If the Sequence packet type is not understood, drop packet and Acknowledgement Numbers (this will be words
3-4 return.
If Data Offset is too small for packet type, or 3-6, depending on whether sequence numbers are extended); the
value of the sender's Connection Nonce; too large for packet,
drop packet and return.

Second, process DCCP-Move;
If P.type == Move,
Look up the value of the other
endpoint's Connection Nonce, Mobility ID in that order. The total length of the
option is therefore 18 bytes, table; get socket.
If socket exists && P.seqno >= S.SWL && P.ackno <= S.AWH
&& P.ackno >= S.ISS && S.state >= PARTOPEN && S.state < TIMEWAIT,
Process options
Set socket to point at new address/ports
Add reference to new address/ports
Set timer to remove old address/ports after 2MSL
Choose new Mobility ID, add to table
Send DCCP-Sync[Change L[Mobility ID, new ID]]
Update S.GSR, S.SWL, S.SWH
Drop packet and the option may only be provided on
packets that contain Acknowledgement Numbers, such as DCCP-Ack.
Inclusion of the two Connection Nonces ensures that attackers cannot
fake an Identification Option, return
Otherwise,
Drop packet and return

Third, check ports and process TIMEWAIT state;
Look up flow ID; get socket.
If no socket, or S.state == TIMEWAIT,
Generate Reset(No Connection) unless they snooped on the beginning
of the connection when nonces are exchanged. (No mechanism protects

Kohler/Handley/Floyd/Padhye P.type == Reset
Drop packet and return

Fourth, process LISTEN state;
If S.state == LISTEN,

Kohler/Handley/Floyd Section 6.5.3. 8.5. [Page 60] 65]

INTERNET-DRAFT Expires: April August 2004 October 2003

against snoopers who know Connection Nonces, since DCCP as specified February 2004

If P.type == Request,
/* Init Cookie processing would go here does not provide strong cryptographic security guarantees; see
Section 16.) Inclusion of the Sequence */
Set S := new socket for this port pair
S.state = RESPOND
Choose S.ISS (initial seqno)
Set S.ISR, S.GSR, S.SWL, S.SWH from packet
Continue (with S.state == RESPOND)
Otherwise,
Generate Reset(No Connection) unless P.type == Reset
Drop packet and Acknowledgement Numbers
protects against replay attacks within the connection.

To check an Identification option's value, the receiver simply
calculates the MD5 digest itself return

Fifth, process Reset;
If P.type == Reset,
If S.GAR <= P.ackno <= S.AWH
&& (P.seqno == 0 || P.seqno > S.GSR || S.state == REQUEST),
Tear down connection
S.state := TIMEWAIT
Set TIMEWAIT timer
Drop packet and compares that against the
option data. The MD5 calculation can be expensive, so an attacker
could conceivably disable a DCCP endpoint by sending it a flood of
invalid packets with bad Identification options. Rate limits
described in Sections 5.2 return
Otherwise (sequence numbers out of whack),
Drop packet and 10 mitigate this issue. The receiver
MAY ignore an Identification option if it occurs on a return

Sixth, process REQUEST state;
If S.state == REQUEST,
If P.type == Response && S.AWL <= P.ackno <= S.AWH,
Set S.GSR, S.ISR, S.SWL, S.SWH
Otherwise,
Generate Reset(Packet Error)
Drop packet that
would otherwise be considered valid.

Example C code for constructing the option's value before
transmitting a and return

Seventh, process Sync sequence numbers;
If P.type == Sync || P.type == SyncAck,
If S.AWL <= P.ackno <= S.AWH and P.seqno >= S.SWL,
Update S.GSR, S.SWL, S.SWH
Otherwise,
Drop packet follows.

unsigned char *packet_data;
int packet_length;
int id_option_offset; /* offset of option in packet_data */

const unsigned char *my_nonce, *other_nonce;
int my_nonce_length, other_nonce_length;

MD5_CTX md5_context;

MD5_Init(&md5_context);
MD5_Update(&md5_context, packet_data + 8, 8);
/* assuming 24-bit and return

Eighth, check sequence numbers */
MD5_Update(&md5_context, my_nonce, my_nonce_length);
MD5_Update(&md5_context, other_nonce, other_nonce_length);
packet_data[id_option_offset] = 42; /* option value */
packet_data[id_option_offset+1] = 18; numbers;
If S.SWL <= P.seqno <= S.SWH
&& (P.ackno does not exist || S.AWL <= P.ackno <= S.AWH),
Update S.GSR, S.GAR, S.SWL, S.SWH
Otherwise,
Send Sync packet acknowledging P.seqno
Drop packet and return

Ninth, check packet type;
If (S.is_server && P.type == CloseReq)
|| (S.is_server && P.type == Response)

Kohler/Handley/Floyd Section 8.5. [Page 66]

INTERNET-DRAFT Expires: August 2004 February 2004

|| (S.is_client && P.type == Request)
|| (S.state >= OPEN && P.type == Request && P.seqno >= S.OSR)
|| (S.state >= OPEN && P.type == Response && P.seqno >= S.OSR)
|| (S.state == RESPOND && P.type == Data),
Send Sync packet acknowledging P.seqno
Drop packet and return

Tenth, process options;
/* option length may involve resetting connection, etc. */
MD5_Final(packet_data + id_option_offset + 2, &md5_context);

6.5.4. Challenge Option

This option informs the receiving DCCP that one of its packets was
ignored, and
Mark packet as "received" for acknowledgement purposes
On processing Confirm R(Mobility ID),
Check that succeeding packets will be ignored until the
endpoint sends a confirmed Mobility ID is correct Identification option. The receiving DCCP
SHOULD
If a DCCP-Move was recently processed,
Remove any old Mobility ID from table

Eleventh, process RESPOND state;
If S.state == RESPOND,
If P.type == Request,
Send Response
Otherwise,
S.OSR := P.seqno
S.state := OPEN

Twelfth, process REQUEST state;
If S.state == REQUEST,
S.state := PARTOPEN
/* Do not send Data packets in PARTOPEN; furthermore, include an Identification option Init
Cookie on the next every packet it sends.
The option takes the following form:

Kohler/Handley/Floyd/Padhye */
Set PARTOPEN timer

Thirteenth, process PARTOPEN state;
If S.state == PARTOPEN,
If P.type == Response,
Send Ack
Otherwise,
S.OSR := P.seqno
S.state := OPEN

Fourteenth, process CloseReq;
If P.type == CloseReq && S.state < CLOSEREQ,
Generate Close
S.state := CLOSING
Set CLOSING timer

Fifteenth, process Close;
If P.type == Close,
Generate Reset(Closed)
Tear down connection

Kohler/Handley/Floyd Section 6.5.4. 8.5. [Page 61] 67]

INTERNET-DRAFT Expires: April August 2004 October 2003

+--------+--------+--------+--------+--------+--------
|00101100| Length | Identification Data ...
+--------+--------+--------+--------+--------+--------
Type=44

The Identification Data sent with a Challenge option depends on the
active Identification Regime. For the default MD5 Regime (Regime
1), the Identification Data on a February 2004

Drop packet sent by and return

Sixteenth, process Sync;
If P.type == Sync,
Generate SyncAck

Seventeenth, process data.
Do not deliver data from more than one Request or Response

9. Checksums

DCCP B is the same uses a header checksum to protect its header against
corruption. Generally, this checksum covers any application data as that for an Identification option sent by
well. However, DCCP B. The receiver
SHOULD ignore a Challenge option, and the packet applications can request that the Challenge
option contains, if header
checksum cover only part of the Identification Data is incorrect. The
purpose application data, or perhaps no
application data at all. Link layers may then reduce their
protection on unprotected parts of DCCP packets. For some noisy
links, and applications that can tolerate corruption, this mechanism can
greatly improve delivery rates and perceived performance.

If checksum coverage is to prevent denial-of-service attacks
where an attacker could cause the receiver to send many complete, packets with
expensive-to-compute Identification options, since the receiver MAY
ignore Challenge options for some time after receiving an invalid
Challenge.

If, after several Challenge options, a DCCP is unable to elicit corrupt application
data must be treated as network losses, thus incurring a
valid Identification loss
response from its partner, it MAY reset the connection sender's congestion control mechanism. Such a
heavy-duty response may unfairly penalize connections on links with Reason "Unanswered Challenge".

6.6. Init Cookie Option

This option is permitted in DCCP-Response, DCCP-Data, DCCP-Ack, and
DCCP-DataAck messages. The server MAY include an Init Cookie option
in its DCCP-Response. If so, then the client MUST echo the same
Init Cookie option in each succeeding DCCP packet until one of those
packets is acknowledged or the connection
high background corruption. It is reset. The server
SHOULD design its Init Cookie format so to the application's benefit to
report corruption losses differently from network losses.
Therefore, even applications that Init Cookies demand correct data can be
checked for tampering; it SHOULD respond to an tampered Init Cookie
option make use
of reduced checksum coverage, by resetting including a Data Checksum option.
Data Checksum holds a strong checksum of the connection with Reason set to "Bad Init
Cookie". application data. The purpose
combination of this option is to allow a reduced checksum coverage and Data Checksum can
detect application data corruption, but report it as corruption, not
congestion, via Data Dropped options (see Section 11.7).

Reduced checksum coverage introduces some security considerations;
see Section 19.2. See Appendix B.1 for further motivation and
discussion. DCCP's implementation of reduced checksum coverage was
inspired by UDP-Lite [UDP-LITE].

9.1. Header Checksum Field

DCCP server to avoid having
to hold any state until uses the three-way connection setup handshake has
completed. TCP/IP checksum algorithm. The server wraps up Checksum field in the service code, server port, and
any options it cares about from both
DCCP generic header (see Section 5.1) equals the DCCP-Request and DCCP-
Response 16 bit one's
complement of the one's complement sum of all 16 bit words in an opaque cookie. Typically the cookie will be
encrypted using
DCCP header, DCCP options, a secret known only to pseudoheader taken from the server and include a
cryptographic checksum or magic value so that correct decryption can
be verified. When network-
layer header, and, depending on the server receives value of the cookie back in Checksum Coverage
field, some or all of the
response, it can decrypt application data. When calculating the cookie and instantiate all
checksum, the state it
avoided keeping.

The precise implementation Checksum field itself is treated as 0. If a packet
contains an odd number of the Init Cookie does not need header and text bytes to be
specified here; since Init Cookies are opaque to the client, there
are no interoperability concerns.

Kohler/Handley/Floyd/Padhye checksummed, 8

Kohler/Handley/Floyd Section 6.6. 9.1. [Page 62] 68]

INTERNET-DRAFT Expires: April August 2004 October 2003

Init Cookies February 2004

zero bits are limited added on the right to at most 253 bytes in length.

+--------+--------+--------+--------+--------+--------
|00100101| Length | Init Cookie Value ...
+--------+--------+--------+--------+--------+--------
Type=37

6.7. Timestamp Option

This option form a 16 bit word for checksum
purposes. The pad byte is permitted in any DCCP not transmitted as part of the packet.

The pseudoheader is calculated as for TCP. For IPv4, it is 96 bits
long, and consists of the IPv4 source and destination addresses, the
IP protocol number for DCCP (padded on the left with 8 zero bits),
and the DCCP length as a 16-bit quantity (the length of the
option DCCP
header with options, plus the length of any data); see Section 3.1
of [RFC 793]. For IPv6, it is 6 bytes.

+--------+--------+--------+--------+--------+--------+
|00101001|00000110| Timestamp Value |
+--------+--------+--------+--------+--------+--------+
Type=41 Length=6

The four bytes 320 bits long, and consists of option data carry the timestamp of this packet in
some undetermined form. A
IPv6 source and destination addresses, the DCCP receiving a Timestamp option SHOULD
respond with length as a Timestamp Echo option 32-bit
quantity, and the IP protocol number for DCCP (padded on the next packet it sends.

6.8. Elapsed Time Option

This option is permitted left
with 24 zero bits); see Section 8.1 of [RFC 2460].

Packets with invalid header checksums MUST be ignored. In
particular, their options MUST NOT be processed.

9.2. Header Checksum Coverage Field

The Checksum Coverage field in any the DCCP packet that contains an
Acknowledgement Number. It indicates how much time, in tenths generic header (see Section
5.1) specifies what parts of
milliseconds, has elapsed since the packet being acknowledged---the
packet with are covered by the given Acknowledgement Number---was received. Checksum
field, as follows:

CsCov = 0 The
option may take 4 or 6 bytes, depending Checksum field covers the DCCP header, DCCP
options, network-layer pseudoheader, and all
application data in the packet, possibly padded on
the size right with zeros to an even number of bytes.

CsCov = 1-15 The Checksum field covers the Elapsed
Time value. Elapsed Time helps correct round-trip time estimates
when the gap between receiving a packet DCCP header, DCCP
options, network-layer pseudoheader, and acknowledging that
packet may be long---in CCID 3, for example, where acknowledgements
are sent infrequently.

+--------+--------+--------+--------+
|00101110|00000100| Elapsed Time |
+--------+--------+--------+--------+
Type=46 Len=4

+--------+--------+--------+--------+--------+--------+
|00101110|00000110| Elapsed Time |
+--------+--------+--------+--------+--------+--------+
Type=46 Len=6

The option data, Elapsed Time, represents an estimated upper bound
on the amount initial
(CsCov-1)*4 bytes of time elapsed since the packet being acknowledged
was received, with units of tenths packet's application data.

Thus, if CsCov is 1, none of milliseconds. If Elapsed Time the application data is protected by
the header checksum. The value (CsCov-1)*4 MUST be less than a second, or
equal to the first, smaller form length of the option SHOULD

Kohler/Handley/Floyd/Padhye Section 6.8. [Page 63]

INTERNET-DRAFT Expires: April 2004 October 2003

be used. Elapsed Times of more than 6.5535 seconds application data. Packets with invalid
CsCov values MUST be sent
using the second form of the option. DCCP endpoints ignored; in particular, their options MUST NOT report
Elapsed Times that are significantly larger
be processed. The meanings of values other than the true elapsed
times. A connection MAY 0 and 1 should be reset, with Reason set to "Aggression
Penalty", if one endpoint determines that the
considered experimental.

Values other than 0 specify that corruption is reporting a
much-too-large Elapsed Time.

Elapsed Time is measured acceptable in tenths of milliseconds as a compromise
between two conflicting goals. First, it provides enough
granularity to reduce rounding error when measuring elapsed time
over fast LANs. Second, Elapsed Time allows most reasonable elapsed
times to fit into two bytes some or
all of the DCCP packet's application data.

6.9. Timestamp Echo Option

This In fact, DCCP cannot
even detect corruption in areas not covered by the header checksum,
unless the Data Checksum option is permitted in used. Applications should not
make any assumptions about the correctness of received data not
covered by the checksum, and should if necessary introduce their own
validity checks.

A DCCP packet, as long application interface should let sending applications suggest
a value for CsCov for sent packets, defaulting to 0 (full coverage).

Kohler/Handley/Floyd Section 9.2. [Page 69]

INTERNET-DRAFT Expires: August 2004 February 2004

It should also let receiving applications refuse delivery of packets
with checksum coverage less than a value provided by the
application; by default, only packets with fully-covered application
data should be accepted. (Note that, for short packets, application
data might be fully covered by a nonzero Checksum Coverage value.)
Lower layers that support partial error detection MAY use the
Checksum Coverage field as a hint of where errors do not need to be
detected. Lower layers MUST use a strong error detection mechanism
to detect at least one
packet carrying errors that occur in the Timestamp option has been received. Generally,
a DCCP endpoint should send one Timestamp Echo option for each
Timestamp option it receives; sensitive part of the
packet, and it should send that option as soon
as is convenient. discard damaged packets. The length sensitive part consists of
the option is bytes between 6 the first byte of the IP header and 10
bytes, depending the last byte
identified by Checksum Coverage.

For more details on whether Elapsed Time is included application and how large
it is.

+--------+--------+--------+--------+--------+--------+
|00101010|00000110| Timestamp Echo |
+--------+--------+--------+--------+--------+--------+
Type=42 Len=6

+--------+--------+------- ... -------+--------+--------+
|00101010|00001000| Timestamp Echo | Elapsed Time |
+--------+--------+------- ... -------+--------+--------+
Type=42 Len=8 (4 bytes)

+--------+--------+------- ... -------+------- ... -------+
|00101010|00001010| Timestamp Echo | Elapsed Time |
+--------+--------+------- ... -------+------- ... -------+
Type=42 Len=10 (4 bytes) (4 bytes) lower-layer interface issues
relating to partial checksumming, see [UDP-LITE].

9.3. Data Checksum Option

The first four bytes of Data Checksum option data, Timestamp Echo, carry holds a
Timestamp Value taken from 32-bit CRC-32c cyclic redundancy-
check code of a preceding received Timestamp option.
Usually, this will be the last packet that was received---the packet
indicated by the Acknowledgement Number, if any---but DCCP packet's application data.

+--------+--------+--------+--------+--------+--------+
|00101100|00000110| CRC-32c |
+--------+--------+--------+--------+--------+--------+
Type=44 Length=6

Data Checksum is intended for packets containing application data,
such as DCCP-Request, DCCP-Response, DCCP-Data, and DCCP-DataAck,
but it might may be a
preceding included on any packet. The Elapsed Time field is similar to the value stored in the Elapsed
Time option. If present, it indicates sending DCCP computes the amount
CRC of time elapsed
since receiving the packet whose timestamp is being echoed. This
time MUST be bytes comprising the application data and stores it in tenths of milliseconds. Elapsed Time
the option data. The CRC-32c algorithm used for Data Checksum is meant to

Kohler/Handley/Floyd/Padhye Section 6.9. [Page 64]

INTERNET-DRAFT Expires: April 2004 October 2003

help
the Timestamp sender separate same as that used for SCTP [RFC 3309]; note that the network round-trip time from CRC-32c of
zero bytes of data equals zero. The DCCP header checksum will cover
the Timestamp receiver's processing time. This may be particularly
important for CCIDs where acknowledgements are sent infrequently, Data Checksum option, so
that there might the data checksum must be considerable delay between computed
before the header checksum.

The receiving a Timestamp
option DCCP SHOULD compute the received application data's
CRC-32c using the same algorithm as the sender, and sending compare the corresponding Timestamp Echo. A missing
Elapsed Time field is equivalent
result and the Data Checksum value. If the values differ, the
packet's application data MUST be dropped, and reported using a Data
Dropped option as dropped due to corruption (Drop Code 3). However,
DCCP MAY provide an Elapsed Time of zero. The
smallest version API through which the receiving application
could request delivery of known-corrupt data. When that API is
active, the option packet's data SHOULD be used that can hold delivered, but reported as
delivered corrupt (Drop Code 7) using a Data Dropped option. In
either case, the
relevant Elapsed Time value.

6.10. Loss Window packet will be reported as Received or Received ECN
Marked by Ack Vector or similar options.

Kohler/Handley/Floyd Section 9.3. [Page 70]

INTERNET-DRAFT Expires: August 2004 February 2004

9.3.1. Check Data Checksum Feature

Loss Window has feature number 6.

The Loss Window Check Data Checksum feature located
at DCCP B is the width of the window lets a sending DCCP B uses to determine
whether packets from DCCP A are valid. Packets outside this window
will be dropped by DCCP B as old duplicates or spoofing attempts;
see Section 5.2 for more information. not its partner can check Data Checksum options. DCCP A
sends a Mandatory "Change R(Loss
Window, W)" R(Check Data Checksum, 1)" option to
DCCP B to set DCCP B's Loss Window require B to W. Loss
Window is non-negotiable.

The Loss Window check Data Checksum options (the connection
will be reset if DCCP B cannot).

Check Data Checksum has feature number 10, and is server-priority.
It takes 3- or 6-byte integer values, like one-byte Boolean values. DCCP
sequence numbers. Change and Confirm B MUST check any received
Data Checksum options for Loss Window are
therefore either 6 when Check Data Checksum/B is one, although it
MAY check them even when Check Data Checksum/B is zero. Values of
two or 9 bytes long.

Loss Window defaults more are reserved. New connections start with Check Data
Checksum 0 for both endpoints.

9.3.2. Usage Notes

Internet links must normally apply strong integrity checks to 1000 the
packets they transmit [UDP-LITE] [LINK BCP]. Data Checksum is
redundant for new connections. The Loss Window
value DCCP packets whose integrity is checked by every link
they traverse. This is the total width default case when the DCCP header's
Checksum Coverage value equals zero (full coverage). However, the
DCCP Checksum Coverage value might not be zero. By setting partial
Checksum Coverage, the application indicates that it can tolerate
corruption in the unprotected part of the loss window. The receiver positions application data.
Recognizing this, link layers may reduce the loss window asymmetrically around GSR, strength of their error
detection and/or correction when transmitting this unprotected part,
which can significantly increase the greatest sequence
number received, with one-third probability of the loss window width (rounded
down) reserved for GSR and older sequence numbers and two-thirds
reserved for newer sequence numbers. See Section 5.2.

7. endpoint
receiving corrupt data. Data Checksum lets the receiver detect any
ensuing corruption.

10. Congestion Control IDs

Each congestion control mechanism supported by DCCP is assigned a
congestion control identifier, or CCID: a number from 0 to 255.
During connection setup, and optionally thereafter, the endpoints
negotiate their congestion control mechanisms by negotiating the
values for their Congestion Control ID features. Congestion Control
ID has feature number 1. The feature located at DCCP A is CCID/A value equals the CCID in use
for the A-to-B half-connection. DCCP B sends a "Change R(CCID, K)"
option to DCCP A to ask DCCP A to use CCID K for its data packets.

CCID is a server-priority feature.

The data byte of Congestion Control ID feature feature, so CCID negotiation options
form a can
list of multiple acceptable CCIDs, sorted in descending order of
priority. For example, the option "Change R(CCID, 1 2 3)" asks the
receiver to use CCID 1 for its packets, although CCIDs 2 and 3 are
also acceptable. (This corresponds to the bytes "35, 6, 1, 1, 2,
3": Change R option (35), option length (6), feature ID (1), CCIDs

Kohler/Handley/Floyd/Padhye

Kohler/Handley/Floyd Section 7. 10. [Page 65] 71]

INTERNET-DRAFT Expires: April August 2004 February 2004 October 2003

(1, 2, 3).) Similarly, "Confirm L(CCID, 1, 1 2 3)" tells the
receiver that the sender is using CCID 1 for its packets, but that
CCIDs 2 or 3 might also be acceptable.

The CCIDs defined by this document are:

CCID Meaning
---- -------
0 Reserved
1 Unspecified Sender-Based Congestion Control
2 TCP-like Congestion Control
3 TFRC Congestion Control

A new connection starts

New connections start with CCID 2 for both DCCPs. endpoints. If this is
unacceptable for a DCCP endpoint, that endpoint MUST send
"Change(CCID)" Mandatory
Change(CCID) options on its first packets, and MUST Reset the
connection if the results of those negotiations are unacceptable. packets.

All CCIDs standardized for use with DCCP will correspond to
congestion control mechanisms previously standardized by the IETF.
We expect that for quite some time, all such mechanisms will be TCP-
friendly, but TCP-friendliness is not an explicit DCCP requirement.

A DCCP implementation intended for general use---in use, such as an
implementation in a general-
purpose general-purpose operating system kernel, for example---SHOULD SHOULD
implement at least CCIDs 1 and 2. The intent is to make these CCIDs
broadly available for interoperability, although any given application particular
applications might disallow their use via the feature negotiation process.

7.1. use.

10.1. Unspecified Sender-Based Congestion Control

CCID 1 denotes an unspecified sender-based congestion control
mechanism. Separate features negotiate the corresponding congestion
acknowledgement options---for example, Ack Vector. This provides a limited, controlled form of
interoperability for new IETF-approved
CCIDs.

Implementors MUST NOT use CCIDs: with CCID 1 in production environments as 1, an HC-
Sender can use a
proxy for new sender-based congestion control mechanisms that have mechanism whose
details the HC-Receiver does not entered understand.

Some congestion control mechanisms require only generic behavior
from the
IETF standards process. We intend receiver. For example, CCID 2, TCP-like Congestion
Control, requires that any production the receiver (1) send Ack Vectors and (2)
respond to Ack Ratio. Both of these requirements use generic
mechanisms described in this document. Thus, a CCID 2 HC-Receiver
doesn't really need to understand the details of CCID 2.

CCID 1
would have uses this insight to be explicitly approved first by support forward compatibility for
sender-based congestion control mechanisms. An HC-Sender proposes
CCID 1 as a proxy for a sender-based mechanism whose details the IETF. Middleboxes
MAY choose HC-
Receiver doesn't need to understand. The HC-Receiver can then agree
to treat the use of CCID 1 1, and provide generic acknowledgement feedback as experimental requested

Kohler/Handley/Floyd Section 10.1. [Page 72]

INTERNET-DRAFT Expires: August 2004 February 2004

by other features (such as Send Ack Vector). Individual CCID
profile documents say whether or
unacceptable. not they can masquerade as CCID 1.

For example, say that CCID 98, a new sender-based congestion control
mechanism using Ack Vector for acknowledgements, has entered the
IETF standards process, and the IETF has approved the use of CCID 1

Kohler/Handley/Floyd/Padhye Section 7.1. [Page 66]

INTERNET-DRAFT Expires: April 2004 October 2003
as a backup proxy for CCID 98. Now, say DCCP A, which understands and A would like to use CCID 98
for its data packets. It should therefore send a "Change L(CCID, 98
1)" option to open a CCID negotiation. 98 comes first, since that
is the preferred CCID; 1 comes next, as a potential proxy for 98.
If DCCP B understands CCID 98, it will respond with "Confirm R(CCID,
98, ...)" and all is trying to communicate well. But if it does not understand CCID 98,
it may respond with "Confirm R(CCID, 1, ...)", still allowing DCCP B, which
doesn't yet know about A
to use CCID 98. DCCP A can simply negotiate use of
CCID 1 and, separately, will separately negotiate Use Send Ack Vector. Vector,
and thus DCCP B will provide the feedback DCCP A requires for CCID 98, requires, namely
Ack Vector, without needing to understand the congestion control mechanism in
use. operation of CCID 98.

Implementors MUST NOT use CCID 1 has no sender implementation; it is exclusively meaningful at
the receiver to support forward compatibility. The sender always
uses in production environments as a specific
proxy for congestion control mechanism whose CCID is mechanisms that have not 1.
However, entered the code implementing a CCID
IETF standards process. We intend that requires only generic
feedback, such as Ack Vector, MAY add any production use of CCID 1
would have to be explicitly approved first by the list of
acceptable CCIDs sent IETF. Middleboxes
MAY choose to the receiver (following the actual CCID),
facilitating communication with receivers that do not understand the
actual CCID.

Any CCID feature negotiation in which the sender proposes treat the use of CCID 1 without any other as experimental or
unacceptable.

Since CCID is considered erroneous, 1 should be used only as a proxy for other, defined
CCIDs, an HC-Sender MUST NOT report a preference list consisting
only of CCID 1, and the option "Change L(CCID, 1)" is illegal.
Receiving such an option SHOULD result in connection reset, reset with Reason set
Reset Code 5, "Option Error". An HC-Receiver MAY suggest CCID 1
exclusively: the option "Change R(CCID, 1)" is not illegal.

If CCID 1 is the result of a CCID feature negotiation, the HC-Sender
determines which CCID to "Fruitless
Negotiation". actually use by picking the earliest CCID
in its preference list that can masquerade as CCID 1. The HC-Sender
MUST pick a CCID that appeared explicitly in its preference list.

Many DCCP APIs will allow applications to suggest preferred CCIDs
for sending and receiving data. Applications Such APIs might be able to let applications
allow or prevent the use of CCID 1 for sending and receiving. For
sending, however, it makes sense to receiving, but they should
not let applications suggest the use of CCID 1 for sending. The
code implementing a particular CCID silently suggest should add CCID 1 to the HC-
Sender's CCID preference list when appropriate, unless the
application disagrees. The default for both sender and receiver
should be to allow CCID 1 when appropriate. possible.

CCID 1 places no restrictions on how often the HC-Receiver may send
DCCP-Ack packets. This applies wherever we say "send a DCCP-Ack as
allowed by the congestion control mechanism in use". A careful implementation SHOULD implement a
liberal rate limit on DCCP-Acks to prevent ack storms, however.

7.2. storms.

Kohler/Handley/Floyd Section 10.1. [Page 73]

INTERNET-DRAFT Expires: August 2004 February 2004

10.2. TCP-like Congestion Control

CCID 2, TCP-like Congestion Control, denotes Additive Increase,
Multiplicative Decrease (AIMD) congestion control with behavior
modelled directly on TCP, including congestion window, slow start,
timeouts, and so forth. CCID 2 achieves maximum bandwidth over the
long term, consistent with the use of end-to-end congestion control,
but halves its congestion window in response to each congestion
event. This leads to the abrupt rate changes typical of TCP.
Applications should use CCID 2 if they prefer maximum bandwidth
utilization to steadiness of rate. This is often the case for
applications that are not playing their data directly to the user.
For example, a hypothetical application that transferred files over
DCCP, using application-level retransmissions for lost packets,

Kohler/Handley/Floyd/Padhye Section 7.2. [Page 67]

INTERNET-DRAFT Expires: April 2004 October 2003
would prefer CCID 2 to CCID 3. On-line games may also prefer CCID
2.

CCID 2 is further described in [CCID 2 PROFILE].

7.3.

10.3. TFRC Congestion Control

CCID 3 denotes TCP-Friendly Rate Control (TFRC), an equation-based
rate-controlled congestion control mechanism. TFRC is designed to
be reasonably fair when competing for bandwidth with TCP-like flows,
where a flow is "reasonably fair" if its sending rate is generally
within a factor of two of the sending rate of a TCP flow under the
same conditions. However, TFRC has a much lower variation of
throughput over time compared with TCP, which makes CCID 3 more
suitable than CCID 2 for applications such as telephony or streaming
media where a relatively smooth sending rate is of importance.

CCID 3 is further described in [CCID 3 PROFILE]. The TFRC congestion
control algorithms were initially described in [RFC 3448].

7.4.

10.4. CCID-Specific Options, Features, and Reset Reasons

Option Codes

Half of the option types, feature numbers, and Reset Reasons 128 through 255 Codes are
available
reserved for CCID-specific use. CCIDs may often need new option
types---for options,
for communicating acknowledgement or rate information, for
example. CCID-specific example;
reserved option types spaces let them CCIDs create options at will without
polluting the global option space. Option 128 might have different
meanings on a half-connection using CCID 4 and a half-
connection half-connection
using CCID 8. CCID-specific options and features will never
conflict with global options and features introduced by later
versions of this specification.

Any packet may contain information meant for either half-connection,
so CCID-specific option types, feature numbers, and Reset Reasons Codes

Kohler/Handley/Floyd Section 10.4. [Page 74]

INTERNET-DRAFT Expires: August 2004 February 2004

explicitly signal the half-connection to which they apply.

o Option numbers 128 through 191 are for options sent from the HC-
Sender to the HC-Receiver; option numbers 192 through 255 are for
options sent from the HC-Receiver to the HC-Sender.

o Reset Reasons Codes 128 through 191 indicate that the HC-Sender reset the
connection (most likely because of some problem with
acknowledgements sent by the HC-Receiver); Reset Reasons Codes 192 through
255 indicate that the HC-Receiver reset the connection (most
likely because of some problem with data packets sent by the
HC-Sender).

Kohler/Handley/Floyd/Padhye Section 7.4. [Page 68]

INTERNET-DRAFT Expires: April 2004 October 2003 by the HC-
Sender).

o Finally, feature numbers 128 through 191 are used for features
located at the HC-Sender; feature numbers 192 through 255 are for
features located at the HC-Receiver. Since Change L and Confirm L
options for a feature are sent by the feature location, we know
that any Change L(128) option was sent by the HC-Sender, while any
Change L(192) option was sent by the HC-Receiver. Similarly,
Change R(128) options are sent by the HC-Receiver, while
Change R(192) options are sent by the HC-Sender.

For example, consider a DCCP connection where the A-to-B half-
connection uses CCID 4 and the B-to-A half-connection uses CCID 5.
Here is how a sampling of CCID-specific options and features are
assigned to half-connections:

Kohler/Handley/Floyd Section 10.4. [Page 75]

INTERNET-DRAFT Expires: August 2004 February 2004

Relevant Relevant
Packet Option Half-conn. CCID
------ ------ ---------- ----
A > B 128 A-to-B 4
A > B 192 B-to-A 5
A > B Change L(128, ...) A-to-B 4
A > B Change R(192, ...) A-to-B 4
A > B Confirm L(128, ...) A-to-B 4
A > B Confirm R(192, ...) A-to-B 4
A > B Change R(128, ...) B-to-A 5
A > B Change L(192, ...) B-to-A 5
A > B Confirm R(128, ...) B-to-A 5
A > B Confirm L(192, ...) B-to-A 5

B > A 128 B-to-A 5
B > A 192 A-to-B 4
B > A Change L(128, ...) B-to-A 5
B > A Change R(192, ...) B-to-A 5
B > A Confirm L(128, ...) B-to-A 5
B > A Confirm R(192, ...) B-to-A 5
B > A Change R(128, ...) A-to-B 4
B > A Change L(192, ...) A-to-B 4
B > A Confirm R(128, ...) A-to-B 4
B > A Confirm L(192, ...) A-to-B 4

CCID-specific options and features have no clear meaning when a
nontrivial negotiation for the relevant CCID is in progress. This
can happen when a CCID-specific option follows a Change(CCID)
option. Say the Change option prefers lists CCID X. X first. Then the
negotiation is nontrivial if and only if its result is not X. CCID-specific CCID-
specific options and features MUST be ignored during a nontrivial
CCID
negotiation---for instance, by responding Ignored options---except negotiation, except that Mandatory CCID-specific options and
features MUST induce a

Kohler/Handley/Floyd/Padhye Section 7.4. [Page 69]

INTERNET-DRAFT Expires: April 2004 October 2003 DCCP-Reset with Reason Reset Code 6, "Mandatory
Error".

11. Acknowledgements

Congestion control requires receivers to transmit information about
packet losses and ECN marks to senders. DCCP receivers MUST report
all congestion they see, as defined by the relevant CCID profile.
Each CCID says when acknowledgements should be sent, what options
they must use, how they should be congestion controlled, and so on.

Most acknowledgements use DCCP options. For example, on a half-
connection with CCID 2 (TCP-like), the receiver reports
acknowledgement information using the Ack Vector option. This
section describes common acknowledgement options and shows how acks
using those options will commonly work. Full descriptions of the
acknowledgement

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

INTERNET-DRAFT Expires: August 2004 February 2004

ack mechanisms used for each CCID are laid out in the CCID profile
specifications.

Acknowledgement options, such as Ack Vector, generally depend on the
DCCP Acknowledgement Number, and are thus only allowed on packet
types that carry that number (all packets except DCCP-Request and
DCCP-Data). Detailed acknowledgement options are not necessarily
required on every packet that carries an Acknowledgement Number,
however.

8.1.

11.1. Acks of Acks and Unidirectional Connections

DCCP was designed to work well for both bidirectional and
unidirectional flows of data, and for connections that transition
between these states. However, acknowledgements required for a
unidirectional connection are very different from those required for
a bidirectional connection. In particular, unidirectional
connections need to worry about acks of acks.

The ack-of-acks problem arises because some acknowledgement
mechanisms are reliable. For example, an HC-Receiver using CCID 2,
TCP-like Congestion Control, sends Ack Vectors containing completely
reliable acknowledgement information. The HC-Sender should
occasionally inform the HC-Receiver that it has received an ack. If
it did not, the HC-Receiver might resend complete Ack Vector
information, going back to the start of the connection, with every
DCCP-Ack packet! However, note that acks-of-acks need not be
reliable themselves: when an ack-of-acks is lost, the HC-Receiver
will simply maintain, and periodically retransmit, old
acknowledgement-related state for a little longer. Therefore, there
is no need for acks-of-acks-of-acks.

Kohler/Handley/Floyd/Padhye Section 8.1. [Page 70]

INTERNET-DRAFT Expires: April 2004 October 2003

When communication is bidirectional, any required acks-of-acks are
automatically contained in normal acknowledgements for data packets.
On a unidirectional connection, however, the receiver DCCP sends no
data, so the sender would not normally send acknowledgements.
Therefore, the CCID in force on that half-connection must explicitly
say whether, when, and how the HC-Sender should generate acks-of-
acks.

For example, consider a bidirectional connection where both half-
connections use the same CCID (either 2 or 3), and where DCCP B goes
"quiescent". This means that the connection becomes unidirectional:
DCCP B stops sending data, and sends only sends DCCP-Ack packets to
DCCP A. For CCID 2, TCP-like Congestion Control, DCCP B uses Ack
Vector to reliably communicate which packets it has received. As
described above, DCCP A must occasionally acknowledge a pure
acknowledgement from DCCP B, so that DCCP B can free old Ack Vector

Kohler/Handley/Floyd Section 11.1. [Page 77]

INTERNET-DRAFT Expires: August 2004 February 2004

state. For instance, DCCP A might send a DCCP-DataAck packet every now
and then, instead of DCCP-Data. In contrast, for CCID 3, TFRC
Congestion Control, DCCP B's acknowledgements generally need not be
reliable, since they contain cumulative loss rates; TFRC works even
if every DCCP-Ack is lost. Therefore, DCCP A need never acknowledge
an acknowledgement.

When communication is unidirectional, a single CCID---in the
example, the A-to-B CCID---controls both DCCPs' acknowledgements, in
terms of their content, their frequency, and so forth. For
bidirectional connections, the A-to-B CCID governs DCCP B's
acknowledgements (including its acks of DCCP A's acks), while the B-
to-A CCID governs DCCP A's acknowledgements.

DCCP A switches its ack pattern from bidirectional to unidirectional
when it notices that DCCP B has gone quiescent. It switches from
unidirectional to bidirectional when it must acknowledge even a
single DCCP-Data or DCCP-DataAck packet from DCCP B. (This includes

Each CCID defines how to detect quiescence on that CCID, and how
that CCID handles acks-of-acks on unidirectional connections. The
B-to-A CCID defines when DCCP B has gone quiescent. Usually, this
happens when a period has passed without B sending any data packets;
for CCID 2, this period is the case where maximum of 0.2 seconds and two round-
trip times. The A-to-B CCID defines how DCCP A handles acks-of-acks
once DCCP B has gone quiescent.

11.2. Ack Piggybacking

Acknowledgements of A-to-B data MAY be piggybacked on data sent by
DCCP B, as long as that does not delay the acknowledgement longer
than the A-to-B CCID would find acceptable. However, data
acknowledgements often require more than 4 bytes to express. A
large set of acknowledgements prepended to a single large data packet might
exceed the allowed maximum packet size. In this case, DCCP B SHOULD
send separate DCCP-Data and DCCP-Ack packets, or DCCP-DataAck wait, but not too
long, for a smaller datagram.

Piggybacking is particularly common at DCCP A when the B-to-A half-
connection is quiescent---that is, when DCCP A is just acknowledging
DCCP B's acknowledgements, as described above. There are three
reasons to acknowledge DCCP B's acknowledgements: to allow DCCP B to
free up information about previously acknowledged data packets from
A; to shrink the size of future acknowledgements; and to manipulate
the rate at which future acknowledgements are sent. Since these are
secondary concerns, DCCP A can generally afford to wait indefinitely
for a data packet was lost to piggyback its acknowledgement onto.

Kohler/Handley/Floyd Section 11.2. [Page 78]

INTERNET-DRAFT Expires: August 2004 February 2004

Any restrictions on ack piggybacking are described in
transit, the relevant
CCID's profile.

11.3. Ack Ratio Feature

Ack Ratio provides a common mechanism by which CCIDs that clock
acknowledgements off data packets can perform rudimentary congestion
control on the acknowledgement stream. CCID 2, TCP-like Congestion
Control, uses Ack Ratio to limit the rate of its acknowledgement
stream, for example. Some CCIDs ignore Ack Ratio, performing
congestion control on acknowledgements in some other way.

Ack Ratio has feature number 7, and is non-negotiable. It takes
two-byte integer values. The Ack Ratio/A feature is the rough ratio
of data packets sent by DCCP A to acknowledgement packets sent back
by DCCP B. For example, if Ack Ratio/A is four, then DCCP B will
send at least one acknowledgement packet for every four data packets
sent by DCCP A. DCCP A sends a "Change L(Ack Ratio)" option to
notify DCCP B of its ack ratio. New connections start with Ack
Ratio 2 for both endpoints.

Implementations should treat Ack Ratio as a loose guideline. For
instance, a DCCP endpoint might implement a delayed acknowledgement
timer like TCP's, whereby each packet is acknowledged within at most
T seconds of its receipt. (In TCP, T is detectable commonly set to 200
milliseconds.) This is explicitly allowed even though it might lead
to sending more acknowledgement packets than Ack Ratio would
suggest. Particular algorithms for setting and using the # NDP field Ack Ratio are
discussed in the DCCP
packet header.)

Each CCID defines how to detect quiescence on that CCID, and how
that relevant CCID handles acks-of-acks on unidirectional connections. drafts.

11.4. Ack Vector Options

The
B-to-A CCID defines when DCCP B has gone quiescent. Usually, this
happens when Ack Vector gives a period has passed without B sending any run-length encoded history of data packets.
For CCID 2, this period is packets
received at the maximum client. Each byte of 0.2 seconds the vector gives the state of
that data packet in the loss history, and the number of preceding
packets with the same state. The option's data looks like this:

The two round-
trip times. Ack Vector options (option types 38 and 39) differ only in
the values they imply for ECN Nonce Echo. Section 12.2 describes
this further.

The A-to-B CCID defines how DCCP A handles acks-of-acks
once DCCP B has gone quiescent.

Kohler/Handley/Floyd/Padhye vector itself consists of a series of bytes, each of whose
encoding is:

Kohler/Handley/Floyd Section 8.1. 11.4. [Page 71] 79]

INTERNET-DRAFT Expires: April August 2004 October 2003

8.2. Ack Piggybacking

Acknowledgements February 2004

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Sta| Run Length|
+-+-+-+-+-+-+-+-+

Sta[te] occupies the most significant two bits of A-to-B data MAY be piggybacked on data sent by
DCCP B, as long as that does each byte, and can
have one of four values:

0 Packet received (and not delay ECN marked).

1 Packet received ECN marked.

2 Reserved.

3 Packet not yet received.

Run Length, the acknowledgement longer
than least significant six bits of each byte, specifies
how many consecutive packets have the A-to-B CCID would find acceptable. However, data
acknowledgements often require more than 4 bytes given State. Run Length zero
says the corresponding State applies to express. A
large set one packet only; Run Length
63 says it applies to 64 consecutive packets. Run lengths of acknowledgements prepended 65 or
more must be encoded in multiple bytes.

The first byte in the first Ack Vector option refers to a large data the packet might
exceed
indicated in the path's MTU. In this case, DCCP B SHOULD send separate Acknowledgement Number; subsequent bytes refer to
older packets. (Ack Vector MUST NOT be sent on DCCP-Data and DCCP-Ack DCCP-
Request packets, or wait, but not too long, for a
smaller datagram.

Piggybacking is particularly common at DCCP A when which lack an Acknowledgement Number.) If an Ack
Vector contains the B-to-A half-
connection is quiescent---that is, when DCCP A decimal values 0,192,3,64,5 and the
Acknowledgement Number is just acknowledging
DCCP B's acknowledgements, as described above. There are three
reasons to decimal 100, then:

Packet 100 was received (Acknowledgement Number 100, State 0,
Run Length 0).

Packet 99 was lost (State 3, Run Length 0).

Packets 98, 97, 96 and 95 were received (State 0, Run Length 3).

Packet 94 was ECN marked (State 1, Run Length 0).

Packets 93, 92, 91, 90, 89, and 88 were received (State 0, Run
Length 5).

A single Ack Vector option can acknowledge DCCP B's acknowledgements: to allow DCCP B to
free up information about previously acknowledged to 16192 data packets.
Should more packets from
A; need to shrink the size be acknowledged than can fit in 253
bytes of future acknowledgements; and to manipulate Ack Vector, then multiple Ack Vector options can be sent;
the rate at which future acknowledgements are sent. Since these second Ack Vector begins where the first left off, and so forth.

Ack Vector states are
secondary concerns, DCCP A can generally afford subject to wait indefinitely two general constraints. (These
principles SHOULD also be followed for a data packet to piggyback its other acknowledgement onto.

Kohler/Handley/Floyd Section 11.4. [Page 80]

INTERNET-DRAFT Expires: August 2004 February 2004

mechanisms; referring to Ack Vector states simplifies their
explanation.)

1. Packets reported as State 0 or State 1 MUST have been processed
by the receiving DCCP stack. In particular, their options must
have been processed. Any restrictions data on ack piggybacking are described the packet need not have been
delivered to the receiving application; in fact, the relevant
CCID's profile.

8.3. Ack Ratio Feature

Ack Ratio provides a common mechanism by which CCIDs that clock
acknowledgements off data packets can perform rudimentary congestion
control may
have been dropped.

2. Packets reported as State 3 MUST NOT have been received by DCCP.
Feature negotiations and options on such packets MUST NOT have
been processed, and the acknowledgement stream. CCID 2, TCP-like Congestion
Control, uses Ack Ratio Acknowledgement Number MUST NOT
correspond to limit such a packet.

Packets dropped in the rate of its acknowledgement
stream, for example. Some CCIDs ignore Ack Ratio, performing
congestion control application's receive buffer SHOULD be
reported as Received or Received ECN Marked (States 0 and 1),
depending on acknowledgements their ECN state; such packets' ECN Nonces MUST be
included in some other way.

Ack Ratio has feature number 3. the Nonce Echo. The Data Dropped option informs the
sender that some packets reported as received actually had their
application data dropped.

One or more Ack Ratio feature located at
DCCP B equals Vector options that, together, report the rough ratio status of data
more packets than have actually been sent by SHOULD be considered
invalid. The receiving DCCP A to
acknowledgement packets sent back SHOULD either ignore the options or
reset the connection with Reset Code 5, "Option Error". Packets
that haven't been included in any Ack Vector option SHOULD be
treated as "not yet received" (State 3) by DCCP B. For example, if it is
set to four, then DCCP B will send at least one acknowledgement
packet for every four data packets DCCP A sends. DCCP the sender.

Appendix A sends provides a
"Change R(Ack Ratio)" option to DCCP B to change non-normative description of the details of
DCCP B's ack ratio. acknowledgement handling, in the context of an abstract Ack Ratio is a non-negotiable feature.

An
Vector implementation.

11.4.1. Ack Ratio option contains Vector Consistency

A DCCP sender will commonly receive multiple acknowledgements for
some of its data packets. For instance, an HC-Sender might receive
two bytes DCCP-Acks with Ack Vectors, both of data: which contained information
about sequence number 24. (Information about a sequence number is
generally repeated in every ack until the HC-Sender acknowledges an
ack. In this case, perhaps the HC-Receiver is sending acks faster
than the HC-Sender is acknowledging them.) In a sixteen-bit
integer representing perfect world, the ratio. A new connection starts with Ack
Ratio 2 for both DCCPs.

Implementations should treat
two Ack Ratio as a loose guideline. For
instance, a DCCP endpoint Vectors would always be consistent. However, there are many
reasons why they might implement a delayed acknowledgement
timer like TCP's, whereby each not be:

o The HC-Receiver received packet is acknowledged within at most

Kohler/Handley/Floyd/Padhye 24 between sending its acks, so
the first ack said 24 was not received (State 3) and the second
said it was received or ECN marked (State 0 or 1).

Kohler/Handley/Floyd Section 8.3. 11.4.1. [Page 72] 81]

INTERNET-DRAFT Expires: April August 2004 October 2003

T seconds of February 2004

o The HC-Receiver received packet 24 between sending its receipt. (In TCP, T is commonly set acks, and
the network reordered the acks. In this case, the packet will
appear to 200
milliseconds.) This is explicitly allowed even though it might lead transition from State 0 or 1 to sending more acknowledgement packets than Ack Ratio would
suggest. Particular algorithms for setting State 3.

o The network duplicated packet 24, and using Ack Ratio are
discussed in one of the relevant CCID drafts.

8.4. Use Ack Vector Feature

The Use Ack Vector feature lets DCCPs negotiate whether they should
use duplicates was
ECN marked. This might show up as a transition between States 0
and 1.

To cope with these situations, HC-Sender DCCP implementations SHOULD
combine multiple received Ack Vector options states according to report congestion. Ack Vector provides
detailed loss information, this table:

Received State
0 1 3
+---+---+---+
0 | 0 |0/1| 0 |
Old +---+---+---+
1 | 1 | 1 | 1 |
State +---+---+---+
3 | 0 | 1 | 3 |
+---+---+---+

To read the table, choose the row corresponding to the packet's old
state and lets senders report back the column corresponding to their
applications whether particular packets were dropped. Use the packet's state in the
newly received Ack
Vector is mandatory for some CCIDs, Vector, then read the packet's new state off the
table. For an old state of 0 (received non-marked) and optional received
state of 1 (received ECN marked), the packet's new state may be set
to either 0 or 1. The HC-Sender implementation will be indifferent
to ack reordering if it chooses new state 1 for others.

Use Ack Vector has feature number 4. that cell.

The Use Ack Vector feature
located at DCCP B specifies whether DCCP B MUST use Ack Vector
options HC-Receiver should collect information about received packets,
which it will eventually report to the HC-Sender on its acknowledgements one or more
acknowledgements, according to DCCP A, although DCCP B may send
Ack Vector options even the following table:

Received Packet
0 1 3
+---+---+---+
0 | 0 |0/1| 0 |
Stored +---+---+---+
1 |0/1| 1 | 1 |
State +---+---+---+
3 | 0 | 1 | 3 |
+---+---+---+

This table equals the sender's table, except that when Use Ack Vector is false. DCCP A sends
a "Change R(Use Ack Vector, 1)" option to DCCP B to ask B to send
Ack Vector options as part of its acknowledgement traffic. Use Ack
Vector the stored
state is a server-priority feature.

Use Ack Vector feature values are a single byte long. The 1 and the received state is 0, the receiver
MUST send Ack Vector options if this byte is nonzero. allowed to
switch its stored state to 0.

Kohler/Handley/Floyd Section 11.4.1. [Page 82]

INTERNET-DRAFT Expires: August 2004 February 2004

A new
connection starts with Use HC-Sender MAY choose to throw away old information gleaned from
the HC-Receiver's Ack Vector 0 Vectors, in which case it MUST ignore newly
received acknowledgements from the HC-Receiver for both DCCPs.

8.5. those old
packets. It is often kinder to save recent Ack Vector Options

The information
for a while, so that the HC-Sender can undo its reaction to presumed
congestion when a "lost" packet unexpectedly shows up (the
transition from State 3 to State 0).

11.4.2. Ack Vector gives a run-length encoded history of data Coverage

We can divide the packets that have been sent from an HC-Sender to
an HC-Receiver into four roughly contiguous groups. From oldest to
youngest, these are:

1. Packets already acknowledged by the HC-Receiver, where the HC-
Receiver knows that the HC-Sender has definitely received at the client. Each byte of
acknowledgements.

2. Packets already acknowledged by the vector gives HC-Receiver, where the state of HC-
Receiver cannot be sure that data packet in the loss history, and HC-Sender has received the number of preceding
packets with
acknowledgements.

3. Packets not yet acknowledged by the same state. The option's data looks like this:

The two Ack Vector options (option types 38 and 39) differ only in HC-Receiver.

4. Packets not yet received by the values they imply for ECN Nonce Echo. Section 9.2 describes
this further. HC-Receiver.

The vector itself consists of a series of bytes, each union of whose
encoding is:

Kohler/Handley/Floyd/Padhye Section 8.5. [Page 73]

INTERNET-DRAFT Expires: April 2004 October 2003

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|St | Run Length|
+-+-+-+-+-+-+-+-+

St[ate]: groups 2 bits

Run Length: 6 bits

State occupies the most significant two bits of each byte, and can
have one of four values:

0 Packet received (and not ECN marked).

1 Packet received ECN marked.

2 Reserved. 3 Packet not yet received.

The first byte in is called the first Acknowledgement Window.
Generally, every Ack Vector option refers to generated by the packet
indicated in HC-Receiver will cover
the whole Acknowledgement Number; subsequent bytes refer to
older packets. (Ack Window: Ack Vector MUST NOT be sent on DCCP-Data and DCCP-
Request packets, which lack an Acknowledgement Number.) If an acknowledgements are
cumulative. (This simplifies Ack Vector contains maintenance at the decimal values 0,192,3,64,5 and HC-
Receiver; see Section A, below.) As packets are received, this
window both grows on the
Acknowledgement Number is decimal 100, then:

Packet 100 was received (Acknowledgement Number 100, State 0,
Run Length 0).

Packet 99 was lost (State 3, Run Length 0).

Packets 98, 97, 96 and 95 were received (State 0, Run Length 3).

Packet 94 was ECN marked (State 1, Run Length 0).

Packets 93, 92, 91, 90, 89, right and 88 were received (State 0, Run
Length 5).

Run lengths of more than 64 must be encoded in multiple bytes. A
single Ack Vector option can acknowledge up to 16192 data packets.
Should shrinks on the left. It grows
because there are more packets, and shrinks because the data
packets' Acknowledgement Numbers will acknowledge previous
acknowledgements, moving packets need to be acknowledged than can fit in 253
bytes of from group 2 into group 1.

11.5. Send Ack Vector, then multiple Vector Feature

The Send Ack Vector feature lets DCCPs negotiate whether they should
use Ack Vector options can be sent.
The second to report congestion. Ack Vector option will begin where the first provides
detailed loss information, and lets senders report back to their
applications whether particular packets were dropped. Send Ack
Vector
option left off, is mandatory for some CCIDs, and so forth.

Kohler/Handley/Floyd/Padhye optional for others.

Send Ack Vector has feature number 8, and is server-priority. It
takes one-byte Boolean values. DCCP A MUST send Ack Vector options
on its acknowledgements when Send Ack Vector/A has value one,
although it MAY send Ack Vector options even when Send Ack Vector/A

Kohler/Handley/Floyd Section 8.5. 11.5. [Page 74] 83]

INTERNET-DRAFT Expires: April August 2004 October 2003 February 2004

is zero. Values of two or more are reserved. New connections start
with Send Ack Vector states are subject to two general constraints. (These
principles SHOULD also be followed 0 for other acknowledgement
mechanisms; referring both endpoints. DCCP B sends a
"Change R(Send Ack Vector, 1)" option to DCCP A to ask A to send Ack
Vector states simplifies their
explanation.)

(1) Packets reported options as State 0 or State 1 MUST have been processed
by part of its acknowledgement traffic.

11.6. Slow Receiver Option

An HC-Receiver sends the receiving DCCP stack. In particular, their options must
have been processed. Any data on Slow Receiver option to its sender to
indicate that it is having trouble keeping up with the sender's
data. The HC-Sender SHOULD NOT increase its sending rate for
approximately one round-trip time after seeing a packet with a Slow
Receiver option. However, the Slow Receiver option does not
indicate congestion, and the HC-Sender need not have been
delivered to reduce its sending
rate. (If necessary, the receiving application; in fact, receiver can force the data may
have been dropped.

(2) Packets reported as State 3 MUST NOT have been received sender to slow down
by DCCP.
Feature negotiations dropping packets, with or without Data Dropped, or reporting
false ECN marks.) APIs should let receiver applications set Slow
Receiver, and options on such packets MUST NOT have
been processed, sending applications determine whether or not their
receivers are Slow.

The Slow Receiver option takes just one byte:

+--------+
|00000010|
+--------+
Type=2

Slow Receiver does not specify why the receiver is having trouble
keeping up with the sender. Possible reasons include lack of buffer
space, CPU overload, and application quotas. A sending application
might react to Slow Receiver by reducing its sending rate or by
switching to a lossier compression algorithm.

The sending application should not react to Slow Receiver by sending
more data, however. The optimal response to a CPU-bound receiver
might be to increase the Acknowledgement Number MUST NOT
correspond sending rate, by switching to such a packet.

Packets dropped in less-
compressed sending format, since a highly-compressed data format
might overwhelm a slow CPU more seriously than the application's receive buffer SHOULD be
reported as Received or Received ECN Marked (States 0 and 1),
depending on their ECN state; such packets' ECN Nonces MUST higher memory
requirements of a less-compressed data format. The Slow Receiver
option is not appropriate for this case; a CPU-bound receiver should
not ask for Slow Receiver options to be
included in the Nonce Echo. sent.

Slow Receiver implements a portion of TCP's receive window
functionality.

11.7. Data Dropped Option

The Data Dropped option informs the
sender indicates that some packets reported as
received actually had their
payloads dropped.

One or more Ack Vector options that, together, report data dropped before it reached the status of
more

Kohler/Handley/Floyd Section 11.7. [Page 84]

INTERNET-DRAFT Expires: August 2004 February 2004

application. The sender's congestion control mechanism may respond
to data-dropped packets less severely than have actually been sent SHOULD be considered
invalid. to lost or marked
packets. For instance, a windowed mechanism might subtract a
constant value from its congestion window, rather than cut it in
half.

Data Dropped lets a sender differentiate between different kinds of
loss (network and endpoint), but it does not allow total freedom in
how to react. The receiving DCCP SHOULD either ignore congestion control response to a Data Dropped
packet must be approved by the options or
reset IETF. Each congestion control
mechanism MUST react to a Data Dropped packet as if the connection with Reason set packet were
ECN marked, unless explicitly specified otherwise.

If a received packet's application data is dropped for one of the
reasons listed below, this SHOULD be reported using a Data Dropped
option. Alternatively, the receiver MAY choose to "Option Error". Packets report as
"received" only those packets whose status has data were not dropped, subject
to the constraint that packets not reported by any Ack Vector option SHOULD be
treated as "not yet received" (State 3) by the sender.

Appendix A provides received MUST NOT
have had their options processed.

The option's data looks like this:

The vector itself consists of a non-normative description series of the details bytes, called Blocks, each
of
DCCP acknowledgement handling, whose encoding corresponds to one of these choices:

0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0| Run Length | or |1|DrpCd|Run Len|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Normal Block Drop Block

The first byte in the context of an abstract Ack
Vector implementation.

8.5.1. Ack Vector Consistency

A DCCP sender will commonly receive multiple acknowledgements for
some of its data first Data Dropped option refers to the packet
indicated in the Acknowledgement Number; subsequent bytes refer to
older packets. For instance, (Data Dropped MUST NOT be sent on DCCP-Data or DCCP-
Request packets, which lack an HC-Sender might receive
two DCCP-Acks with Ack Vectors, both of Acknowledgement Number.) Normal
Blocks, which contained information
about sequence number 24. (Because of cumulative acking,
information about a sequence number is repeated have high bit 0, indicate that any received packets in every ack until
the HC-Sender acknowledges an ack. Perhaps the HC-Receiver is
sending acks faster than Run Length had their data delivered to the HC-Sender is acknowledging them.) In a
perfect world, application. Drop
Blocks, which have high bit 1, indicate that received packets in the two Ack Vectors would always be consistent.
However, there are many reasons why they might
Run Len[gth] were not be:

o delivered as usual. The HC-Receiver received 3-bit Drop Code
[DrpCd] field says what happened; generally, no data from that
packet 24 between sending its acks, so reached the first ack said 24 was application. Packets reported as "not yet
received" MUST be included in Normal Blocks; packets not received (State 3) and the second

Kohler/Handley/Floyd/Padhye covered by
any Data Dropped option are treated as if they were in a Normal

Kohler/Handley/Floyd Section 8.5.1. 11.7. [Page 75] 85]

INTERNET-DRAFT Expires: April August 2004 October 2003

said it was received or ECN marked (State 0 or 1).

o The HC-Receiver received packet 24 between sending its acks, and
the network reordered the acks. In this case, the packet will
appear to transition from State February 2004

Block. Defined Drop Codes for Drop Blocks are:

0 or 1 Packet data dropped due to State 3.

o The network duplicated packet 24, and one of protocol constraints. For
example, the duplicates data was
ECN marked. This might show up as included on a transition between States 0 DCCP-Request packet, and 1.

To cope with these situations, HC-Sender DCCP implementations SHOULD
combine multiple received Ack Vector states according to this table:

Received State
0 1 3
+---+---+---+
0 | 0 |0/1| 0 |
Old +---+---+---+
1 | 1 | 1 | 1 |
State +---+---+---+
3 | 0 | 1 | 3 |
+---+---+---+

To read
the table, choose receiving application does not allow that piggybacking;
or the row corresponding to data was sent during an important feature
negotiation.

1 Packet data dropped because the packet's old
state and application is no longer
listening.

2 Packet data dropped in the column corresponding receive buffer.

3 Packet data dropped due to corruption.

4-6 Reserved.

7 Packet data corrupted, but delivered to the packet's state in the
newly received Ack Vector, then read application
anyway.

For example, if a Data Dropped option contains the packet's new state off