@@ Page 1 @@ Internet Engineering Task Force Eddie Kohler INTERNET-DRAFT UCLA -draft-ietf-dccp-spec-11.txt Mark Handley -Expires: 10 September 2005 UCL +draft-ietf-dccp-spec-12b.txt Mark Handley +Expires: 1 June 2006 UCL Sally Floyd ICIR - 10 March 2005 + 1 December 2005 Datagram Congestion Control Protocol (DCCP) @@ Page 1 @@ Status of this Memo - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ Page 1 @@ The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on 10 September 2005. -Copyright Notice - Copyright (C) The Internet Society (2005). All Rights Reserved. + This Internet-Draft will expire on 1 June 2006. Abstract @@ Page 14, Section 4.2 @@ Used to resynchronize sequence numbers after large bursts of loss. -4.2. Sequence Numbers +4.2. Packet Sequencing Each DCCP packet carries a sequence number, so that losses can be detected and reported. Unlike TCP sequence numbers, which are byte- @@ Page 17, Section 4.4 @@ state immediately), and a server can request its client to hold TIMEWAIT state using the DCCP-CloseReq packet type. -4.4. Congestion Control +4.4. Congestion Control Mechanisms DCCP connections are congestion controlled, but unlike in TCP, DCCP applications have a choice of congestion control mechanism. In @@ Page 18, Section 4.5 @@ CCIDs 2 and 3 are fully defined in separate profile documents [CCID 2 PROFILE, CCID 3 PROFILE]. -4.5. Features +4.5. Connection Features DCCP endpoints use Change and Confirm options to negotiate and agree on feature values. Feature negotiation will almost always happen on @@ Page 23, Section 5.1 @@ DCCP APIs should treat port numbers similarly to TCP and UDP port numbers. For example, machines that distinguish between "privileged" and "unprivileged" ports for TCP and UDP should do - the same for DCCP. + the same for DCCP. See Section 19.9 for more discussion. Data Offset: 8 bits The offset from the start of the packet's DCCP header to the @@ Page 31, Section 5.6 @@ 12.3. 12-127, Reserved - Receivers should treat these codes like Reset Code 0, + Receivers should treat these codes as they do Reset Code 0, "Unspecified". 128-255, CCID-specific codes Semantics depend on the connection's CCIDs. See Section 10.3. - Receivers should treat unknown CCID-specific Reset Codes like - Reset Code 0, "Unspecified". + Receivers should treat unknown CCID-specific Reset Codes as they + do Reset Code 0, "Unspecified". The following table summarizes this information. @@ Page 39, Section 6.5 @@ that implements CCID 2 MUST support Ack Ratio and Send Ack Vector, for example. -6.5. Examples +6.5. Feature Negotiation Examples Here are three example feature negotiations for features located at the server, the first two for the Congestion Control ID feature, the last for the Ack Ratio. @@ Page 54, Section 7.5.4 @@ Endpoints MUST ignore sequence-invalid DCCP-Sync and DCCP-SyncAck packets, and MUST respond to other sequence-invalid packets with - (possibly rate-limited) DCCP-Sync packets. Each DCCP-Sync packet - MUST acknowledge the corresponding sequence-invalid packet's - Sequence Number, not GSR. The DCCP-Sync MUST use a new Sequence - Number, and thus will increase GSS; GSR will not change, however, - since the received packet was sequence-invalid. + (possibly rate-limited) DCCP-Sync packets. Each such DCCP-Sync + packet MUST use a new Sequence Number, and thus will increase GSS; + GSR will not change, however, since the received packet was + sequence-invalid. Each such DCCP-Sync packet's Acknowledgement + Number MUST equal GSR when the received sequence-invalid packet has + type DCCP-Reset, and the received packet's Sequence Number + otherwise. On receiving a sequence-valid DCCP-Sync packet, the peer endpoint (say, DCCP B) MUST update its GSR variable and reply with a DCCP- @@ Page 57, Section 7.5.6 @@ INTERNET-DRAFT Expires: 1 June 2006 December 2005 -7.5.6. Examples +7.5.6. Sequence Number Handling Examples In the following example, DCCP A and DCCP B recover from a large burst of loss that runs DCCP A's sequence numbers out of DCCP B's @@ Page 58, Section 7.6 @@ Set REF_low := low 24 bits of REF Set REF_hi := high 24 bits of REF If REF_low (<) S /* circular comparison mod 2^24 */ - && S |<| REF_low, /* conventional, non-circular + and S |<| REF_low, /* conventional, non-circular comparison */ Return (((REF_hi + 1) mod 2^24) << 24) | S + Otherwise, if S (<) REF_low and REF_low |<| S, + Return (((REF_hi - 1) mod 2^24) << 24) | S Otherwise, Return (REF_hi << 24) | S - - The two different kinds of comparison in the if statement detect + The two different kinds of comparison in the if statements detect when the low-order bits of the sequence space have wrapped. (The circular comparison "REF_low (<) S" returns true if and only if (S - REF_low), calculated using two's-complement arithmetic and then represented as an unsigned number, is less than or equal to 2^23 - (mod 2^24).) When this happens, the high-order bits are - incremented. + (mod 2^24).) When this happens, the high-order bits are incremented + or decremented, as appropriate. 7.6.1. Allow Short Sequence Numbers Feature @@ Page 60, Section 7.7.1 @@ receiver cannot always tell whether a burst of loss contained a non- data packet. -7.7.1. Usage Notes +7.7.1. NDP Count Usage Notes Say that K consecutive sequence numbers are missing in some burst of loss, and the Send NDP Count feature is on. Then some application @@ Page 62, Section 8.1.2 @@ discretion, be associated with more than one Service Code; this might let multiple applications, or multiple versions of the same application, listen on the same port, differentiated by Service - Code. If the DCCP-Request's Service Code doesn't match any of the + Code. If the DCCP-Request's Service Code doesn't equal any of the server's Service Codes for the given port, the server MUST reject the request by sending a DCCP-Reset packet with Reset Code 8, "Bad Service Code". A middlebox MAY also send such a DCCP-Reset in @@ Page 63, Section 8.1.2 @@ o Service Code 0 represents the absence of a meaningful Service Code, and MUST NOT be allocated. + o The value 4294967295 is an invalid Service Code. Servers MUST + reject any DCCP-Request with this Service Code value by sending a + DCCP-Reset packet with Reset Code 8, "Bad Service Code". This design for Service Code allocation is based on the allocation of 4-byte identifiers for Macintosh resources, PNG chunks, and TrueType and OpenType tables. + In text settings, we recommend that Service Codes be written in one + of three forms, prefixed by the ASCII letters SC and either a colon + ":" or equals sign "=". These forms are interpreted as follows. + + SC: Indicates a Service Code representable using a subset of the + ASCII characters. The colon is followed by between one and + four characters taken from the following set: letters, + digits, and the characters in "-_+.*/?@" (not including + quotes). Numerically, these characters have values in + {42-43, 45-57, 63-90, 95, 97-122}. The Service Code is + calculated by padding the string on the right with spaces + (value 32) and intepreting the four-character result as a + 32-bit big-endian number. + + SC= Indicates a decimal Service Code. The octothorp is followed + by any number of decimal digits, which specify the Service + Code. Values above 4294967294 are illegal. + + SC=x or SC=X + Indicates a hexadecimal Service Code. The "x" or "X" is + followed by any number of hexadecimal digits (upper or lower + + + + + + case), which specify the Service Code. Values above + 4294967294 are illegal. + + Thus, the Service Code 1717858426 might be represented in text as + either SC:fdpz, SC=1717858426, or SC=x6664707A. 8.1.3. Server Response @@ Page 69, Section 8.3 @@ the DCCP-CloseReq. DCCP-Data, DCCP-DataAck, and DCCP-Ack packets received in CLOSEREQ - or CLOSE states MAY be either processed or ignored. + or CLOSING states MAY be either processed or ignored. 8.3.1. Abnormal Termination @@ Page 71, Section 8.5 @@ return Step 2: Check ports and process TIMEWAIT state + /* Flow ID is 4-tuple */ Look up flow ID in table and get corresponding socket If no socket, or S.state == TIMEWAIT, Generate Reset(No Connection) unless P.type == Reset @@ Page 72, Section 8.5 @@ Choose S.ISS (initial seqno) or set from Init Cookie + Initialize S.GAR := S.ISS Set S.ISR, S.GSR, S.SWL, S.SWH from packet or Init Cookie Continue with S.state == RESPOND /* A Response packet will be generated in Step 11 */ @@ Page 72, Section 8.5 @@ If P.type != Sync, Update S.GAR Otherwise, - Send Sync packet acknowledging P.seqno + If P.type == Reset, + Send Sync packet acknowledging S.GSR + Otherwise, + Send Sync packet acknowledging P.seqno @@ Page 78, Section 9.3.2 @@ two or more are reserved. New connections start with Check Data Checksum 0 for both endpoints. -9.3.2. Usage Notes +9.3.2. Checksum Usage Notes Internet links must normally apply strong integrity checks to the packets they transmit [RFC 3828, RFC 3819]. This is the default @@ Page 110, Section 17.2 @@ Since DCCP doesn't provide reliable, ordered delivery, multiple application sub-flows may be multiplexed over a single DCCP connection with no inherent performance penalty. Thus, there is no - need for DCCP to provide built-in, SCTP-style support for multiple - sub-flows. + need for DCCP to provide built-in support for multiple sub-flows. + This differs from SCTP RFC 2960. Some applications might want to share congestion control state among multiple DCCP flows that share the same source and destination @@ Page 112, Section 19 @@ 19. IANA Considerations + IANA has assigned IP Protocol Number 33 to DCCP. DCCP introduces eight sets of numbers whose values should be allocated by IANA. We refer to allocation policies, such as Standards Action, outlined in RFC 2434, and most registries reserve some values for experimental and testing use [RFC 3692]. In - addition, DCCP requires a Protocol Number to be added to the - registry of Assigned Internet Protocol Numbers. IANA is requested - to assign IP Protocol Number 33 to DCCP; this number has already - been informally made available for experimental DCCP use. -19.1. Packet Types - Each entry in the DCCP Packet Type registry contains a packet type, + addition, DCCP requires that the IANA Port Numbers registry be + opened for DCCP port registrations; Section 19.9 describes how. + +19.1. Packet Types Registry + + Each entry in the DCCP Packet Types registry contains a packet type, which is a number in the range 0-15; a packet type name, such as DCCP-Request; and a reference to the RFC defining the packet type. The registry is initially populated using the values in Table 1 @@ Page 112, Section 19.2 @@ allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication. -19.2. Reset Codes - Each entry in the DCCP Reset Code registry contains a Reset Code, +19.2. Reset Codes Registry + + Each entry in the DCCP Reset Codes registry contains a Reset Code, which is a number in the range 0-255; a short description of the @@ Page 113, Section 19.3 @@ reserved for CCID-specific registries; each CCID Profile document describes how the corresponding registry is managed. -19.3. Option Types - Each entry in the DCCP option type registry contains an option type, - which is a number in the range 0-255; the name of the option, such - as "Slow Receiver"; and a reference to the RFC defining the option - type. The registry is initially populated using the values in Table - 3 (Section 5.8). This document allocates option types 0-2 and - 32-44, and option types 31 and 120-126 are permanently reserved for - experimental and testing use. Option types 3-30, 45-119, and 127 - are currently reserved, and should be allocated with the IETF +19.3. Option Types Registry + + Each entry in the DCCP option types registry contains an option + type, which is a number in the range 0-255; the name of the option, + such as "Slow Receiver"; and a reference to the RFC defining the + option type. The registry is initially populated using the values + in Table 3 (Section 5.8). This document allocates option types 0-2 + and 32-44, and option types 31 and 120-126 are permanently reserved + for experimental and testing use. Option types 3-30, 45-119, and + 127 are currently reserved, and should be allocated with the IETF Consensus policy, requiring an IETF RFC publication (standards-track or not) with IESG review and approval. Option types 128-255 are permanently reserved for CCID-specific registries; each CCID Profile document describes how the corresponding registry is managed. -19.4. Feature Numbers - Each entry in the DCCP feature number registry contains a feature +19.4. Feature Numbers Registry + + Each entry in the DCCP feature numbers registry contains a feature number, which is a number in the range 0-255; the name of the feature, such as "ECN Incapable"; and a reference to the RFC defining the feature number. The registry is initially populated @@ Page 113, Section 19.5 @@ CCID Profile document describes how the corresponding registry is managed. -19.5. Congestion Control Identifiers - Each entry in the DCCP Congestion Control Identifier (CCID) registry - contains a CCID, which is a number in the range 0-255; the name of - the CCID, such as "TCP-like Congestion Control"; and a reference to - the RFC defining the CCID. The registry is initially populated - using the values in Table 5 (Section 10). CCIDs 2 and 3 are - allocated by concurrently published profiles, and CCIDs 248-254 are - permanently reserved for experimental and testing use. CCIDs 0, 1, - 4-247, and 255 are currently reserved, and should be allocated with - the IETF Consensus policy, requiring an IETF RFC publication +19.5. Congestion Control Identifiers Registry + + Each entry in the DCCP Congestion Control Identifiers (CCID) + registry contains a CCID, which is a number in the range 0-255; the + name of the CCID, such as "TCP-like Congestion Control"; and a + reference to the RFC defining the CCID. The registry is initially + + + + + + populated using the values in Table 5 (Section 10). CCIDs 2 and 3 + are allocated by concurrently published profiles, and CCIDs 248-254 + are permanently reserved for experimental and testing use. CCIDs 0, + 1, 4-247, and 255 are currently reserved, and should be allocated + with the IETF Consensus policy, requiring an IETF RFC publication (standards-track or not) with IESG review and approval. - -19.6. Ack Vector States - Each entry in the DCCP Ack Vector State registry contains an Ack +19.6. Ack Vector States Registry + + Each entry in the DCCP Ack Vector States registry contains an Ack Vector State, which is a number in the range 0-3; the name of the State, such as "Received ECN Marked"; and a reference to the RFC defining the State. The registry is initially populated using the @@ Page 114, Section 19.7 @@ with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication. -19.7. Drop Codes - Each entry in the DCCP Drop Code registry contains a Data Dropped +19.7. Drop Codes Registry + + Each entry in the DCCP Drop Codes registry contains a Data Dropped Drop Code, which is a number in the range 0-7; the name of the Drop Code, such as "Application Not Listening"; and a reference to the RFC defining the Drop Code. The registry is initially populated @@ Page 114, Section 19.8 @@ should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication. -19.8. Service Codes - Each entry in the Service Code registry contains a Service Code, - which is a number in the range 0-4294967295; a short English +19.8. Service Codes Registry + + Each entry in the Service Codes registry contains a Service Code, + which is a number in the range 0-4294967294; a short English description of the intended service; and an optional reference to an RFC or other publicly available specification defining the Service Code. The registry should list the Service Code's numeric value as @@ Page 114, Section 19.8 @@ is in the range 32-127, the registry should also show a four- character ASCII interpretation of the Service Code. Thus, the number 1717858426 would additionally appear as "fdpz". Service - Codes are not DCCP-specific. This document does not allocate any - Service Codes, but Service Code 0 is permanently reserved (it - represents the absence of a meaningful Service Code), and Service - Codes 1056964608-1073741823 (high byte ASCII "?") are reserved for - Private Use. Most of the remaining Service Codes are allocated - First Come First Served, with no RFC publication required. - Exceptions are listed in Section 8.1.2. + Codes are not DCCP-specific. Service Code 0 is permanently reserved + (it represents the absence of a meaningful Service Code), and + Service Codes 1056964608-1073741823 (high byte ASCII "?") are + reserved for Private Use. Note that 4294967295 is not a valid + Service Code. Most of the remaining Service Codes are allocated + First Come First Served, with no RFC publication required; + exceptions are listed in Section 8.1.2. This document allocates a + single Service Code, 1145656131 ("DISC"). This corresponds to the + + + + + + discard service, which discards all data sent to the service and + sends no data in reply. + +19.9. Port Numbers Registry + + DCCP services may use contact port numbers to provide service to + unknown callers, as in TCP and UDP. IANA is therefore requested to + open the existing Port Numbers registry for DCCP using the following + rules, which we intend to mesh well with existing Port Numbers + registration procedures. + + Port numbers are divided into three ranges. The Well Known Ports + are those from 0 through 1023, the Registered Ports are those from + 1024 through 49151, and the Dynamic and/or Private Ports are those + from 49152 through 65535. Well Known and Registered Ports are + intended for use by server applications that desire a default + contact point on a system. On most systems, Well Known Ports can + only be used by system (or root) processes or by programs executed + by privileged users, while Registered Ports can be used by ordinary + user processes or programs executed by ordinary users. Dynamic + and/or Private Ports are intended for temporary use, including + client-side ports, out-of-band negotiated ports, and application + testing prior to registration of a dedicated port; they MUST NOT be + registered. + + The Port Numbers registry should accept registrations for DCCP ports + in the Well Known Ports and Registered Ports ranges. Well Known and + Registered Ports SHOULD NOT be used without registration. Although + in some cases -- such as porting an application from UDP to DCCP -- + it may seem natural to use a DCCP port before registration + completes, we emphasize that IANA will not guarantee registration of + particular Well Known and Registered Ports. Registrations should be + requested as early as possible. + + Each port registration SHALL include the following information: + + o A short port name, consisting entirely of letters (A-Z and a-z), + digits (0-9), and punctuation characters from "-_+./*" (not + including the quotes). + + o The port number that is requested to be registered. + + o A short English phrase describing the port's purpose. This MUST + include one or more space-separated textual Service Code + descriptors naming the port's corresponding Service Codes (see + Section 8.1.2). + + + + + + + + o Name and contact information for the person or entity performing + the registration, and possibly a reference to a document defining + the port's use. Registrations coming from IETF working groups + need only name the working group, but it is also recommended to + indicate a contact person. + + Registrants are encouraged to follow these guidelines when + submitting a registration. The guidelines may be violated at IANA's + discretion. + + o A port name SHOULD NOT be registered for more than one DCCP port + number. + + o A port name registered for UDP MAY be registered for DCCP as + well. Any such registration SHOULD use the same port number as + the existing UDP registration. + + o Concrete intent to use a port SHOULD precede port registration. + For example, existing UDP ports SHOULD NOT be registered in + advance of any intent to use those ports for DCCP. + + o A port name generally associated with TCP and/or SCTP SHOULD NOT + be registered for DCCP, since that port name implies reliable + transport. For example, we discourage registration of any "http" + port for DCCP. However, if such a registration makes sense (that + is, if there is concrete intent to use such a port), the DCCP + registration SHOULD use the same port number as the existing + registration. + + o Multiple DCCP registrations for the same port number are allowed + as long as the registrations' Service Codes do not overlap. + + This document registers the following port. (This should be + considered a model registration.) + + discard 9/dccp Discard SC:DISC + # IETF dccp WG, Eddie Kohler , DCCP RFC + + The discard service, which accepts DCCP connections on port 9, + discards all incoming application data and sends no data in + response. Thus, DCCP's discard port is analogous to TCP's discard + port, and might be used to check the health of a DCCP stack. 20. Thanks @@ Page 117, Section 20 @@ Lanphear, Patrick McManus, Colin Perkins, Sara Karlberg, Kevin Lai, Bernard Aboba, Youngsoo Choi, Pengfei Di, Dan Duchamp, Gorry Fairhurst, Derek Fawcus, David Timothy Fleeman, John Loughney, - Ghyslain Pelletier, Tom Phelan, Stanislav Shalunov, David Vos, Yufei - Wang, and Michael Welzl. In particular, Colin Perkins provided - extensive, detailed feedback, Michael Welzl suggested the Data - Checksum option, and Gorry Fairhurst provided extensive feedback on - various checksum issues. + Ghyslain Pelletier, Tom Phelan, Stanislav Shalunov, Somsak Vanit- + Anunchai, David Vos, Yufei Wang, and Michael Welzl. In particular, + Colin Perkins provided extensive, detailed feedback, Michael Welzl + suggested the Data Checksum option, Gorry Fairhurst provided + extensive feedback on various checksum issues, and Somsak Vanit- + Anunchai et al.'s Colored Petri Net model discovered a problem with + message exchange. A. Appendix: Ack Vector Implementation Notes @@ Page 118, Section 20 @@ <=== buf_head and buf_tail move this way <=== - Each `S,L' represents a State/Run length byte. We will draw these + Each "S,L" represents a State/Run length byte. We will draw these buffers showing only their live portion, and will add an annotation showing the Acknowledgement Number for the last live byte in the buffer. For example: