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.
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.
| 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 <falk@isi.edu>
Notes: Spencer Dawkins
<sdawkins@cynetanetworks.com>
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:dccp@ietf.org
Subscribe: mailto:dccp-request@ietf.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
|