Last Modified: 2004-01-22
- 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.
|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|
|Sep 03||Working group last call for spec and CCIDs|
|Oct 03||Working group last call on User Guide|
|Nov 03||Submit DCCP spec for IESG/IETF review to be Proposed Standard|
|Nov 03||Submit DCCP CCIDs for IESG/IETF review to be Proposed Standard|
|Dec 03||Submit User Guide for IESG/IETF review to be Informational RFC|
Minutes Datagram Congestion Control Protocol (dccp) working group March 4, 2004 IETF-59 Seoul, South Korea Minutes taken by Ted Faber. Slides for all talks are available at http://www.icir.org/kohler/dccp/ietf59 Jabber log is available at http://firstname.lastname@example.org/2004-03-03.html Agenda: Status & Chair's Remarks (Falk) Spec Update (Handley) Summary of mailing list thread on DCCP, real-time, and CBR (Floyd) DCCP User Guide update (Phelan) ==================================== Chair's remarks (Aaron Falk) Since last meeting there has been an energetic discussion of congestion control versus real-time applications, an update of the User Guide draft, and a (hopefully) final polish on the DCCP specification and CCID documents. The current status of the working group is that the spec and CCIDs are ready for WGLC (however they require thorough reading since many editorial changes have been made); the User Guide needs feedback from the community: is the new direction (describing services as opposed to APIs) acceptable? useful? Also, there are a handful of ideas that have come up over the last several months that may be taken on as new work items. Before the next IETF, we hope to take the spec and CCIDs to WGLC, update the User Guide, and update the charter. Here is a proposed schedule: - IETF-59: Review Spec, CCID changes - Mar 04: WGLC for spec, CCIDs - Apr 04: Publish user-guide-02 - May 04: Revise wg charter Several possible new charter items have been proposed. They are listed below with the folks who've agreed to author an initial draft. (It's necessary to identify an author is before adding something to the charter.) - Faster start after idle (Eddie Kohler) - CCID-3 thin (Eddie Kohler) - TFRC-PS (Sally Floyd - to be published in tsvwg but will require a CCID) - TFRC supporting apps w/limited rate flexibility (mjh) - 8 packet/RTT initial sending rate (Eddie) Spec Changes (Mark Handley presenting for Eddie Kohler) Spec changes include organizational changes and cleanups spotted by reviewers. Event processing has been clarified. There were many simplifications discussed at IETF in Minneapolis. The most significant changes have already been discussed on the mailing list. A new state was added, Part Open, to handle a possible deadlock. Event processing text was made explicit through the use of pseudocode (much more comprehensive than the state diagram, which is necessarily incomplete). Text on sequence number validity cleaned up and ambiguities removed. Changed protocol for Sync packets to avoid some possible problems. Spec now discusses probabilities of sequence number collisions for regular and extended number spaces. Recommend using extended sequence numbers for windows greater than 100 packets. Clarifications added on forward compatibility including removing the "Ignored" option. Empty Change and Confirm options added to allow one end to query the option state of the other. Open issues status from IETF-58. - #NDP: removed in favor of NDP count option - ID and Challenge: removed for Sync and SyncAck - DataDropped requirements in CCID 3: since the problem is in the receiver rather than in the network, the draft now suggests manipulating Xrecv to indirectly limit the transmit rate Discussion on DataDropped: - Magnus Westerlund: seems to indicate that this kind of data drop is not congestion related. The right answer is: do nothing. - Mark: the options of ignore or treat as network congestion are both too extreme, this allows a more gentle response. - Magnus: could this be a valid response for corruption? - Sally: I believe the text says "drop in receive buffer". You don't want to send data that you know is going to be dropped. We think this will also be useful to deal with corruption. However, using DataDropped for corruption is open issue - this is a hook for the future. - Mark: packets are serving no useful purpose, so we felt we needed to do something, although the response is not as urgent (as for network congestion). - Magnus: I suggest adding more drop codes and define these responses remove special cases. - Sally: Not something to talk about here. Corruption/ congestion may be uncorrelated, maybe not. Need to think about that, but this current systems is not a bad start. Gentle reduction. - Mark: Yes, this is a placeholder but a reasonable start. - Colin Perkins: Could use receive window for flow control. I.e., no receive window, no flow control -- this seems close to that. - Mark: have to think about it - Packet sizes: want to avoid people gaming packet sizes. Not clear how well this works, added weasel words. implementations can check. Flag of a possible issue. - Payload checksum: use SCTP CRC-32c Discussion on Checksums - Colin Perkins: I understand why you switched to the CRC-32c checksum, but I'm concerned that it is expensive in terms of bandwidth overhead. - Mark: you don't have to use it. - Colin: Wireless environments will use it and it's particularly expensive for them. - Mark: separate header from rest. OK, that's an issue. - Colin: You may need 2 types of checksums. - Mark: Apps which can tolerate loss may not care about checksum. - Eddie: It's only 6 bytes overhead. - Colin: Can be pushed out 8 bytes with padding. Yes? That would be twice the Internet checksum overhead? It may not be a problem but we need to be careful. - Mark: We just can't sort out all these issues before we get some deployment experience. Go try it. Adding a checksum is easy. - Eddie: And you don't have to use it. - Tom Phelan: The purpose of different checsksums is to provide different strengths of protection. So, having both use the Internet checkksum would be redundant (and defeat the intent). - Mark: Having two coverages does have uses, e.g., to detect non-congestion errors. You may really want a stronger checksum, too. Mostly strong checksums are for when there's no link layer help. - Tom Phelan: Agree, if you only have one extra checksum, it *should* be stronger. - Service Code wildcarding: addressing Bellovin security issue. Solution was to remove wildcarding. Discussion on Service Code Wildcarding - Falk: what flexibility are you giving up by dropping wildcarding? - Mark: Nothing useful. A server listening on port w/o specifying service name now requires service code. A client cannot specify connection w/o knowing what service is there. Allowins wildcard was a workarounds because we expected it would be difficult to get service codes, but we now believe that getting service codes should be fairly easy so that should be OK. - Falk: Suppose I have a client wants to talk Real version or QT version and a server that will take either. - Mark: The appropriate service code must be acquired that out-of-band and that's OK - Tom Phelan: Adding admin overhead is OK. Since ports added overhead, so service codes are OK. - Eddie: Servers can talk multiple protocols and at most service will fail one to another. - Colin: One thing vendors will do is mux on the same port. E.g., muxing RTP and RTCP. What does this buy us? Compared to potential for abuse. - Mark: This makes the client's intent much more explicit. It's important for security to have explicit intent. Therefore, fewer firewall heuristics are required. This approach allows fine, detailed description of what is transferred. The existing port space is insufficient; there aren't enough ports for fine grained registration. You don't want to put large numbers in every packet. - Colin: That seems OK. Although, I'm concerned that people could lie about Service Codes to get through firewalls. Having a separate code lets you manipulate server. - Colin: You can multiplex multiple services on one port. Horrible, but can do it. - Mark: Server port irrelevant. It's OK to have many things on same server port. - Colin: Doesn't this make the firewall's job harder? - Mark: No, explicit data makes firewalls easier. They can specify the specific rules they want (using service codes) instead of relying on a rough estimate (by using port numbers). - Colin: I still don't see the gains, but servers will multiplex services on same port - Mark: we just don't agree. Talk later. - Only trivial changes to CCIDs Questions? - James Kempf: Lots of discussion about ID/locator separation at this IETF. The mobility support in DCCP looks like that stuff. Are there conflicts?? - Mark: The timing was poor for DCCP mobility support. We don't know which (or whether any) mobile IP solution will prevail and so we'll assume they fail. While we hope not, however the DCCP mobility approach is a lightweight mechanism, so we can deprecate it if something better comes along. - James: The DCCP approach doesn't work if both ends are moving. - Mark: Yes, this is a known shortcoming. - Magnus: Mobility is a big security hole via sniffing and stealing. - Mark: If you are concerned about sniffing, use IPsec. - Falk: DCCP is only required to be as secure as TCP - Magnus: I believe the mobility feature should be moved out of the spec and made an optional extension to avoid the security hole. - Mark: Disagree. You can turn mobility support off and it would be hard to add as an extension. - Eddie: Agree with Mark. - James: This is a similar problem to Mobile IP binding update: there's a protocol in MIP that will avoid a DOS here (lying about move destination) there may be an IESG issue here (since it affects multiple protocols). Can this be used to DoS an innocent 3rd party? - Mark: Yes. But only if you can snoop nonce exchange - James: Is the nonce used directly? - Mark: yes - Anders Clements: Any thoughts on how to cross NATs? - Mark: NATs will need to become DCCP-aware. We acknowledge that this is a long term solution. - Anders: Is DCCP over UPD to avoid blocking by NATs a crazy idea? - Mark: Yes - Colin: Suppose you set up connection to yourself, observe the nonce exchange, and redirect the stream to some unsuspecting 3rd party? - Mark: This may be a problem. I need to think about that. - Future work - TFRC for apps that can't directly change sending rate. - Specs assume that CCIDs assumes data will be sent appropriately - What about fixed rate or discretely variable rate apps? Try using TFRC as reference rate and stay within a factor of 2 and use DCCP as policing mechanism. May be issues when there are only a few flows. Need some research. Unlikely to be socially bad, but may not always be fair. Additional Discussion - Magnus: How useful is sequence number transition - Mark: had a fair amount of debate on this. It's preferable to pick the right sequence number space at the beginning of a connection. However, flows without knowledge of net conditions (which includes most flows) would like to be able to switch. I'm not terribly happy with the current solution but we couldn't find anything better. =========================== DCCP issues from mailing list (Sally Floyd) Some quotes from recent list messages: - "Real Time apps have no interest in being 'fair'. - "Don't expect people like XXX to be happy with the 'you must fit in to TCP's view of the world' when most of their real-time applications are already being good citizens (by not sending 'all they can' when they don't have to)." [Referring to a silence-suppressed, CBR, 4 Mbps video stream!] - "Maybe some codecs of today, which were designed assuming a QoS enabled network, cannot make use of TFRC or DCCP." - "TCP is broken. Nowhere is it written that TCP = best effort." Background assumptions (ours): - DCCP and best-effort traffic: DCCP with best-effort service does not necessarily meet the needs of all apps. In fact, best-effort service does not necessarily meet the needs of all apps. DCCP is intended to solve the best-effort problem, not the QoS problem. We believe that in the long run DCCP offers better performance than UDP to applications (e.g., ECN, NAT traversal, etc.) Why do flows have to be bothered with CC? RFC 2914 provides 2 reasons: prevent congestion collapse and share fairly w/TCP. IETF will not standardize non CC-ed transport protocols. Why Slow start? CBR app writers don't want slow start after idle periods or ever. Why?: "We're sending at a low rate so why bother?" Idle periods: "We're benefiting the network by going idle, why penalize us by forcing slow start after a quiet period?" "Our traffic is more financially valuable to ISPs so congestion rules don't apply" "TCP must be fixed [to be friendlier to CBR apps]" Current CCID 3 specifies 4 pkts initial window and possibility of 8 small packets in the future. DCCP would drop packets in excess of 4 sent by a CBR application. As for best-effort traffic with higher initial rates rates? Sally's view: explicit router feedback is needed. See, e.g., the Quick-Start expired ID (draft-amit-quick-start-02.txt). You could make this happen! Sending rate is limited to grow no faster than doubling in a RTT. This topic was triggered by mention in user-guide to double your send rate to avoid TCP from 'stealing' your BW and to avoid slow start after idle. This suggestion was based on an incorrect understanding of TCP. TCP's send rate is determined by loss, not by maximum send rate. Nevertheless, it is recognized that the doubling-limit poses a constraint for bursty apps, instant-on apps, and silence suppression. But relaxing this constraint remains a topic for research. A connection that has started and gone idle knows a little more about the network conditions than a brand-new connection. There has been a proposal sent to the list for a "Faster Start" after idle. The proposal is for an initial rate of 8 pkts/RTT, followed by quadrupling of the send rate each RTT until the previous rate is reached or a drop or a mark are received. This proposal has not been tested or fully evaluated and needs more investigation. Implementation experience regarding slow-start problems will help guide and motivate this work. Finally, there are concerns about applications with fixed (or very limited flexibility in) send rates. There is a proposal to allow a DCCP sender to send up to twice the "allowed" sending rate. To do this would require a new CCID and further work. Questions? Comments? - Wolfgang Beck: SIP has a mechanism to include RSVP. We have implemented SIP with a probing phase. Would this work for DCCP? DCCP would signal a reference rate then go on with signaling. Would this be a solution for initial slow-start as a kind of reservation? - Sally: use padded data to build up rate and go? Sounds viable. - Falk: It seems you could do it w/o SIP or RSVP. - Mark: Yes, you could use DCCP-Sync pkts to do that. - Sally: Hmm, would the packet size difference cause a problem? Slow starting with small packets, then going to large application packets... - Magnus: Can you pad an ack? - Sally: Yes. ============================== DCCP Users Guide (Tom Phelan) There's a new revision of User Guide and the big question is what to do next. The "user" in the user guide is the application. Unlike the previous version, it is not an API document. Sections include: - Choosing a CCID - 2 App stories - streaming media probably not ready - Shorter section on gaming. - Stupid DCCP tricks - misc features - Security section Controversies in guide (according to Tom) Fast restart is assumed to be in there. Training period in strategy 3 - padding the network as discussed before. - Falk: fast restart is probably not coming anytime soon. Suggest removing that assumption. Stream switch Variable rate media: just can't support rate variations like the 10x difference between I-frames and ??-frames. - Falk: a sender can smooth these bursty codecs right? - Tom: you need to ramp up in a frame time - Falk: I was talking about smoothing the rate variation - Tom: going from a static frame to a busy frame is a sharp change - Sally: The fundamental assumption here is that real-time media users with cheap service use best-effort at the cost of extra delay, while people willing to pay would not use best-effort. - Magnus: Can avoid big swings through the right choice of codec, right? - Tom: Agrees that most codec can be adapted, but maybe not today's, especially MPEG-4. - Mark: There are fundamentally two types of codecs: H.261 and H.263. One sends close to constant bit rate, in the absence of drastic content changes. The others have different frame sizes, e.g., MPEG-4. The latter is not intended for interactive use. Perhaps the issue we are talking about stems from a mismatch between codec and application. - Falk: you said the video is not changing on the smoother codec - Mark: there are smoothing/quality degradation tricks in the interactive codecs. - Tom: There's a similar statement in the user-guide. Your point is good - some codecs adapt better than others. - Mark: No - if you want to meet interactive constraints, you need a codec that produces smooth traffic, or with non-interactive codecs that use buffering to smooth their output. Stream padding: always try to send - pad when necessary. removed the doubling of rate. (This was based on bad assumptions, see Sally's talk). TFRC with self-limiting sources. Desperately in need of simulations. Restart after idle for games? Will it work? - Falk: Do we know whether gaming people are using RTP or raw UDP? - Tom: We don't have much information, but it appears they are using UDP. More apps? What's missing? The section on "Stupid DCCP tricks" discusses specific guidance on how a DCCP application should use some of the features in DCCP. - Colin: In my opinion, this version of the User Guide is more useful. ============================ Closing Discussion - Colin: Are there any implementations? - Falk: There are some implementation info on Eddie's page. Not clear how close they are to the current version of the spec. A fairly full featured version was developed at ICIR over the summer but the spec has changed a bit since then. - Mark: Most implementations are lagging. - Colin: would like implementations before going to Proposed Standard - Falk: Implementations are not a requirement for PS (but are a good thing) - Colin: I still feel we need implementations ============================ CLOSE