Last Modified: 2003-02-10
- 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|
|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.|
DCCP meeting notes March 19th, 2003 IETF-56 ============================================ Notes taken by Aaron Falk <email@example.com> and Gorry Fairhurst <firstname.lastname@example.org>. Presentations available at http://www.isi.edu/~falk/dccp/ until the IETF-56 proceedings are online. ============================================ Chair's Summary - Aaron Falk <email@example.com> Introduction Other possible applications: pwe3, nfsv4, tls, ipfix Plans for a detailed protocol review Would like to do a public design review (at July 2003 IETF) Some implementations in Summer 2003 Schedule The April milestones are not going to be met! Suggested new schedule for comment: December 2003 - Publish specs February 2004 - Publish user guide - to be confirmed with AD (no objection from AD or group to the proposed schedule) Open issues the group needs to close: Header only checksum (UDPLite) Mobility Open issues the group doesn't need to close: RTP optimizations (for future rev) Long, fat network performance(for future rev) TFRC changes (will be handled elsewhere) ============================================ DCCP Spec Status - Eddie Kohler - ISSUE: will link layers support partial checksums? - a: 3Gwireless links - Allison: there's a mode in GSM & UMTS (not deployed yet) with a no-error checking option & a partial checksum for audio. A large deployment of these links. (Some say this is a bad engineering decision but it remains a fact.) So we should check this, and try to write up a list of known links that need this, can support this, and how they work. There is an argument that this could be a bad tradeoff in radio/link design that will not be repeated in network designs in the future. - Charles Moinia: I work with fiber channel. We have strong end-to-end CRCs at application layer and, so, are agnostic to the use of partial checksums at transport. - ???: Don't know of wireless links that exist that do this. It seems like these discussions are different to UDPLite, or are they the same? - Eddie Kohler, EK: The issues are the same. - Michael ??: most links do full packet checksums. However, some links want to send error-ed information. - Stuart Bryant: Some PWE3 services operate at high bit rate and there may be too much expense in doing full checksums, they'd prefer to keep processing to a minimum. - Mark Handley, MH: 1. Packets get corrupted in routers, links aren't the only place errors occur. 2. Dccp naturally separates congestion and corruption. 3. This is easy to do in transport, costs only four bits, has minimal complexity. It enables wireless folks to tailor links to work with separated congestion & corruption. - Allison: The need for UDPLite needs to be documented. - Sally: open research issue is how transport protocols respond to links with heavy corruption - Mark: (authentication): Authentication is a big deal, for some services. AH will work with or without the support of a DCCP checksum over the payload, since the IPSEC AH header protection is so much stronger than the DCCP packet checksum. DCCP may therefore use either partial or full protection - AH still provides strong coverage. - Colin Perkins: The usefulness of AH depends on what the intended purpose is, - Colin Perkins: There's also the idea of application-layer security, e.g. Secure RTP work. This also raised issues in this area of applications-level security. - Allison: DCCP needs to provide plenty of structured considerations and justification on this topic. Including guidelines to designer about why this feature is there and what it's used for. Also, need a guideline about authentication. Actually, the authentication issue may cause this feature to be blocked in the IESG. - Mark: The DCCP editors are not religious on this issue. DCCP just provides an easy way to do it. However, we'd remove this feature if it would cause the protocol to block. - Randy Presun: I'm trying to understand authentication issue. - Mark: DCCP would do authentication and application would reject error-ed payload. - Colin: That depends on what you are authenticating. You may just want to authenticate the sender, not the payload (which works with partial header checksums). - Allison: partial checksum may render MAC useless (as in SRTP) [Ed: I lost this comment.] - Eddie: One solution is to insist that IPsec use requires disabling partial checksum. - Colin: not sure about this, there may be applications where you wouldn't want to / need to do that. - Gorry: if you want to authenticate the whole packet, just disable partial checksums. - Jose Rey: Other networks also exist which could provide a link service that does not necessarily employ a frame CRC. The UMTS network has the possibility to deliver possibly corrupted payloads. This feature is currently unused. - ??: Endpoints may not know if IPsec is in use, e.g., tunnel mode, so one can't rely on IPsec authentication. - Julije: Are checksums end-to-end? - Eddie: Yes. We'll add a sentence to the spec saying checksum is e2e, not hop-by-hop. - ??: some link layers try a few times and give up. one _could_ say try a few times and send error-ed. - Mark: send examples of links and apps which would use this to the mail list. - ISSUE: Error-ed link bit - Mark: This bit must only a hint that errors might occur. Errors can still occur regardless of whether bit is set. - Gorry: Is there a link CRC? Eddie: yes. - Gorry: Not protecting the destination address raises the issue about what you are delivering to the Network receiver - and where in the network it may end up by accident. I think we must protect the header. - Eddie: Good point (this proposal appears dead). - Julije: It's bad to have transport mess with IP layer (in corruption allowed bit). propose asking IP layer to add a bit for this reason. [something else...?] - Eddie: need to bring this up on list - ISSUE: proposal to change 4 bit CSlen field to one bit. - Colin: You may want variable checksums to, say, cover the RTP header which can be variable if it goes through a mixer. - Mark: I can imagine a lot of applications which might want their headers protected. The question is: is it worth spending three bits for this purpose? Complexity is also a consideration. - Eddie: API might specify an RTP header is covered by the checksum, whatever length. - Colin: I feel there are uses for the four bits of control over checksum. - ISSUE: Welzl option to checksum only payload. The motivation was that UDPLite wanted to cover the next level protocol headers. There is a use for this, it is good for higher layer headers to be protected - A mask, allowing arbitrary bits to be protected, is not probably useful. - Colin: I agree with proposal not to adopt this option; we can get all we need with the four bits. - Mark: I like this option. It provides a general purpose mechanism for passing known corrupt packets to the upper layer. - Colin: It adds a lot of overhead. And, the apps which could use this are delay sensitive. - ISSUE: NATs changing ports, etc - Aaron: STUN, TURN can find ports. - Colin: but those tools only work in restricted cases. - Eddie: We don't want to rely on deployment of these technologies. - ISSUE: Purpose-Built Keys - Aaron: anyone here following this topic? - Yogesh: The send working group is using a similar mechanism. There is a problem with PBK in the computational cost of generating both keys. - ISSUE: NATS - Aaron: The issue is really not "NATS can't change seq numbers" but "middleboxes..." There are other boxes out there besides NATS that change sequence numbers. - ISSUE: RTP Interactions - Mark: There was a long discussion at the previous meeting about header size. The size, was often not critical, since critical links would do there own link-layer compression. We should avoid making the transport more complex and hence making link compression harder. - ISSUE: Long, Fat Networks (LFNs) - Mark Allman: Do you require TCP friendliness? - Eddie: No. For a while DCCP should be based on TCP. But there is no long term need. The spec says to follow IETF standards. - Allman: Is using seq number size based on TCP friendliness the right thing to do? - Eddie: This can be addressed in an option... - Mark: we have no idea about how to do congestion control with these massive windows; but don't want to close the door on future optimizations. if we need to do cc with million packet sized windows, we'll need to solve this problem. but may just have MB sized packets. At this point, the problem is not well-defined. - Colin: The assumption appears to be that seq numbers are used only for retransmissions and loss information but some apps may want to use them for FEC control which may have a very large window size. This is really a research idea and probably not an issue but we should think about whether 24 bits is enough. - Eddie: This is the same concern as having data from an old connection showing up... - Mark: One can always do epoch counters at application. Need to compromise between low overheads and very high end problem. At high end problem you can always add overhead. - Colin: The high end isn't that high compared to what people are doing today. I'm concerned about the bandwidth limits DCCP may be imposing. I'm doing gigabit streams today. - ISSUE: LFN Solution List - Comment: Slow rate apps don't need epoch option, any wraps in seq num space happened longer than 2 minutes; so epoch option is unnecessary overhead and may not want to do it. - ISSUE: Fragmentation -- Fragmentation was previously brought up as a WG discussion. In summary, the conclusion is to rely on IP fragmentation. - Colin: Shouldn't we do P-MTU discovery? - Eddie: This is about supporting moronic applications which may be overly simple and may not want to use PMTU information for request. - Mark: If you know you have a large amount of data, do PMTU discovery. If the application wants to send just a little bit more than will fit into the current segment, then it's not an issue. - Eddie: We can't mandate P-MTUD b/c of bad firewalls. - ISSUE: Shall we use the reserved bits to carry the CCID? - Mark: I think this is a good idea. One down-side is that this makes it hard for the link to compress this field, since it is in the DCCP header. The ROHC processing may work on a packet-by-packet basis without knowing any negotiated fields. - Eddie: We'll hear about compression issues later. - Eddie: There may be too many header parameters open for negotiation. We may need to reduce this, by making some mandatory - to discuss this on the list. - ISSUE: TFRC & codecs - Mark: Should TFRC (CCID=3) actually be required to send at the specified rate? The dynamics issues, etc need to be identified to know the space for implementation. We should add some text. ============================================ Nit Summary for CCID2 and CCID3 - Sally Floyd - DCCP should track TCP, e.g., in High Speed TCP - Appropriate Byte Counting - Allman: I am not quite clear. Are these byte-based things not being used in CCID2? - Sally: Yes, but we do need to think on a case-by-case basis how these carry forward in DCCP (which is packet-based). - Mark: There was a question on list which CCIDS are mandatory. Any feedback? - Eddie: What's the purpose of a mandatory ccid? - Sally: So that any receiver can talk to any sender. - Eddie: Hmm, not sure we can promise feature this in feature negotiation - Mark: good point, needs careful wording - Eddie: This is not always needed. A small device may wish to implement just one CCID. - Mark: If you implement DCCP as a stack, then you must provide the standard set, and we wish to have a fall-back position. Suggestion that we can amend the spec to include the simplest (single application) case. - Eddie: CCID1 is another candidate for the fall-back case. ============================================ DCCP Compression Profile for ROHC - Julije Ozegovic Presentation on ROHC activity considering DCCP header. There are issues in DCCP header design that would improve ROHC processing <see slides>. The aim is to get compression as good as for RTP/UDP. One optimization suggestion is to change DCCP, so that it can be more easily compressed. - Mark: (on the proposal for making ACKs part of generic header) Making ACKs a part of the base header raises other issues. There could be a difference in the packet length for congestion control - you can't take into account that the packet may be shorter on the link in question. ... - Mark West: I don't see why ACKs need to go into header. Treat the headers as separate headers but make pieces part of the same context. The DCCP spec shouldn't need to accommodate; it's more of an issue for ROHC. - Lars Erik (ROHC wg chair) - ROHC is not currently chartered to do DCCP header compression. Currently doing TCP compression work and looking at generic methods. - Lars Erik - the natural place to do this work is in ROHC with DCCP participation. - Mark: Document authors should be on both lists. ============================================ Implementation Reports - Aaron Falk - Implementations expected by ICIR, Sun, RealNetworks, Deval Mehta (note to list), and Vladimir Moltchanov of Nokia ============================================ Other Issues? - Mark: If we removed the UDPLite functionality, we could expand the sequence number field to 32 bits, assuming we also use the reserved value. I think we made the correct choice to use CSLen in the header. Are there other views? - Collin Perkins: I think we did make the right choice. But, I worry that there are not enough bits to cover the range of (higher layer protocol) header length we need to protect - Eddie: The CSLen field is in 32-bit words, you can get quite a lot of coverage for the current range of CSLen. - Collin Perkins: Aha, OK. - Eddie: I'd rather have CSLen than sequence number. - Mark: I get the impression that no-one is really pushing for more bits in the sequence number so current design seems OK.