Last Modified: 2004-06-15
- 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.
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 | |
Mar 04 | Working group last call for spec and CCIDs | |
Apr 04 | Revise user-guide | |
May 04 | Revise charter | |
May 04 | Submit DCCP spec for IESG/IETF review to be Proposed Standard | |
May 04 | Submit DCCP CCIDs for IESG/IETF review to be Proposed Standard | |
Sep 04 | Working group last call on User Guide |
Datagram Congestion Control Protocol WG (dccp) Thursday, August 5, 2004 at 15:30 to 17:30 ============================================== The meeting was chaired by Aaron Falk. Matt Zekauskas was scribe. AGENDA 1. Agenda Bashing and Milestone Update 2. DCCP Spec 3. Changes to CCID 2 and CCID 3 4. CCID3-thin 5. DCCP Mobility and Multihoming 6. DCCP User Guide 7. Media Friendly Rate Control 8. Last Call Comments ======================= 1. Agenda Bashing and Milestone Update --Aaron Falk (see slides) - DCCP user guide is becoming more important - MFRC (Media Friendly Rate Control) is new - The specification, CCID2 and CCID3 are all under WGLC for Proposed Standard since 20-July. The WGLC is scheduled to conclude 20-August. - Milestones were all just beyond last IETF; they've been adjusted to the next IETF, and most are now achievable. There has been no input on the milestones. - On CCID and real time interactive traffic * We need measured data to support claims being made on the mailing list * TFRC for real-time flows discussion "most heated" - Comments about applicability need to be in the user guide. There is a new revision out, please comment! If you have concerns, sending text is always appreciated. ==================== 2. DCCP specification, version -08 -- Eddie Kohler There were many little readability adjustments, which make diffs from the last version look large. However, there are two big technical issues: Mobility and multihoming was removed, and the move to uniform 48 bit sequence numbers (versus 24). The latter needs the most review, please comment! The sequence numbers used to be 24 or 48 bit, via negotiation. Since the recent TCP sequence number attack consciousness-raising, this has been revised, since with 24 bits blind reset attacks are highly probable. Thus 48 bit sequence numbers are required for DCCP requests, although 24 bits are allowed in three cases (data, datack, and ack). Mark Allman commented that 32 bits used to be OK for TCP too. Eddie responded that here "bits" means something different, you gain because DCCP is per packet instead of per-byte; eventually you'll need a timestamp. Mark responded "or a challenge/response, or...". Eddie said that was true, but it's not necessary for the next "large number" of years. Colin Perkins asked why it was OK to protect against reset, but not OK to protect against injection? Eddie responded that the important case is a half-open connection, because that's what made the blind attacks bad previously. We're trading off header size against the possibility of attack, and feel that the application should make the decision. It is a working group question as to whether there are no applications that would want to save 4 bytes of header. Colin responded that he understands why it was done, but it makes him uncomfortable, and applications might use the smaller sequence number space without understanding the consequences. Eddie said there was a section in the draft on sequence number attacks -- and he'd love advice on how to sharpen it: send text. Colin felt that what was there was good. Mark agreed that what's in the current spec is about as good a compromise as we can achieve. Eddie amplified on his earlier response: if you reset the connection, you're dead. In the general case insertion attacks generate results that are annoying, but not fatal. There is a difference in the magnitude of the attack on data versus meta-state. If an application really cares, set the option for larger sequence numbers. This seems to be a good compromise. Allison Mankin said she wanted to echo what Eddie just said. In his review of the protocol, Steve Bellovin really downplayed the significance of blind data attack. There are few that make any difference. There is enough extensibility that an additional option can be added to increase strength; it could even be proprietary. Colin noted that DCCP was primarily for long-lived connections; he understands but still isn't comfortable. Eddie invited him to send text. Colin said he would re-read the text and forward any comments. Eddie spent some time on feature negotiation (see slides). A new visible state was added ("unstable") to take care of a race condition. However, the current document has some typos; this will be remedied shortly. Eddie noted that this might be reason to restart WGLC, although he didn't think so. Finally, Eddie mentioned a host of other small changes: * rearranged header... reserved above packet type so can have more packet types if needed. Eddie was uncomfortable with the extended seqno bit in middle.... and asked if there were any ideas on what else to do. * dccp sync: ack# not acknowledgment, because used to recover from confusion. * reset codes * options on reset are processed... you may reset a reset ...but there cannot be a storm. Once a connection is killed, there are no more responses to reset. * min cksum coverage feature (willing to accept possibly corrupt data) * section on congestion state, and reset cong. state. mobility -> worth keeping? Aaron Falk: taking bait... why not move X bit to end of byte so not together. Eddie said it was to keep type as a nibble, but no one cares about that anymore. Aaron asked for an example of an option in a dccp reset? Eddie responded it was there in case there was a reason in future for conditionally resetting a connection. He had some examples, but he couldn't recall on the fly. Aaron wondered if it was susceptible to 1/2 baked-ness of reset congestion state. If the path knows something, should it always send that? The effects of an option are carefully defined. However, when the option needs to be sent is undefined. Aaron wondered if this was a general problem, although you may not want to solve it here. Eddie responded that it was possible that there are cases when it is useful to tell the other side to reset state & start again. But that is not without risk. For example, in an overloaded situation, 1 packet every 64 sec, this is like a "get out of jail free" card. That's a shame, but is also useful. Tom Phelan: what do you mean by "if path changed". Eddie said it was from an email conversation, someone had example from mobility. It's in the draft, but he can't recall what it was... and said that we should probably get rid of that option. Tom agreed. Magnus Westerlund said that because it's an option, we can add it later, even if has applicability for future. Sally Floyd agreed that it should be taken out of this, and put in a separate draft, like mobility. Aaron Falk said it's the right decision, it's gone. ====================== 3. Changes to CCID 2 and CCID 3 -- Sally Floyd CCID2 * description of response to idle and app-limited period. In essence, just explain what TCP does. * Detecting lost and marked acks. If a packet is lost, the receiver knows it (seqno missing) but doesn't know if ack or data (assuming 2 way traffic). The sender knows. When the receiver sees a loss, it assumes ack loss for ack ratio. There is an added appendix to show what this does... worst case is the same number of data and non-data packets. even in worst case, the cost is not that bad. CCID3 * added para on sending rate when no feedback (making it rfc3448 compliant) * expanded discussion; packet size used in rate calculations * new section on response to idle and app-limited periods. * new text on data dropped and slow receiver (5.2) -- try to limit sending rate in next rtt (a bit) * new section outlining current research issues. - send fewer acks when rate low? ok with me, but potential problem if a lot of acked packets - more than double sending rate from one RTT to next. possible to relax, but... again be careful - higher sending rate after idle period. Should be more aggressive than after slow start, because been through slow start. but how much more? - Initial send of 8 packets. TCP says 4 packets, at most 4k bytes. It makes sense to send 8, but pace them out, and only if there is less than 4k sent. However, Sally had "enough skin lost" getting 4 packet initial window, that someone should research this change. Sally ended with a list of possible new efforts, for the groups information: * re-invigorating quickstart * ccid for voip based on rfc3714 (because of IAB concerns about congestion control and voice traffic). If encounter persistent congestion, must stop sending. No numbers in the draft on how much over and how much to drop, just a principle statement. ccid .. change minimum requirement to sufficient requirement. Something a little, but not much more, aggressive than CCID3 * TFRC-PS, flows that adapt their packet size =========================== 4. DCCP CCID3-lite -- Eddie Kohler This draft tries to demonstrate than although CCID3 looks heavyweight, you can implement a CCID that is very streamlined. This draft is mostly updated based on changes to the main draft. What is missing? The loss-intervals option can't be turned on (hence no ECN). Is this important enough work item for the group to accept, or should it be put off until someone wants to implement DCCP on a really small device? Aaron Falk asked if anyone cares? If not, he is going to kill it (as a wg item). Tom Phelan noted that what drove him to do this in the first place is the thought of trying to sell DSP coders to implement DCCP on DSP. The question now is if CCID3-thin is the right one to go on diet. he's not sure right now, and think we ought to hold off until all the congestion control issues settle. Aaron gave the group a thought exercise: Have we learned enough from complexity to answer the question? Or is it useful for the WG to prepare a standard that has a reduced specification? These are two different goals, one of which might not require an RFC. Tom thought it depends on what want to do later, you can apply these ideas to MFRC, and have a thin version of that. Aaron said just call it a lightweight version of something. Does it require an RFC, or just a thought experiment? Tom thought it had to go to RFC eventually. Aaron wanted to know if anyone else felt this way. Colin Perkins in a "devil's advocate" role, suggested that if there is an interest in the draft, why not just implement DCCP simply. DCCP does not seem excessive, compared to ATM. Aaron said that was a different issue; Colin thought we should consider it, it did not seem to be difficult. Aaron noted that this is about a CCID, the rest is modular. Eddie reiterated that it was a CCID, not all of DCCP. However, this specification is also a combined simplification -- it restricts what a DCCP implementation can do, and what the CCID can do. For example, * no ack vectors * no renegotiation of options Mark Handley said that to the extent that this is a profile for use, and doesn't change specification, it is always useful to suggest people a way to implement a useful subset of functionality. He thinks it is a useful informational draft. As to whether main specification might have too much in it, that's a question for all protocols... people implement different subsets of features. That's why there are "bakeoffs". Just because a stripped down version is useful for lightweight devices, you don't want to cut out features that are useful for devices that are not so lightweight. Aaron noted that feature pruning is the kind of thing that happens when a draft advances from Proposed Standard to Draft Standard. Mark said that you should do it then, but this is still a useful informational draft. Eddie notes that it is a bit of rewrite to make it informational, because the draft allocates an option. Aaron wondered if anything in thin that violated a MUST in the specification. Eddie sad no, but it does allocate an option. Colin wondered if a path forward is for the base specification to be clearer about a minimal subset. Eddie said there is an options table that shows what is optional. But 3-thin does more than that, it constrains implementations. This is so an implementation that only spoke thin can speak to a full - the full implementation would not generate a packet that violated thin rules. This is different from "optionally implemented" in a specification. Aaron wondered if this violates "server wins"; if the client is thin it supersedes server rules. Eddie said no -- if a server doesn't understand thin, by rules of mandatory, the server must reset. The server does win - it gets what it wants or no connection. Tom Phelan said his drive was not that DCCP is too thick in general; it was for streaming media devices that are very thin. A protocol for streaming media needs a thin variant, or needs to be very thin. Allison asked for clarification of how thin relates to negotiation - did it actually break the protocol? Eddie said it does not break the protocol. It restricts the operation of an endpoint, but the endpoint must agree to the restrictions. Allison wondered why we were engineering something that could happen naturally. An endpoint could restrict itself anyway. Eddie said that all CCID3-thin packets are valid dccp packets. But if you only restrict yourself, you can't guarantee that a peer would do it. Aaron said that when one found something the other side didn't support, it would just reset the connection. Eddie said the point of 3-thin was that the implementation didn't need to bother looking for strange options; it's not to be a time-saver (although it does that) but it's an implementation saver. You just check at the beginning of a connection. Allison thought perhaps we're actually asking if we can create a kind of extension to negotiation mechanism -- "negotiate out of rich negotiation". Asking to add vital small piece to proto that allows that. You need a part of the proposed standard to do that, why you should do it now instead of later. Eddie responded that this was not quite true; you can go to proposed standard without this, since it can go independently with some option number. The "mandatory option" concept is all you need in DCCP. 3-thin is in the header, as the mandatory three-thin option. There could be 3-thin, 3-thin2 or 3-thin3. Don't need to pre-specify because we have the mandatory piece. Colin said he was still trying to understand the need. Why not just send "no" to all options? Eddie because the implementation of a 3-thin client could be really simple. Colin thought it just wasn't that complex. Aaron asked for a hum of people that thought this was a reasonable activity to pursue. Mild yes. He asked for a hum of people that thought this should not be pursued. Mild no. There was a big don't care. Aaron said to take this off line... but there are not a lot of folks that support at the meeting. ================= 5. DCCP Mobility and Multihoming -- Eddie Kohler This is a new draft, pulling material out of the main draft. (See slides.) Yet to be done: specify mobility secret format and encryption algorithms. The security considerations section. The questions Eddie had for the group: * when we gave up on mobility in main spec, did we give up on it completely? * if no, - this draft - some other approach? Magnus Westerlund said that considering what was said in TSVWG today... multihoming device could use different dccp sessions, and use ICE to select. Mobility might be better in a lower layer. He didn't know what was better, but felt that's what we need to look at. Eddie responded that to be fair he wasn't at TSVWG, but he felt there is a strong case to be made for supporting in transport layer (in addition to, or instead of, the network layer). Aaron said that he saw much of what would drive a decision here to be things in other working groups. This is probably the wrong time to make a decision. You have put together a reasonable proposal. His suggestion would be to see what happens in other WG, and get rid of other outstanding issues before revisiting this one. Mark Handley thought we should keep going and see where it leads, but don't make decision now if RFC. Don't stop working on this since we have a certain amount of stuff worked out. He would like to get to the point where it was all worked out... but ietf policy to see if push forward into stds track. Aaron asked for a show of hands people interested: 2 raised their hand. He said the onus is on those folks to take forward if that's what they want to do. Allison said that she sees a need for discussion. Perhaps taking a couple of days sometime, looking at what everyone has envisioned for these services and solutions. This would be to see what everyone has discovered and learned, not "how to do them in X". There are neat things in this document. Things learned and discovered are important to the overall architecture, and people need to pool ideas. She's really happy this progress went on, and feels it could be an experimental RFC. Aaron said there are so many names for the issues on these topics... how would one characterize the topic for, e.g., an IAB workshop? Allison thought perhaps 'multiple addresses'. Aaron summarized what he heard: encouragement for the work to be done. It's not a WG item, but you can include the dccp list; collaboration with people on the list is good and worth doing. Allison said she would send a bibliography of pointers where to look for mobility work on TSVWG list, in addition to the viewgraphs from her talk at TSVWG. She's not sure where the follow-up activity is yet; suggestions on follow-up activities is also really important, and please send those to the TSVWG list. ======================== 6. The DCCP User Guide -- Tom Phelan The changes for 01 were not substantive; diff marked versions pointed to in draft. (See slides.) The question is "what next". Aaron asked who has read? Approximately 7 people responded. Rather than flogging people for not reading it, prefer to get the existing set of documents through WGLC, and then flog people. He thinks this is a very important document, applying DCCP to certain types of flows. However, without more input it has a ways to go. We need to get group more involved. Tom agreed to postpone work until after WGLC. ====================== 7. Media Friendly Rate Control -- Tom Phelan Tom started with background. There were discussions on the mailing list about TFRC versus interactive applications. TFRC seems reasonably good if not used for interactive traffic. The MFRC draft is a thought experiment of what you might want to do for interactive applications, and to stimulate discussion. Tom then went through the thought process he had leading to MFRC, and the basics of MFRC (see slides). Basically, let media applications guess the rate, and react quickly if the guess is bad. What are the next steps? Based on mailing list comments: * restart is bigger problem than slow-start. (agree, may add) * based on TFRC to make it simple. but byte rate is better than packet rate for streaming media, and he'd like to investigate. * please help simulate Tom asked where is the appropriate home for this work? DCCP says, you can't have congestion control work without a specification, but this is easy to explore. Eddie said that what the draft intends to say is that CCIDs that are standardized will have IETF-approved congestion control. It doesn't mean you have to standardize cong ctl first. However, DCCP is a congestion control protocol - can't have random congestion control algorithms. Aaron noted that the IANA rules for ccid in the draft is that there is a requirement to first have a congestion control document before you can get a CCID. Mark Allman said he votes for "option 3": you need to simulate first, see where the worst cases are. This isn't baked yet. Sally said that she agreed. However, the home for CCID could be this group. Her assumption was that the place to bring it was this WG. Ruediger Geib said that he worked on QOS for a large provider. He would transport applications using dccp, but use a different queue in the router. Then, TCP friendliness is not an issue -- only require that DCCP flows were friendly toward themselves. Because of separate queues, it would be helpful to be able to get application to reduce rate. Another idea from TSVWG: use ECN. Suggest you do both... losses and ECN. Tom said that loss or ECN marked is abbreviated by saying "loss". Right now draft doesn't consider ECN marking. Ruediger thought it would be nice to mention, not you personally do work. By the way, as a provider, we view losses as bad. Aaron said that Mark is right. There is research to be done. Show the results in AVT and here. If there is a ccid to be defined, this is the place, but that's the second step. The first step is to figure out the right thing to do. Eddie said that a ccid draft is a useful way to work out details of this as proposal. So he wouldn't mind seeing more of this draft here. Not that you shouldn't separate congestion control into a separate draft. Tom said that he wanted a ccid draft of this as one document, a simulation study as another document, and to be able to continue to talk about it here. Aaron asked if anyone here wants to work on it. No one raised hands. ======================== 8. Last Call Comments -- all Aaron wanted to follow up on a mailing list discussion as to whether some or all of the drafts should go to experimental instead of proposed. The charter specifies that the documents go to proposed. There are also issues people are raising between TFRC and real-time multimedia traffic. These are issues when trying to run this traffic over specific CCIDs. There is no applicability statement in any of the documents in last call that require people to use a specific ccid. DCCP is a piece of transport mechanism; we should standardize to get people to implement it and use it. More CCIDs would be developed with experience. Thus, he doesn't see a conflict with the fact that the CCIDs may not be appropriate for streaming media, and taking the existing documents to proposed standard. Colin agreed. Get these documents out, and save the rest for later. Magnus thought he agreed in principle. However, are the documents mature enough to go to proposed, without an implementation of the current spec? Aaron said RFC2026 does not require an implementation for proposed standard. Magnus thought it would be good to have an implementation to show it works. Aaron said that we know the requirements; there are early implementations, we've been talking about it for two years, and there's been a detailed design review. No one is raising new issues with the main specification mechanism. If someone can put issue on table, let's discuss. Free-floating anxiety is hard to work on. Magnus noted there was a new state in this version. Aaron wanted to know about new mechanisms. Eddie agreed about the new state (UNSTABLE), but it's for feature negotiation. There is an existing state machine there. Previously there were STABLE and CHANGING. Now there are three. However, this is not the main DCCP state machine. Magnus said that we haven't had one round that deals only with editorial comments. Steve Casner echoed Magnus's comments. He doesn't dispute Aaron's position, but there are certain things that he's not quite certain about. It seems a little less than ready for last call and send it on. Unidentified from Orange, works on 3G phone issues. He had an interesting conversation with Sally. How well does DCCP apply to a wireless link? Some transport protocols cause lots of problems. Not congestion - but strange behavior on radio side causes false alarms. Would dccp behave better in a strange or variable radio condition? Eddie asked for clarification: do you mean "if tcp behaves badly in highly variable link, will dccp also?" ???: Actually, if delay spikes. We see huge delay spikes on radio links. It will cause TCP to slow down, and tremendous HTTP problems. Packets are not lost, but buffered in the radio link. It produces a shot of high delay in short period of time. Mark Handley said that what would probably happen is that a decent CCID 3 implementation would carry on transmitting through delay. It may tell the sender to back off rate, but when get feedback, it would go ahead. So the answer is "yes, it should be better than TCP" Eddie wasn't sure, because he wasn't sure of the application. If you want reliable byte stream delivery, then it's a congestion control concern. You probably need CCID4/MFRC Aaron said that if you use CCID2 with data, you should have a big win over TCP if there was a delay spike. Sally said we should take this issue to the list. Colin Perkins said that he was not worried about applicability to particular applications, since we can develop new CCIDs if we need to. He's worried that we are trying to push something to proposed when it's not yet stable. 9 pages of significant revisions in this version of specification, plus the CCIDs. He thinks it is a good piece of work, and shaping up nicely, but is not convinced it's stable. He's worried that we set it in stone too early - don't force it out. Sally responded that we can't expect long term stability before PS, look at what is happening with TCP; it's not stable. We are trying to do HS-TCP because the current TCP doesn't work in a large congestion window environment. Then there's the big tussle over the reset attack. The work within TCPM is robust to reordering, and it should have been done day one. TCP is not stable. If we want to wait for the specification to be completely stable, then it will never happen. Holding a bigger bar to DCCP and TFRC than TCP doesn't make sense. All changes Sally presented were text- no new mechanism. Eddie added another point: there were technical changes made to main specification. However, they were all sent to the list, and received no replies. He will release another draft once he's done a full read through. Not sure if this would address stability concerns of Magnus and Colin. The authors are now talking only to themselves. The draft will get stable in your perception that way. We need to get others to read whole document again. The last person to read the whole document was Magnus... if no one is going to do it again, what are we waiting for? Mark Handley added that he wouldn't object to delay if something would happen. More reviews, for example... Aaron asked who has read this version of specification: about 5 hands. He then asked who would commit to reading this version of the specification; another 10 raised their hands. Aaron said that he expects to see typos posted to list. If you can't find an error, he'll assume you haven't read. There's another two weeks after the IETF in the last call. He'll ask for more on the list if we need it. Colin thought this was unfair: people have been giving comments at every IETF, and there have been significant changes before each IETF. Aaron asked if there had to be one IETF meeting with no significant comments. Colin said the spec must be out there long enough to read and digest. Aaron said that the authors think the drafts are stable, and it is time for the community to look and see if it's stable. We can do that now, there is no need to wait four months. Eddie said that the current specification has a typo or two (see his presentation). He agrees that there have been technical changes in the last revision, but they were circulated to the list. He would not feel "bashed on" to be asked to come up with new revision of the main specification for last call. However, he also thinks that a last call on the current specification is OK. Randall Stewart said that he had the same opinion as Sally, having gone through the SCTP specification. You're going to make mistakes. The only way you're going to find them is by getting people to implement the specification. There will be other problems. he doesn't see any harm in going to proposed; you may have to cycle at proposed again based on changes. That's OK. In the end the document will be much better. Allison talked about the IESG's interpretation of proposed standard: * no known flaws (so fix the bug) * WGLC is on a document that had changes. We're now looking at the document since changes made. * There's no need to restart the LC, since the changes are in response to discussion. They see a lot of that - the document can go through big changes during WGLC; what's happening now is the response. She thinks it is appropriate. * Sometimes after IETF last call, the document gets a large change. They accept that. * There's no need to be overly conservative for proposed; we don't require deployment, but do require people think that the spec can be implemented. Her feeling is that it is time for IETF LC on this, and would encourage closure. Mark Allman said that he too agreed with sally; its not going to be perfect, it's never going to be perfect. The document will change (maybe big things) as an RFC. It's time to get a stable version that people can start implementing. Aaron ended the meeting with a charge to the WG to go forth and read the documents in last call. </xmp> |