One document matched: draft-ietf-dccp-ccid3-thin-00.txt
Internet Engineering Task Force Eddie Kohler
INTERNET-DRAFT UCLA/ICIR
draft-ietf-dccp-ccid3-thin-00.txt 19 October 2003
Expires: April 2004
DCCP CCID 3-Thin
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes the Thin variant of the Datagram Congestion
Control Protocol (DCCP) Congestion Control Identifier 3, TCP-
Friendly Rate Control (TFRC). The Thin variant is more restricted
than CCID 3; it limits allowable options, acceptable feature values,
and so forth. CCID 3-Thin packets are still valid DCCP CCID 3
packets. CCID 3-Thin was designed for small clients where a full
DCCP implementation would be too expensive.
Kohler [Page 1]
INTERNET-DRAFT Expires: April 2004 October 2003
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The CCID 3-Thin Option. . . . . . . . . . . . . . . . . . . . 3
4. CCID 3-Thin Restrictions. . . . . . . . . . . . . . . . . . . 4
5. Connection Establishment. . . . . . . . . . . . . . . . . . . 6
5.1. Thin Client Initiates Connection . . . . . . . . . . . . 6
5.2. Server Responds to Thin Client . . . . . . . . . . . . . 6
5.3. Thin Server Responds to Fat Client . . . . . . . . . . . 7
5.4. Fat Client Responds to Thin Server's
Response. . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Thanks. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Normative References . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
Kohler [Page 2]
INTERNET-DRAFT Expires: April 2004 October 2003
1. Introduction
The Datagram Congestion Control Protocol (DCCP) [DCCP] implements a
congestion-controlled stream of unreliable unicast datagrams. DCCP
uses Congestion Control Identifiers, or CCIDs, to determine the
congestion control mechanism in use on a half-connection. (A half-
connection might consist of data packets sent from DCCP A to DCCP B,
plus acknowledgements sent from DCCP B to DCCP A. DCCP A is the HC-
Sender, and DCCP B the HC-Receiver, for this half-connection. In
this document, I abbreviate HC-Sender and HC-Receiver as "sender"
and "receiver", respectively. These terms are defined more fully in
[DCCP].) DCCP CCID 3, TCP-Friendly Rate Control (TFRC) [CCID 3
PROFILE], defines a receiver-based congestion control mechanism that
provides a TCP-friendly send rate, while minimizing abrupt rate
changes [RFC 3448].
This document describes the Thin variant of DCCP CCID 3. All CCID
3-Thin packets are valid CCID 3 packets, but the converse is not
true: the Thin variant restricts the options that may be sent, the
values that features may take, and so forth. CCID 3-Thin was
designed for small clients and servers where a full DCCP
implementation would be too expensive.
Note that this version of this document is more a proof-of-concept
than a final proposal. The right set of restrictions for CCID
3-Thin should be subject to further discussion. For example, a
final CCID 3-Thin might support ECN.
This document assumes familiarity with both DCCP proper [DCCP] and
the CCID 3 profile [CCID 3 PROFILE].
2. Conventions
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. The CCID 3-Thin Option
+--------+--------+
|11000001|00000010|
+--------+--------+
Type=193 Len=2
The CCID 3-Thin option is sent on the initial packets in a CCID 3
connection to indicate that the endpoints agree to be bound by the
CCID 3-Thin restrictions. It is a CCID-specific option, which means
Kohler Section 3. [Page 3]
INTERNET-DRAFT Expires: April 2004 October 2003
that the CCID feature must be set to 3 before the CCID 3-Thin option
is processed; this may happen simply by sending CCID 3-Thin after
the options that negotiate the CCID.
CCID 3-Thin options will generally be preceded by a Mandatory option
(Type 1). This will force the receiving DCCP to reset the
connection if it cannot abide by the CCID 3-Thin restrictions,
below.
4. CCID 3-Thin Restrictions
A CCID 3-Thin connection agrees to follow these restrictions.
o Both half-connections use CCID 3 (their CCID features have value
3).
o All features are fixed to the values listed below, whether or not
their values are negotiated. No feature negotiation options will
be sent after the CCID 3-Thin handshake completes.
o Both ECN Capable features have value 0 (ECN incapable). All
packets are sent as ECN-incapable.
o Both Use Ack Vector features have value 0 (do not send Ack
Vectors; the default). No Ack Vector options will be sent. CCID
3-Thin applications that want information about which packets have
arrived will have to send application-level acknowledgements.
o Both Mobility Capable features have value 0 (mobility incapable;
the default). Neither endpoint will send a DCCP-Move packet.
o Both Loss Window features have value 1000 (the default).
o Both ID Regime features have value 0 (the Null Regime). This
makes it impossible for CCID 3-Thin connections to get back into
sync after large bursts of loss. Neither endpoint will ever send
a Challenge or Identification option.
o Both Use Loss Event Rate features have value 1 (send Loss Event
Rate options; the default).
o Both Use Loss Intervals features have value 0 (do not send Loss
Intervals options; the default). No Loss Intervals options will
be sent.
o Only the following types of packets can be sent:
Kohler Section 4. [Page 4]
INTERNET-DRAFT Expires: April 2004 October 2003
(1) DCCP-Request packets without data.
(2) DCCP-Response packets without data and without an Init Cookie
option.
(3) DCCP-Data packets with no options (Data Offset = 3).
(4a)
DCCP-Ack packets with no options (Data Offset = 4).
(4b)
DCCP-Ack packets with 20 bytes of option (Data Offset = 9).
The options MUST be exactly as follows: Elapsed Time with
length 4; Padding; Padding; Receive Rate with length 6;
Padding; Padding; and Loss Event Rate with length 6.
(4c)
A fat client responding to a thin server may follow a DCCP-
Response with a DCCP-Ack that contains other options; see
Section 5.4.
(5) DCCP-Close packets with no options (Data Offset = 4).
(6) DCCP-Reset packets with no options (Data Offset = 5).
o Packets that would normally be reported with Data Dropped are
instead treated as network losses (they increase the reported Loss
Event Rate).
o Following from the earlier restrictions, neither DCCP will ever
send Slow Receiver, Init Cookie, Ack Vector, Data Dropped (except
on a DCCP-Response), Timestamp, Timestamp Echo, Identification,
Challenge, Payload Checksum, or Loss Intervals options, or DCCP-
Move, DCCP-DataAck, or DCCP-CloseReq packets.
o The connection speed must be sufficiently small that sequence
number wrapping will not become a problem, and extended sequence
numbers will never be sent.
A CCID 3-Lite connection is a normal DCCP connection, and MUST
follow the DCCP [DCCP] and CCID 3 [CCID 3 PROFILE] specifications,
except that if any of the above restrictions is violated, the
receiving DCCP SHOULD reset the connection with Reason 193, Thin
Violation.
Kohler Section 4. [Page 5]
INTERNET-DRAFT Expires: April 2004 October 2003
5. Connection Establishment
This section describes how CCID 3-Thin connections are initiated.
The terminology "thin" means that a client or server can only
communicate with CCID 3-Thin restricted partners, and agrees to
abide by those restrictions itself. "Fat" clients and/or servers,
however, can communicate with any DCCP.
5.1. Thin Client Initiates Connection
A thin client initiating a connection to any server MUST send a
DCCP-Request packet containing only the following options in this
exact order: Change L(CCID, 3), Change R(CCID, 3), Mandatory, CCID
3-Thin, and Padding.
+--------+--------+--------+--------+
|00100001|00000100|00000001|00000011|
|Change L| Len=4 | CCID | TFRC |
+--------+--------+--------+--------+
|00100011|00000100|00000001|00000011|
|Change R| Len=4 | CCID | TFRC |
+--------+--------+--------+--------+
|00000001|11000001|00000010|00000000|
|Mand'ory| 3-Thin | Len=2 |Padding |
+--------+--------+--------+--------+
The DCCP-Request MUST NOT contain data.
5.2. Server Responds to Thin Client
A server responding to this packet sequence will first change both
CCID features to 3 (TFRC). If TFRC is not acceptable to the server,
it MUST reset the connection with Reset Reason set to Fruitless
Negotiation (since CCID is a server-priority feature). The server
will then process the Mandatory CCID 3-Thin option. If the server
agrees to the CCID 3-Thin restrictions above, it MUST send a DCCP-
Response packet containing only the following options, in this
order: Confirm R(CCID 3), Confirm L(CCID, 3), Mandatory, CCID
3-Thin, and Padding.
Kohler Section 5.2. [Page 6]
INTERNET-DRAFT Expires: April 2004 October 2003
+--------+--------+--------+--------+
|00100100|00000100|00000001|00000011|
|ConfirmR| Len=4 | CCID | TFRC |
+--------+--------+--------+--------+
|00100010|00000100|00000001|00000011|
|ConfirmL| Len=4 | CCID | TFRC |
+--------+--------+--------+--------+
|00000001|11000001|00000010|00000000|
|Mand'ory| 3-Thin | Len=2 |Padding |
+--------+--------+--------+--------+
The server SHOULD reset the connection if the DCCP-Request does not
follow the CCID 3-Thin restrictions---for example, if the CCID
3-Thin option is followed by other options.
If the server does not understand the CCID 3-Thin option, or does
not agree to the Thin restrictions, it MUST reset the connection
with Reason set to Option Error (because of the Mandatory option).
5.3. Thin Server Responds to Fat Client
A thin server might be contacted by a fat client, which might send
options and feature values on its DCCP-Request that do not follow
the CCID 3-Thin restrictions. The server MUST process these
options, but not necessarily as a conventional DCCP would. In
particular:
o The server MUST process options immediately preceded by a
Mandatory option. If a Mandatory option does not fit the CCID
3-Thin restrictions, the server MUST reset the connection with
Reason set to Option Error. If a Mandatory option does fit the
restrictions, the server SHOULD respond as required; for example,
when sent a Mandatory Change option with acceptable values, the
server SHOULD respond with the appropriate Confirm option. An
extremely restricted server MAY instead choose to reset the
connection (with Reason set to Option Error) whenever any
Mandatory option is received.
o The server SHOULD process non-Mandatory options as well. For
example, when sent a Change L(CCID, 2) option, the server SHOULD
reset the connection with Reason set to Fruitless Negotiation; but
when sent a Change L(CCID, 1 2 3) option, the server SHOULD
respond with a Confirm R(CCID, 3) option. An extremely restricted
server MAY instead ignore all non-mandatory options; the fat
client will perform the necessary settings (or reset the
connection) when it receives the server's Mandatory CCID 3-Thin
option.
Kohler Section 5.3. [Page 7]
INTERNET-DRAFT Expires: April 2004 October 2003
o If the DCCP-Request contains data, the server's DCCP-Response MUST
contain a Data Dropped option with Drop Code 0 (data dropped due
to protocol constraints).
o Any DCCP-Response MUST contain feature negotiation options that
set both CCIDs to 3, followed by a Mandatory CCID 3-Thin option.
The feature negotation options might be Change L(CCID, 3) and
Change R(CCID, 3) options, as in the thin-client case; or if the
server processed one or more Change(CCID) options on the DCCP-
Request, they might be Confirm options.
5.4. Fat Client Responds to Thin Server's Response
A fat client receiving a DCCP-Response containing a Mandatory CCID
3-Thin option MUST either reset the connection, if it cannot abide
by the CCID 3-Thin restrictions, or respond with a DCCP-Ack. This
DCCP-Ack MUST complete any feature negotiations initiated by the
DCCP-Response, and MUST also contain a CCID 3-Thin option (either
Mandatory or not).
The thin server MUST be prepared to handle such a DCCP-Ack, but it
MAY ignore the feature negotiation options on that Ack. Because the
server sent a Mandatory CCID 3-Thin option on its DCCP-Response, it
can assume that any ensuing DCCP-Ack abides by the CCID 3-Thin
restrictions.
6. Security Considerations
Security considerations for DCCP have been discussed in [DCCP];
security considerations for TFRC have been discussed in [RFC 3448];
and security considerations for DCCP CCID 3 have been discussed in
[CCID 3 PROFILE]. CCID 3-Thin is not as secure against spoofed
feedback, misbehaving receivers, and DOS attacks as straight DCCP
with CCID 3. In particular, CCID 3-Thin does not support ECN, so
the ECN Nonce-based verification mechanisms of CCID 3 are not
available to it. Also, the lack of an Identification mechanism
means that an attacker can cause a connection to stop by inducing a
long burst of loss.
7. IANA Considerations
The CCID 3-Thin specification allocates two values from IANA-
administered registries:
o The CCID 3-specific option 193, for CCID 3-Thin.
o The CCID 3-specific Reset Reason 193, for Thin Violation.
Kohler Section 7. [Page 8]
INTERNET-DRAFT Expires: April 2004 October 2003
8. Thanks
Thanks to Tom Phelan for his DCCP-Lite draft, which showed what he
thought could be elided from full CCID 3.
Normative References
[CCID 2 PROFILE] S. Floyd and E. Kohler. Profile for DCCP Congestion
Control ID 2: TCP-like Congestion Control, draft-ietf-dccp-
ccid2-03.txt, work in progress, June 2003.
[CCID 3 PROFILE] S. Floyd, E. Kohler, and J. Padhye. Profile for
DCCP Congestion Control ID 3: TCP-Friendly Rate Control, draft-
ietf-dccp-ccid3-03.txt, work in progress, June 2003.
[DCCP] E. Kohler, M. Handley, S. Floyd, and J. Padhye. Datagram
Congestion Control Protocol, draft-ietf-dccp-spec-04.txt, work
in progress, June 2003.
[RFC 2119] S. Bradner. Key Words For Use in RFCs to Indicate
Requirement Levels. RFC 2119.
[RFC 3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP
Friendly Rate Control (TFRC): Protocol Specification, RFC 3448,
Proposed Standard, January 2003.
Authors' Addresses
Eddie Kohler <kohler@icir.org>
ICSI Center for Internet Research
1947 Center Street, Suite 600
Berkeley, CA 94704 USA
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
Kohler [Page 9]
INTERNET-DRAFT Expires: April 2004 October 2003
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Kohler [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-22 13:28:41 |