Last Modifield: 07/02/2002
- 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.
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.
|SEP 02||Publish summary of required protocol functions/requirements|
|DEC 02||Decision to build on proposed DCCP protocol, alternate protocol, or quit and go home|
|APR 03||Publish DCCP protocol as proposed standard (including applicability statement)|
|APR 03||Publish TCP equivalent congestion profile as proposed standard|
|APR 03||Publish TCP Friendly Rate Control congestion profile as Proposed Standard|
|JUN 03||Publish document providing guidance to users of DCCP as an Informational RFC.|
Datagram Congestion Control Protocol (dccp) Thursday, November 21 at 0900-1130 =================================== CHAIR: Aaron Falk <email@example.com> Notes: Spencer Dawkins <firstname.lastname@example.org> AGENDA 0. Agenda Bashing - Aaron Falk 1. Working Group Status - Aaron Falk 2. Discussion of changes to DCCP protocol spec - Mark Handley 3. Should we continue down the path of the current DCCP protocol spec? open discussion, moderator: Aaron Falk 4. A few words on the relationship between TFRC and DCCP - Sally Floyd 5. Discussion of initial draft of DCCP User Doc - Damon Lanphear 6. Implementation Reports 7. Other Issues 8. Close ======================================== =============================== 0. Agenda Bashing - Aaron Falk No changes noted. ======================================== =============================== 1. Working Group Status -- Aaron Falk ---------------------------------- Presentation: http://www.isi.edu/~falk/dccp/dccp-intro-falk.ppt We've WG last-called the problem statement, revved the protocol spec, and published a first-draft user's guide. We're humming directions on the protocol spec today. The mailing list has been quiet - too quiet. Are people following the work? Comment: The authors have not published what they where doing and what changes they where performing to the mailing list. Where are the implementations? There are implementations, but they are implementations of earlier drafts (the spec has changed) and haven't been tested against each other. Are they being maintained? ======================================== =============================== 2. Discussion of changes to DCCP protocol spec -- Mark Handley draft-ietf-dccp-spec-00 --------------------------------------- ----------------------- Presentation: http://www.icir.org/mjh/tmp/dccp-nov02.pdf Quite a few changes since Yokohama - rewrite of Challenge, change of Reset format, "buffer closed" signaling. TCP-friendliness isn't an explicit goal any more - the focus is on "IETF-standardized" congestion control mechanisms to allow for future, non-TCP congestion control. Challenge allows DCCP-level mobility and loss of sequence number synchronization. The old mechanism didn't work (darn!). Challenge source address must be expected address. Have discussed stronger mechanisms, looking for feedback that this is needed in the base spec (and this looking will happen on the mailing list). Reasons have been added to the Reset packet. There are some reasons that the other endpoint can't do anything about, but it's good to know what the reason was - and some reasons do have reasonable responses. Buffer Closed Drops option has been dropped in favor of Buffer Close. We discovered an ambiguity where packets might be dropped in a receive buffer, but possibly after control information was extracted. To resolve this ambiguity, the philosophy is "If you ACK a packet as 'received', you MUST deliver it to the application unless it's explicitly dropped due to application intervention." Good progress, mechanisms are stabilizing, corner cases being nailed down. We still need implementation experience, and we still need to do RTP over DCCP - do we? Is two sequence spaces too much overhead? Q: Have you considered UDP extensions such as UDP-lite? A: We do have a partial checksum in DCCP. Could you see if this meets the needs of UDP-lite applications? Q: Assuming DCCP is wildly successful, what about header compression? A: DCCP isn't too different from other transports, so this should be doable. Carsten: when you design protocols, please assume that there will be header compression, so don't go crazy squeezing bits. Q: The real question of RTP over DCCP is motivation. If the service is the same when things work, there's no motivation to move to DCCP. Applications prefer not to care about congestion, especially when there's no congestion most of the time. You're going to have to force applications to care about congestion, and nobody is actually working on forcing applications to care. Sally: the other carrot for DCCP is ECN, if people find ECN useful. Under heavy load, maybe routers would stop doing ECN for UDP, assuming that the applications won't respond anyway? Mark: another benefit is explicit set-up/tear-down for NATs and other middleboxes. Q: VoIP applications has very periodic sending rate. How is the congestion control (TFRC) going to handle this? Mark: Could use TFRC bitrate as limit for the application. If keeping within the limit the application can be allowed to decide its sending times. Q: How would applications actually use congestion controlled flows? They don't understand how to adapt codecs, etc. ======================================== =============================== HUM: Should we continue to develop the spec in this working group? ---------------------------------------- -------------------------- Aaron: time to hum this protocol direction (right direction? Something better? Go home?) Q: Shouldn't DCCP be an experimental protocol? A: not in the charter - we're supposed to be doing a standards-track protocol. Allison (Transport Area Director): the goal is to go to Proposed Standard. Q: DCCP needs a different API - too much interaction for sockets. A: User Guide talks about an example API, but a real API spec isn't in scope. Hum: The room thought we're headed down the right path. [There was some confusion do to poorly framed hum questions by Aaron (sorry!). A portion of the room felt that there were alternative technologies to DCCP to provide congestion control (notably extending SCTP). However, there was a clear consensus that the working group should continue to develop the existing DCCP spec.] Q: There are other protocols that meet the problem statement. SCTP variant? A: another hum. SCTP only has one congestion control profile (TCP). There's no reason another variant couldn't be developed. Allison: except that SCTP is already very complex now. Q: Is there a congestion profile that's NOT designed to be TCP-friendly? Or significantly different from TCP? Sally: Actually, yes (Note-taker - apparently this is the answer to the SECOND question) - TFRC. Sally: We wanted TFRC, not just TCP, we wanted smaller headers, and we wanted ECN. There's functionality in SCTP that DCCP doesn't need - multiple streams, etc. Comment: How long the header is doesn't make sense to worry about - use header compression. Comment: This is going really fast to Proposed Standard. We did the problem statement and protocol specs in parallel - or maybe even the protocol first. We need some time to absorb this. We need to think about mobility, we need to think about why we need for applications to establish connections, and so forth. Allison: this isn't WG last call - we're asking if it's the right direction. Comment: there's no technical reason why SCTP couldn't be TFRC - maybe architectural issues, but it shouldn't be off the table a priority. Allison: No engineering is ever off the table. We're thinking about functional families, but people can still think about SCTP and TFRC and convince us. Carsten (ROHC wg co-chair): don't worry about header SIZE, but do worry about header COMPLEXITY! Comment: Some of the changes I've seen over the last two meetings are dealing with the reasons why SCTP is so complex - and DCCP is becoming more complex. Mark: Maybe we should separate connection setup and congestion control? Comment: We need to make sure we're not moving too quickly, because Proposed Standard is more important than it used to be ("de facto"). A: We can change things in April if we have to. Allison: Streaming media needs this soon/today. It's OK to be moving fast. Hum: This spec is appropriate for this working group at this time. Aaron couldn't express a counter-hum, due to illness! ======================================== =============================== 3. A few words on the relationship between TFRC and DCCP Sally Floyd draft-ietf-dccp-ccid3-00 draft-ietf-tsvwg-tfrc-05 ------------------------------------------------------ TFRC is now approved as Proposed Standard. It has gone through some small changes as a result of Last Call/IESG feedback, mostly removing information that was being exchanged and adding implementation hints. CCID2 and CCID3 have been reissued with new names but no changes. Q: How does TFRC work with application-limited streams? A: This hasn't been significantly looked at to date. Mark: even TCP hasn't really looked at this! ======================================== =============================== 4. Discussion of initial draft of DCCP User Doc Damon Lanphear draft-ietf-dccp-user-guide-00 -------------------------------------------- Presentation: http://www.isi.edu/~falk/dccp-user-guide-lanphear.pdf Note: The User Doc is a new draft that hasn't been widely read or reviewed. PLEASE READ IT. Version 00 is a rough draft. Damon is looking for community guidance and feedback, so that the document has the right structure and content. Implementations need to think about what DCCP facilities they expose to applications. Examples: post-network buffer and rate control, selective transmission and retransmission based on latency, latency requirements. API considerations include configuration issues and connection establishment/termination and feature negotiation. Open issues: Loss signaling, kernel/user space API. Pragmatically, how far can we move from BSD sockets? Do applications find out that data may need retransmitting? Is the DCCP sequence number space - and loss indications - visible to the application? What do we do when receivers are slow? Aaron: If you're in AVT, please share pointers to this work with that community. Q: There's minimal sample buffering - this is problematic for VoIP. Sally: TRFC loss rate should be visible, and I'm supposed to be thinking about this. Comment: VoIP applications are very delay intolerant, therefore any API should allow a possibility to send packet without any sender side buffering. ======================================== =============================== 5. Implementation Reports ------------------------- Damon has an implementation with two parts - a validation of TFRC for streaming media applications with discrete coding intervals, and an implementation of DCCP for FreeBSD, and hopes to have patches to share by April so people can experiment with it. Berkeley developed a user-space implementation based on an older verson of the spec which is no longer being maintained. Aaron: any grad students looking for a good thesis project? ======================================== =============================== 6. Other Issues None noted. ======================================== =============================== 7. Close ======================================== =============================== USEFUL LINKS DCCP charter: http://www.ietf.org/html.charters/dccp-charter.html Mail archive: http://www1.ietf.org/mail-archive/working-groups/dccp/ DCCP mail list: mailto:email@example.com Subscribe: mailto:firstname.lastname@example.org Drafts: http://www.ietf.org/internet-drafts/draf t-ietf-dccp-spec-00.txt http://www.ietf.org/internet-drafts/draf t-ietf-dccp-problem-00.txt http://www.ietf.org/internet-drafts/draf t-ietf-dccp-ccid2-00.txt http://www.ietf.org/internet-drafts/draf t-ietf-dccp-ccid3-00.txt http://www.ietf.org/internet-drafts/draf t-ietf-dccp-user-guide-00.txt