Datagram Congestion Control Protocol (dccp) Internet Drafts
| Faster Restart for TCP Friendly Rate Control (TFRC) | |||||||||||||||||
|
TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. This document introduces Faster Restart, an optional mechanism for safely improving the behavior of interactive flows that use TFRC. Faster Restart is proposed for use with TFRC and with TFRC-SP, the Small Packet variant of TFRC. We present Faster Restart in general terms as a congestion control mechanism, and further discuss Faster Restart for Datagram Congestion Control Protocol (DCCP) Congestion Control IDs 3 and 4. | ||||||||||||||||
| RTP and the Datagram Congestion Control Protocol (DCCP) | |||||||||||||||||
|
The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion Control Protocol (DCCP) is a newly defined transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real-time applications can make use of the services provided by DCCP. | ||||||||||||||||
| TCP Friendly Rate Control (TFRC): Protocol Specification | |||||||||||||||||
|
This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance. This document obsoletes RFC 3448 and updates RFC 4342. | ||||||||||||||||
| The DCCP Service Code | |||||||||||||||||
|
This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340. It motivates the setting of a Service Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g. network address translators and firewalls). It updates the specification provided in RFC 4340. | ||||||||||||||||
| DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal | |||||||||||||||||
|
This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update assists DCCP applications which need to communicate through one or more middleboxes (e.g. Network Address Translators or firewalls), where establishing necessary middlebox state requires peering endpoints to initiate communication in a near-simultaneous manner. | ||||||||||||||||
| Quick-Start for Datagram Congestion Control Protocol (DCCP) | |||||||||||||||||
|
This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and on-line games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID-2 and CCID-3. Quick-Start enables a DCCP sender to cooperate with any Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start and, at times, in the middle of a DCCP connection (e.g., after an idle or application-limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. | ||||||||||||||||
 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
Datagram Congestion Control Protocol (dccp)
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:
Additional DCCP Web Page
Last Modified: 2008-07-07
Additional information is available at tools.ietf.org/wg/dccp
Chair(s):
Transport Area Director(s):
Transport Area Advisor:
Mailing Lists:
General Discussion: dccp@ietf.orgTo Subscribe: dccp-request@ietf.org
In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/dccp/index.html
Description of Working Group:
The Datagram Control Protocol working group is chartered to develop andstandardize the Datagram Congestion Control Protocol (DCCP). DCCP is a
minimal general purpose transport-layer protocol providing only two
core functions:
- the establishment, maintenance and teardown of an unreliable packet
flow.
- congestion control of that packet flow.
Within the constraints of providing these core functions, DCCP aims to
be a general purpose protocol, minimizing the overhead of packet
header
size or end-node processing as much as possible. Therefore, DCCP is as
simple as possible, and as far as reasonably possible, it should avoid
providing higher-level transport functionality. DCCP will provide a
congestion-controlled, unreliable packet stream, without TCP's
reliability or in-order delivery semantics. Additional unicast,
flow-based application functionality can be layered over DCCP.
SCOPE
Drafts for DCCP, and several associated congestion control IDs, already
exist. The first task before the working group will be an abbreviated
functional requirement validation of those drafts. There are two
possible outcomes:
1) The current DCCP draft is declared suitable for further work, with
some areas listed for possible extension.
2) The current DCCP draft is declared unsuitable for further work, and
more formal functional requirement exploration begins.
Prior to the final development of the protocol, the working group will
investigate areas of functionality that should be integrated into DCCP
because they are difficult or impossible to layer above it. These areas
include security and multi-homing/mobility, at a minimum. The protocol
will be for both IPv4 and IPv6. It will not encompass multicast. It
is strictly a unicast transport.
For security, the working group will endeavor to ensure that DCCP
incorporates good non-cryptographic mechanisms that make it resistant
to denial-of-service attacks on DCCP connections and DCCP servers. A
related topic that will be explored is whether DCCP can be a candidate
to replace UDP in the transport of security management protocols such
as IKE and JFK.
The working group will also investigate DCCP's relationship with RTP
(the Real-time Transport Protocol).
Once the DCCP specification has stabilized, the WG will produce a
document providing guidance to potential users of DCCP. The precise
form of this document will be determined by WG discussion, but it
might
include example APIs, an applicability statement, or other forms of
guidance about appropriate usage of DCCP.
Goals and Milestones:
| Done | Publish summary of required protocol functions/requirements | |
| Done | Decision to build on proposed DCCP protocol, alternate protocol, or quit and go home | |
| Done | Detailed review of spec and CCIDs | |
| Done | Public design review at IETF meeting | |
| Done | Working group last call for spec and CCIDs | |
| Done | Submit DCCP spec for IESG/IETF review to be Proposed Standard | |
| Done | Submit DCCP CCIDs for IESG/IETF review to be Proposed Standard | |
| Done | Complete WGLC draft-ietf-dccp-problem-xx as Informational | |
| Done | Complete WGLC draft-ietf-dccp-tfrc-voip as Experimental | |
| Done | Complete WGLC 'RTP over DCCP' as PS | |
| Done | Complete WGLC 'DTLS over DCCP' as PS | |
| Done | Complete WGLC for draft-ietf-dccp-rfc3448bis as PS | |
| Apr 2008 | Complete WGLC for draft-ietf-dccp-serv-codes as PS | |
| Jul 2008 | Complete WGLC draft-ietf-dccp-ccid4 as Experimental | |
| Sep 2008 | Complete WGLC draft-ietf-dccp-tfrc-faster-restart as Experimental | |
| Sep 2008 | Complete WGLC for draft-ietf-dccp-simul-open as PS | |
| Mar 2009 | Complete WGLC draft-ietf-dccp-quickstart as Experimental |
Internet-Drafts:
Faster Restart for TCP Friendly Rate Control (TFRC) (51139 bytes)RTP and the Datagram Congestion Control Protocol (DCCP) (39080 bytes)
TCP Friendly Rate Control (TFRC): Protocol Specification (148766 bytes)
The DCCP Service Code (58100 bytes)
DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal (45206 bytes)
Quick-Start for Datagram Congestion Control Protocol (DCCP) (50040 bytes)
Request For Comments:
Problem Statement for the Datagram Congestion Control Protocol (DCCP) (RFC 4336) (53585 bytes)Datagram Congestion Control Protocol (DCCP) (RFC 4340) (318830 bytes)
Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control (RFC 4341) (47868 bytes)
Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC) (RFC 4342) (83054 bytes)
TCP Friendly Rate Control (TFRC): the Small-Packet (SP) Variant (RFC 4828) (116808 bytes)
Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) (RFC 5238) (24395 bytes)
IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.
Return to working group directory. 
