One document matched: draft-ietf-dccp-ccid3-thin-01.txt
Differences from draft-ietf-dccp-ccid3-thin-00.txt
Internet Engineering Task Force Eddie Kohler
INTERNET-DRAFT UCLA
draft-ietf-dccp-ccid3-thin-01.txt 18 July 2004
Expires: January 2005
DCCP CCID 3-Thin
Status of this Memo
This document is an Internet-Draft.
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been
disclosed, or will be disclosed, and any of which we become aware
will be disclosed, in accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, we accept the provisions of
Section 3 of RFC 3667 (BCP 78).
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes the Thin variant of the Datagram Congestion
Control Protocol (DCCP) Congestion Control Identifier 3, TCP-
Kohler [Page 1]
INTERNET-DRAFT Expires: January 2005 July 2004
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 2]
INTERNET-DRAFT Expires: January 2005 July 2004
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The CCID 3-Thin Option. . . . . . . . . . . . . . . . . . . . 4
4. CCID 3-Thin Restrictions. . . . . . . . . . . . . . . . . . . 5
5. Connection Establishment. . . . . . . . . . . . . . . . . . . 7
5.1. Thin Client Initiates Connection . . . . . . . . . . . . 7
5.2. Server Responds to Thin Client . . . . . . . . . . . . . 7
5.3. Thin Server Responds to Fat Client . . . . . . . . . . . 8
5.4. Fat Client Responds to Thin Server's
Response. . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Thanks. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Normative References . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 11
Kohler [Page 3]
INTERNET-DRAFT Expires: January 2005 July 2004
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
+--------+--------+
|11000011|00000010|
+--------+--------+
Type=195 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
that the CCID feature must be set to 3 before the CCID 3-Thin option
Kohler Section 3. [Page 4]
INTERNET-DRAFT Expires: January 2005 July 2004
is processed; this may happen simply by sending CCID 3-Thin after
Mandatory options that negotiate the CCID.
CCID 3-Thin options will generally be preceded by a Mandatory option
(Type ). 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 Allow Short Seqnos features have value 1 (allow short
sequence numbers).
o Both Sequence Window features have value 100 (the default).
o Both ECN Capable features have value 0 (ECN incapable). All
packets are sent as ECN-incapable.
o Both Ack Ratio features have value 0 (Ack Ratio not in use).
o Both Send 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 Send NDP Count features have value 0 (do not send NDP Count
options; the default). No NDP Count options will be sent.
o Both Minimum Checksum Coverage features have value 0 (require
full Checksum Coverage; the default). No packets with less-than-
full Checksum Coverage will be sent.
o Both Check Data Checksum features have value 0 (do not
necessarily check Data Checksum options; the default). No Data
Checksum options will be sent.
o Both Send Loss Event Rate features have value 1 (send Loss Event
Rate options; the default).
Kohler Section 4. [Page 5]
INTERNET-DRAFT Expires: January 2005 July 2004
o Both Send 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:
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.
4a. DCCP-Ack packets with no options.
4b. DCCP-Ack packets with 20 bytes of option. 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.
6. DCCP-Reset packets with no options.
7. DCCP-Sync packets with no options.
8. DCCP-SyncAck packets with no options.
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-
DataAck or DCCP-CloseReq packets.
A CCID 3-Thin 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 195, Thin
Violation.
Kohler Section 4. [Page 6]
INTERNET-DRAFT Expires: January 2005 July 2004
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
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: Mandatory, Change L(CCID, 3), Mandatory, Change R(CCID,
3), Mandatory, CCID 3-Thin, Padding, Padding, Padding.
+--------+--------+--------+--------+
|00000001|00100000|00000100|00000001|
|Mand'ory|Change L| Len=4 | CCID |
+--------+--------+--------+--------+
|00000011|00000001|00100010|00000100|
| TFRC |Mand'ory|Change R| Len=4 |
+--------+--------+--------+--------+
|00000001|00000011|00000001|11000001|
| CCID | TFRC |Mand'ory| 3-Thin |
+--------+--------+--------+--------+
|00000010|00000000|00000000|00000000|
| Len=2 |Padding |Padding |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, since the Change options are marked as
Mandatory. 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 7]
INTERNET-DRAFT Expires: January 2005 July 2004
+--------+--------+--------+--------+
|00100011|00000100|00000001|00000011|
|ConfirmR| Len=4 | CCID | TFRC |
+--------+--------+--------+--------+
|00100001|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 8]
INTERNET-DRAFT Expires: January 2005 July 2004
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 Mandatory feature negotiation
options that set both CCIDs to 3, followed by a Mandatory
CCID 3-Thin option. The feature negotation options might be
Mandatory Change L(CCID, 3) and Mandatory 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.
7. IANA Considerations
The CCID 3-Thin specification allocates two values from IANA-
administered registries:
o The CCID 3-specific option 195, for CCID 3-Thin.
o The CCID 3-specific Reset Reason 195, for Thin Violation.
Kohler Section 7. [Page 9]
INTERNET-DRAFT Expires: January 2005 July 2004
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-06.txt, work in progress.
[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-06.txt, work in progress.
[DCCP] E. Kohler, M. Handley, S. Floyd, and J. Padhye. Datagram
Congestion Control Protocol, draft-ietf-dccp-spec-07.txt, work
in progress.
[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.
Authors' Addresses
Eddie Kohler <kohler@cs.ucla.edu>
4531C Boelter Hall
UCLA Computer Science Department
Los Angeles, CA 90095
USA
Full Copyright Statement
Copyright (C) The Internet Society 2004. This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM 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]
INTERNET-DRAFT Expires: January 2005 July 2004
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Kohler [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-22 13:18:00 |