diff options
Diffstat (limited to 'doc/rfc/rfc4342.txt')
| -rw-r--r-- | doc/rfc/rfc4342.txt | 1851 |
1 files changed, 1851 insertions, 0 deletions
diff --git a/doc/rfc/rfc4342.txt b/doc/rfc/rfc4342.txt new file mode 100644 index 0000000..c57ca9b --- /dev/null +++ b/doc/rfc/rfc4342.txt @@ -0,0 +1,1851 @@ + + + + + + +Network Working Group S. Floyd +Request for Comments: 4342 ICIR +Category: Standards Track E. Kohler + UCLA + J. Padhye + Microsoft Research + March 2006 + + + Profile for Datagram Congestion Control Protocol (DCCP) + Congestion Control ID 3: TCP-Friendly Rate Control (TFRC) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document contains the profile for Congestion Control Identifier + 3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion + Control Protocol (DCCP). CCID 3 should be used by senders that want + a TCP-friendly sending rate, possibly with Explicit Congestion + Notification (ECN), while minimizing abrupt rate changes. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Conventions .....................................................3 + 3. Usage ...........................................................3 + 3.1. Relationship with TFRC .....................................4 + 3.2. Half-Connection Example ....................................4 + 4. Connection Establishment ........................................5 + 5. Congestion Control on Data Packets ..............................5 + 5.1. Response to Idle and Application-Limited Periods ...........7 + 5.2. Response to Data Dropped and Slow Receiver .................8 + 5.3. Packet Sizes ...............................................9 + 6. Acknowledgements ................................................9 + 6.1. Loss Interval Definition ..................................10 + 6.1.1. Loss Interval Lengths ..............................12 + 6.2. Congestion Control on Acknowledgements ....................13 + + + +Floyd, et al. Standards Track [Page 1] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + 6.3. Acknowledgements of Acknowledgements ......................13 + 6.4. Determining Quiescence ....................................14 + 7. Explicit Congestion Notification ...............................14 + 8. Options and Features ...........................................14 + 8.1. Window Counter Value ......................................15 + 8.2. Elapsed Time Options ......................................17 + 8.3. Receive Rate Option .......................................17 + 8.4. Send Loss Event Rate Feature ..............................18 + 8.5. Loss Event Rate Option ....................................18 + 8.6. Loss Intervals Option .....................................18 + 8.6.1. Option Details .....................................19 + 8.6.2. Example ............................................20 + 9. Verifying Congestion Control Compliance with ECN ...............22 + 9.1. Verifying the ECN Nonce Echo ..............................22 + 9.2. Verifying the Reported Loss Intervals and Loss + Event Rate ................................................23 + 10. Implementation Issues .........................................23 + 10.1. Timestamp Usage ..........................................23 + 10.2. Determining Loss Events at the Receiver ..................24 + 10.3. Sending Feedback Packets .................................25 + 11. Security Considerations .......................................27 + 12. IANA Considerations ...........................................28 + 12.1. Reset Codes ..............................................28 + 12.2. Option Types .............................................28 + 12.3. Feature Numbers ..........................................28 + 13. Thanks ........................................................29 + A. Appendix: Possible Future Changes to CCID 3 ....................30 + Normative References ..............................................31 + Informative References ............................................31 + +List of Tables + + Table 1: DCCP CCID 3 Options ......................................14 + Table 2: DCCP CCID 3 Feature Numbers ..............................15 + +1. Introduction + + This document contains the profile for Congestion Control Identifier + 3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion + Control Protocol (DCCP) [RFC4340]. DCCP uses Congestion Control + Identifiers, or CCIDs, to specify the congestion control mechanism in + use on a half-connection. + + TFRC is a receiver-based congestion control mechanism that provides a + TCP-friendly sending rate while minimizing the abrupt rate changes + characteristic of TCP or of TCP-like congestion control [RFC3448]. + The sender's allowed sending rate is set in response to the loss + + + + +Floyd, et al. Standards Track [Page 2] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + event rate, which is typically reported by the receiver to the + sender. See Section 3 for more on application requirements. + +2. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + All multi-byte numerical quantities in CCID 3, such as arguments to + options, are transmitted in network byte order (most significant byte + first). + + A DCCP half-connection consists of the application data sent by one + endpoint and the corresponding acknowledgements sent by the other + endpoint. The terms "HC-Sender" and "HC-Receiver" denote the + endpoints sending application data and acknowledgements, + respectively. Since CCIDs apply at the level of half-connections, we + abbreviate HC-Sender to "sender" and HC-Receiver to "receiver" in + this document. See [RFC4340] for more discussion. + + For simplicity, we say that senders send DCCP-Data packets and + receivers send DCCP-Ack packets. Both of these categories are meant + to include DCCP-DataAck packets. + + The phrases "ECN-marked" and "marked" refer to packets marked ECN + Congestion Experienced unless otherwise noted. + + This document uses a number of variables from [RFC3448], including + the following: + + o X_recv: The receive rate in bytes per second. See [RFC3448], + Section 3.2.2. + + o s: The packet size in bytes. See [RFC3448], Section 3.1. + + o p: The loss event rate. See [RFC3448], Section 3.1. + +3. Usage + + CCID 3's TFRC congestion control is appropriate for flows that would + prefer to minimize abrupt changes in the sending rate, including + streaming media applications with small or moderate receiver + buffering before playback. TCP-like congestion control, such as that + of DCCP's CCID 2 [RFC4341], halves the sending rate in response to + each congestion event and thus cannot provide a relatively smooth + sending rate. + + + + +Floyd, et al. Standards Track [Page 3] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + As explained in [RFC3448], Section 1, the penalty of having smoother + throughput than TCP while competing fairly for bandwidth with TCP is + that the TFRC mechanism in CCID 3 responds slower to changes in + available bandwidth than do TCP or TCP-like mechanisms. Thus, CCID 3 + should only be used for applications with a requirement for smooth + throughput. For applications that simply need to transfer as much + data as possible in as short a time as possible, we recommend using + TCP-like congestion control, such as CCID 2. + + CCID 3 should also not be used by applications that change their + sending rate by varying the packet size, rather than by varying the + rate at which packets are sent. A new CCID will be required for + these applications. + +3.1. Relationship with TFRC + + The congestion control mechanisms described here follow the TFRC + mechanism standardized by the IETF [RFC3448]. Conforming CCID 3 + implementations MAY track updates to the TCP throughput equation + directly, as updates are standardized in the IETF, rather than wait + for revisions of this document. However, conforming implementations + SHOULD wait for explicit updates to CCID 3 before implementing other + changes to TFRC congestion control. + +3.2. Half-Connection Example + + This example shows the typical progress of a half-connection using + CCID 3's TFRC Congestion Control, not including connection initiation + and termination. The example is informative, not normative. + + 1. The sender transmits DCCP-Data packets. Its sending rate is + governed by the allowed transmit rate as specified in [RFC3448], + Section 3.2. Each DCCP-Data packet has a sequence number and the + DCCP header's CCVal field contains the window counter value, which + is used by the receiver in determining when multiple losses belong + in a single loss event. + + In the typical case of an ECN-capable half-connection, each DCCP- + Data and DCCP-DataAck packet is sent as ECN Capable, with either + the ECT(0) or the ECT(1) codepoint set. The use of the ECN Nonce + with TFRC is described in Section 9. + + 2. The receiver sends DCCP-Ack packets acknowledging the data packets + at least once per round-trip time, unless the sender is sending at + a rate of less than one packet per round-trip time, as indicated + by the TFRC specification ([RFC3448], Section 6). Each DCCP-Ack + packet uses a sequence number, identifies the most recent packet + + + + +Floyd, et al. Standards Track [Page 4] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + received from the sender, and includes feedback about the recent + loss intervals experienced by the receiver. + + 3. The sender continues sending DCCP-Data packets as controlled by + the allowed transmit rate. Upon receiving DCCP-Ack packets, the + sender updates its allowed transmit rate as specified in + [RFC3448], Section 4.3. This update is based on a loss event rate + calculated by the sender using the receiver's loss intervals + feedback. If it prefers, the sender can also use a loss event + rate calculated and reported by the receiver. + + 4. The sender estimates round-trip times and calculates a nofeedback + time, as specified in [RFC3448], Section 4.4. If no feedback is + received from the receiver in that time (at least four round-trip + times), the sender halves its sending rate. + +4. Connection Establishment + + The client initiates the connection by using mechanisms described in + the DCCP specification [RFC4340]. During or after CCID 3 + negotiation, the client and/or server may want to negotiate the + values of the Send Ack Vector and Send Loss Event Rate features. + +5. Congestion Control on Data Packets + + CCID 3 uses the congestion control mechanisms of TFRC [RFC3448]. The + following discussion summarizes information from [RFC3448], which + should be considered normative except where specifically indicated + otherwise. + + Loss Event Rate + + The basic operation of CCID 3 centers around the calculation of a + loss event rate: the number of loss events as a fraction of the + number of packets transmitted, weighted over the last several loss + intervals. This loss event rate, a round-trip time estimate, and the + average packet size are plugged into the TCP throughput equation, as + specified in [RFC3448], Section 3.1. The result is a fair transmit + rate close to what a modern TCP would achieve in the same conditions. + CCID 3 senders are limited to this fair rate. + + The loss event rate itself is calculated in CCID 3 using recent loss + interval lengths reported by the receiver. Loss intervals are + precisely defined in Section 6.1. In summary, a loss interval is up + to 1 RTT of possibly lost or ECN-marked data packets, followed by an + arbitrary number of non-dropped, non-marked data packets. Thus, long + loss intervals represent low congestion rates. The CCID 3 Loss + + + + +Floyd, et al. Standards Track [Page 5] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + Intervals option is used to report loss interval lengths; see Section + 8.6. + + Other Congestion Control Mechanisms + + The sender starts in a slow-start phase, roughly doubling its allowed + sending rate each round-trip time. The slow-start phase is ended by + the receiver's report of a data packet drop or mark, after which the + sender uses the loss event rate to calculate its allowed sending + rate. + + [RFC3448], Section 4, specifies an initial sending rate of one packet + per round-trip time (RTT) as follows: The sender initializes the + allowed sending rate to one packet per second. As soon as a feedback + packet is received from the receiver, the sender has a measurement of + the round-trip time and then sets the initial allowed sending rate to + one packet per RTT. However, while the initial TCP window used to be + one segment, [RFC2581] allows an initial TCP window of two segments, + and [RFC3390] allows an initial TCP window of three or four segments + (up to 4380 bytes). [RFC3390] gives an upper bound on the initial + window of min(4*MSS, max(2*MSS, 4380 bytes)). + + Therefore, in contrast to [RFC3448], the initial CCID 3 sending rate + is allowed to be at least two packets per RTT, and at most four + packets per RTT, depending on the packet size. The initial rate is + only allowed to be three or four packets per RTT when, in terms of + segment size, that translates to at most 4380 bytes per RTT. + + The sender's measurement of the round-trip time uses the Elapsed Time + and/or Timestamp Echo option contained in feedback packets, as + described in Section 8.2. The Elapsed Time option is required, while + the Timestamp Echo option is not. The sender maintains an average + round-trip time heavily weighted on the most recent measurements. + + Each DCCP-Data packet contains a sequence number. Each DCCP-Data + packet also contains a window counter value, as described in Section + 8.1. The window counter is generally incremented by one every + quarter round-trip time. The receiver uses it as a coarse-grained + timestamp to determine when a packet loss should be considered part + of an existing loss interval and when it must begin a new loss + interval. + + Because TFRC is rate-based instead of window-based, and because + feedback packets can be dropped in the network, the sender needs some + mechanism for reducing its sending rate in the absence of positive + feedback from the receiver. As described in Section 6, the receiver + sends feedback packets roughly once per round-trip time. As + specified in [RFC3448], Section 4.3, the sender sets a nofeedback + + + +Floyd, et al. Standards Track [Page 6] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + timer to at least four round-trip times, or to twice the interval + between data packets, whichever is larger. If the sender hasn't + received a feedback packet from the receiver when the nofeedback + timer expires, then the sender halves its allowed sending rate. The + allowed sending rate is never reduced below one packet per 64 + seconds. Note that not all acknowledgements are considered feedback + packets, since feedback packets must contain valid Loss Intervals, + Elapsed Time, and Receive Rate options. + + If the sender never receives a feedback packet from the receiver, and + as a consequence never gets to set the allowed sending rate to one + packet per RTT, then the sending rate is left at its initial rate of + one packet per second, with the nofeedback timer expiring after two + seconds. The allowed sending rate is halved each time the nofeedback + timer expires. Thus, if no feedback is received from the receiver, + the allowed sending rate is never above one packet per second and is + quickly reduced below one packet per second. + + The feedback packets from the receiver contain a Receive Rate option + specifying the rate at which data packets arrived at the receiver + since the last feedback packet. The allowed sending rate can be at + most twice the rate received at the receiver in the last round-trip + time. This may be less than the nominal fair rate if, for example, + the application is sending less than its fair share. + +5.1. Response to Idle and Application-Limited Periods + + One consequence of the nofeedback timer is that the sender reduces + the allowed sending rate when the sender has been idle for a + significant period of time. In [RFC3448], Section 4.4, the allowed + sending rate is never reduced to fewer than two packets per round- + trip time as the result of an idle period. CCID 3 revises this to + take into account the larger initial windows allowed by [RFC3390]: + the allowed sending rate is never reduced to less than the [RFC3390] + initial sending rate as the result of an idle period. If the allowed + sending rate is less than the initial sending rate upon entry to the + idle period, then it will still be less than the initial sending rate + when the idle period is exited. However, if the allowed sending rate + is greater than or equal to the initial sending rate upon entry to + the idle period, then it should not be reduced below the initial + sending rate no matter how long the idle period lasts. + + The sender's allowed sending rate is limited to at most twice the + receive rate reported by the receiver. Thus, after an application- + limited period, the sender can at most double its sending rate from + one round-trip time to the next, until it reaches the allowed sending + rate determined by the loss event rate. + + + + +Floyd, et al. Standards Track [Page 7] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + +5.2. Response to Data Dropped and Slow Receiver + + DCCP's Data Dropped option lets a receiver declare that a packet was + dropped at the end host before delivery to the application -- for + instance, because of corruption or receive buffer overflow. Its Slow + Receiver option lets a receiver declare that it is having trouble + keeping up with the sender's packets, although nothing has yet been + dropped. CCID 3 senders respond to these options as described in + [RFC4340], with the following further clarifications. + + o Drop Code 2 ("receive buffer drop"). The allowed sending rate is + reduced by one packet per RTT for each packet newly acknowledged + as Drop Code 2, except that it is never reduced below one packet + per RTT as a result of Drop Code 2. + + o Adjusting the receive rate X_recv. A CCID 3 sender SHOULD also + respond to non-network-congestion events, such as those implied by + Data Dropped and Slow Receiver options, by adjusting X_recv, the + receive rate reported by the receiver in Receive Rate options (see + Section 8.3). The CCID 3 sender's allowed sending rate is limited + to at most twice the receive rate reported by the receiver via the + "min(..., 2*X_recv)" clause in TFRC's throughput calculations + ([RFC3448], Section 4.3). When the sender receives one or more + Data Dropped and Slow Receiver options, the sender adjusts X_recv + as follows: + + 1. X_inrecv is equal to the Receive Rate in bytes per second + reported by the receiver in the most recent acknowledgement. + + 2. X_drop is set to the sending rate upper bound implied by Data + Dropped and Slow Receiver options. If the sender receives a + Slow Receiver option, which requests that the sender not + increase its sending rate for roughly a round-trip time + [RFC4340], then X_drop should be set to X_inrecv. Similarly, + if the sender receives a Data Dropped option indicating, for + example, that three packets were dropped with Drop Code 2, then + the upper bound on the sending rate will be decreased by at + most three packets per RTT, by the sender setting X_drop to + + max(X_inrecv - 3*s/RTT, min(X_inrecv, s/RTT)). + + Again, s is the packet size in bytes. + + 3. X_recv is then set to min(X_inrecv, X_drop/2). + + As a result, the next round-trip time's sending rate will be + limited to at most 2*(X_drop/2) = X_drop. The effects of the Slow + Receiver and Data Dropped options on X_recv will mostly vanish by + + + +Floyd, et al. Standards Track [Page 8] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + the round-trip time after that, which is appropriate for this + non-network-congestion feedback. This procedure MUST only be used + for those Drop Codes not related to corruption (see [RFC4340]). + Currently, this is limited to Drop Codes 0, 1, and 2. + +5.3. Packet Sizes + + CCID 3 is intended for applications that use a fixed packet size, and + that vary their sending rate in packets per second in response to + congestion. CCID 3 is not appropriate for applications that require + a fixed interval of time between packets and vary their packet size + instead of their packet rate in response to congestion. However, + some attention might be required for applications using CCID 3 that + vary their packet size not in response to congestion, but in response + to other application-level requirements. + + The packet size s is used in the TCP throughput equation. A CCID 3 + implementation MAY calculate s as the segment size averaged over + multiple round trip times -- for example, over the most recent four + loss intervals, for loss intervals as defined in Section 6.1. + Alternately, a CCID 3 implementation MAY use the Maximum Packet Size + to derive s. In this case, s is set to the Maximum Segment Size + (MSS), the maximum size in bytes for the data segment, not including + the default DCCP and IP packet headers. Each packet transmitted then + counts as one MSS, regardless of the actual segment size, and the TCP + throughput equation can be interpreted as specifying the sending rate + in packets per second. + + CCID 3 implementations MAY check for applications that appear to be + manipulating the packet size inappropriately. For example, an + application might send small packets for a while, building up a fast + rate, then switch to large packets to take advantage of the fast + rate. (Preliminary simulations indicate that applications may not be + able to increase their overall transfer rates this way, so it is not + clear that this manipulation will occur in practice [V03].) + +6. Acknowledgements + + The receiver sends a feedback packet to the sender roughly once per + round-trip time, if the sender is sending packets that frequently. + This rate is determined by the TFRC protocol as specified in + [RFC3448], Section 6. + + Each feedback packet contains an Acknowledgement Number, which equals + the greatest valid sequence number received so far on this + connection. ("Greatest" is, of course, measured in circular sequence + space.) Each feedback packet also includes at least the following + options: + + + +Floyd, et al. Standards Track [Page 9] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + 1. An Elapsed Time and/or Timestamp Echo option specifying the amount + of time elapsed since the arrival at the receiver of the packet + whose sequence number appears in the Acknowledgement Number field. + These options are described in [RFC4340], Section 13. + + 2. A Receive Rate option, defined in Section 8.3, specifying the rate + at which data was received since the last DCCP-Ack was sent. + + 3. A Loss Intervals option, defined in Section 8.6, specifying the + most recent loss intervals experienced by the receiver. (The + definition of a loss interval is provided below.) From Loss + Intervals, the sender can easily calculate the loss event rate p + using the procedure described in [RFC3448], Section 5.4. + + Acknowledgements not containing at least these three options are not + considered feedback packets. + + The receiver MAY also include other options concerning the loss event + rate, including Loss Event Rate, which gives the loss event rate + calculated by the receiver (Section 8.5), and DCCP's generic Ack + Vector option, which reports the specific sequence numbers of any + lost or marked packets ([RFC4340], Section 11.4). Ack Vector is not + required by CCID 3's congestion control mechanisms: the Loss + Intervals option provides all the information needed to manage the + transmit rate and probabilistically verify receiver feedback. + However, Ack Vector may be useful for applications that need to + determine exactly which packets were lost. The receiver MAY also + include other acknowledgement-related options, such as DCCP's Data + Dropped option ([RFC4340], Section 11.7). + + If the HC-Receiver is also sending data packets to the HC-Sender, + then it MAY piggyback acknowledgement information on those data + packets more frequently than TFRC's specified acknowledgement rate + allows. + +6.1. Loss Interval Definition + + As described in [RFC3448], Section 5.2, a loss interval begins with a + lost or ECN-marked data packet; continues with at most one round-trip + time's worth of packets that may or may not be lost or marked; and + completes with an arbitrarily long series of non-dropped, non-marked + data packets. For example, here is a single loss interval, assuming + that sequence numbers increase as you move right: + + + + + + + + +Floyd, et al. Standards Track [Page 10] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + Lossy Part + <= 1 RTT __________ Lossless Part __________ + / \/ \ + *----*--*--*------------------------------------- + ^ ^ ^ ^ + losses or marks + + Note that a loss interval's lossless part might be empty, as in the + first interval below: + + Lossy Part Lossy Part + <= 1 RTT <= 1 RTT _____ Lossless Part _____ + / \/ \/ \ + *----*--*--***--------*-*--------------------------- + ^ ^ ^ ^^^ ^ ^ + \_ Int. 1 _/\_____________ Interval 2 _____________/ + + As in [RFC3448], Section 5.2, the length of the lossy part MUST be + less than or equal to 1 RTT. CCID 3 uses window counter values, not + receive times, to determine whether multiple packets occurred in the + same RTT and thus belong to the same loss event; see Section 10.2. A + loss interval whose lossy part lasts for more than 1 RTT, or whose + lossless part contains a dropped or marked data packet, is invalid. + + A missing data packet doesn't begin a new loss interval until NDUPACK + packets have been seen after the "hole", where NDUPACK = 3. Thus, up + to NDUPACK of the most recent sequence numbers (including the + sequence numbers of any holes) might temporarily not be part of any + loss interval while the implementation waits to see whether a hole + will be filled. See [RFC3448], Section 5.1, and [RFC2581], Section + 3.2, for further discussion of NDUPACK. + + As specified by [RFC3448], Section 5, all loss intervals except the + first begin with a lost or marked data packet, and all loss intervals + are as long as possible, subject to the validity constraints above. + + Lost and ECN-marked non-data packets may occur freely in the lossless + part of a loss interval. (Non-data packets consist of those packet + types that cannot carry application data; namely, DCCP-Ack, DCCP- + Close, DCCP-CloseReq, DCCP-Reset, DCCP-Sync, and DCCP-SyncAck.) In + the absence of better information, a receiver MUST conservatively + assume that every lost packet was a data packet and thus must occur + in some lossy part. DCCP's NDP Count option can help the receiver + determine whether a particular packet contained data; see [RFC4340], + Section 7.7. + + + + + + +Floyd, et al. Standards Track [Page 11] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + +6.1.1. Loss Interval Lengths + + [RFC3448] defines the TFRC congestion control mechanism in terms of a + one-way transfer of data, with data packets going from the sender to + the receiver and feedback packets going from the receiver back to the + sender. However, CCID 3 applies in a context of two half- + connections, with DCCP-Data and DCCP-DataAck packets from one half- + connection sharing sequence number space with DCCP-Ack packets from + the other half-connection. For the purposes of CCID 3 congestion + control, loss interval lengths should include data packets and should + exclude the acknowledgement packets from the reverse half-connection. + However, it is also useful to report the total number of packets in + each loss interval (for example, to facilitate ECN Nonce + verification). + + CCID 3's Loss Intervals option thus reports three lengths for each + loss interval, the lengths of the lossy and lossless parts defined + above and a separate data length. First, the lossy and lossless + lengths are measured in sequence numbers. Together, they sum to the + interval's sequence length, which is the total number of packets the + sender transmitted during the interval. This is easily calculated in + DCCP as the greatest packet sequence number in the interval minus the + greatest packet sequence number in the preceding interval (or, if + there is no preceding interval, then the predecessor to the half- + connection's initial sequence number). The interval's data length, + however, is the number used in TFRC's loss event rate calculation, as + defined in [RFC3448], Section 5, and is calculated as follows. + + For all loss intervals except the first, the data length equals the + sequence length minus the number of non-data packets the sender + transmitted during the loss interval, except that the minimum data + length is one packet. In the absence of better information, an + endpoint MUST conservatively assume that the loss interval contained + only data packets, in which case the data length equals the sequence + length. To achieve greater precision, the sender can calculate the + exact number of non-data packets in an interval by remembering which + sent packets contained data; the receiver can account for received + non-data packets by not including them in the data length, and for + packets that were not received, it may be able to discriminate + between lost data packets and lost non-data packets using DCCP's NDP + Count option. + + The first loss interval's data length is undefined until the first + loss event. [RFC3448], Section 6.3.1 specifies how the first loss + interval's data length is calculated once the first loss event has + occurred; this calculation uses X_recv, the most recent receive rate, + as input. Until this first loss event, the loss event rate is zero, + + + + +Floyd, et al. Standards Track [Page 12] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + as is the data length reported for the interval in the Loss Intervals + option. + + The first loss interval's data length might be less than, equal to, + or even greater than its sequence length. Any other loss interval's + data length must be less than or equal to its sequence length. + + A sender MAY use the loss event rate or loss interval data lengths as + reported by the receiver, or it MAY recalculate loss event rate + and/or loss interval data lengths based on receiver feedback and + additional information. For example, assume the network drops a + DCCP-Ack packet with sequence number 50. The receiver might then + report a loss interval beginning at sequence number 50. If the + sender determined that this loss interval actually contained no lost + or ECN-marked data packets, then it might coalesce the loss interval + with the previous loss interval, resulting in a larger allowed + transmit rate. + +6.2. Congestion Control on Acknowledgements + + The rate and timing for generating acknowledgements is determined by + the TFRC algorithm ([RFC3448], Section 6). The sending rate for + acknowledgements is relatively low -- roughly once per round-trip + time -- so there is no need for explicit congestion control on + acknowledgements. + +6.3. Acknowledgements of Acknowledgements + + TFRC acknowledgements don't generally need to be reliable, so the + sender generally need not acknowledge the receiver's + acknowledgements. When Ack Vector or Data Dropped is used, however, + the sender, DCCP A, MUST occasionally acknowledge the receiver's + acknowledgements so that the receiver can free up Ack Vector or Data + Dropped state. When both half-connections are active, the necessary + acknowledgements will be contained in A's acknowledgements to B's + data. If the B-to-A half-connection goes quiescent, however, DCCP A + must send an acknowledgement proactively. + + Thus, when Ack Vector or Data Dropped is used, an active sender MUST + acknowledge the receiver's acknowledgements approximately once per + round-trip time, within a factor of two or three, probably by sending + a DCCP-DataAck packet. No acknowledgement options are necessary, + just the Acknowledgement Number in the DCCP-DataAck header. + + The sender MAY choose to acknowledge the receiver's acknowledgements + even if they do not contain Ack Vectors or Data Dropped options. For + instance, regular acknowledgements can shrink the size of the Loss + Intervals option. Unlike Ack Vector and Data Dropped, however, the + + + +Floyd, et al. Standards Track [Page 13] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + Loss Intervals option is bounded in size (and receiver state), so + acks-of-acks are not required. + +6.4. Determining Quiescence + + This section describes how a CCID 3 receiver determines that the + corresponding sender is not sending any data and therefore has gone + quiescent. See [RFC4340], Section 11.1, for general information on + quiescence. + + Let T equal the greater of 0.2 seconds and two round-trip times. (A + CCID 3 receiver has a rough measure of the round-trip time so that it + can pace its acknowledgements.) The receiver detects that the sender + has gone quiescent after T seconds have passed without receiving any + additional data from the sender. + +7. Explicit Congestion Notification + + CCID 3 supports Explicit Congestion Notification (ECN) [RFC3168]. In + the typical case of an ECN-capable half-connection (where the + receiver's ECN Incapable feature is set to zero), the sender will use + the ECN Nonce for its data packets, as specified in [RFC4340], + Section 12.2. Information about the ECN Nonce MUST be returned by + the receiver using the Loss Intervals option, and any Ack Vector + options MUST include the ECN Nonce Sum. The sender MAY maintain a + table with the ECN nonce sum for each packet and use this information + to probabilistically verify the ECN nonce sums returned in Loss + Intervals or Ack Vector options. Section 9 describes this further. + +8. Options and Features + + CCID 3 can make use of DCCP's Ack Vector, Timestamp, Timestamp Echo, + and Elapsed Time options, and its Send Ack Vector and ECN Incapable + features. In addition, the following CCID-specific options are + defined for use with CCID 3. + + Option DCCP- Section + Type Length Meaning Data? Reference + ----- ------ ------- ----- --------- + 128-191 Reserved + 192 6 Loss Event Rate N 8.5 + 193 variable Loss Intervals N 8.6 + 194 6 Receive Rate N 8.3 + 195-255 Reserved + + Table 1: DCCP CCID 3 Options + + + + + +Floyd, et al. Standards Track [Page 14] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + The "DCCP-Data?" column indicates that all currently defined CCID 3- + specific options MUST be ignored when they occur on DCCP-Data + packets. + + The following CCID-specific feature is also defined. + + Rec'n Initial Section + Number Meaning Rule Value Req'd Reference + ------ ------- ----- ----- ----- --------- + 128-191 Reserved + 192 Send Loss Event Rate SP 0 N 8.4 + 193-255 Reserved + + Table 2: DCCP CCID 3 Feature Numbers + + The column meanings are described in [RFC4340], Table 4. "Rec'n + Rule" defines the feature's reconciliation rule, where "SP" means + server-priority. "Req'd" specifies whether every CCID 3 + implementation MUST understand a feature; Send Loss Event Rate is + optional, in that it behaves like an extension ([RFC4340], Section + 15). + +8.1. Window Counter Value + + The data sender stores a 4-bit window counter value in the DCCP + generic header's CCVal field on every data packet it sends. This + value is set to 0 at the beginning of the transmission and generally + increased by 1 every quarter of a round-trip time, as described in + [RFC3448], Section 3.2.1. Window counters use circular arithmetic + modulo 16 for all operations, including comparisons; see [RFC4340], + Section 3.1, for more information on circular arithmetic. For + reference, the DCCP generic header is as follows. (The diagram is + repeated from [RFC4340], Section 5.1, which also shows the generic + header with a 24-bit Sequence Number field.) + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source Port | Dest Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Offset | CCVal | CsCov | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Res | Type |1| Reserved | Sequence Number (high bits) . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . Sequence Number (low bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + +Floyd, et al. Standards Track [Page 15] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + The CCVal field has enough space to express 4 round-trip times at + quarter-RTT granularity. The sender MUST avoid wrapping CCVal on + adjacent packets, as might happen, for example, if two data-carrying + packets were sent 4 round-trip times apart with no packets + intervening. Therefore, the sender SHOULD use the following + algorithm for setting CCVal. The algorithm uses three variables: + "last_WC" holds the last window counter value sent, "last_WC_time" is + the time at which the first packet with window counter value + "last_WC" was sent, and "RTT" is the current round-trip time + estimate. last_WC is initialized to zero, and last_WC_time to the + time of the first packet sent. Before sending a new packet, proceed + like this: + + Let quarter_RTTs = floor((current_time - last_WC_time) / (RTT/4)). + If quarter_RTTs > 0, then: + Set last_WC := (last_WC + min(quarter_RTTs, 5)) mod 16. + Set last_WC_time := current_time. + Set the packet header's CCVal field to last_WC. + + When this algorithm is used, adjacent data-carrying packets' CCVal + counters never differ by more than five, modulo 16. + + The window counter value may also change as feedback packets arrive. + In particular, after receiving an acknowledgement for a packet sent + with window counter WC, the sender SHOULD increase its window + counter, if necessary, so that subsequent packets have window counter + value at least (WC + 4) mod 16. + + The CCVal counters are used by the receiver to determine whether + multiple losses belong to a single loss event, to determine the + interval to use for calculating the receive rate, and to determine + when to send feedback packets. None of these procedures require the + receiver to maintain an explicit estimate of the round-trip time. + However, implementors who wish to keep such an RTT estimate may do so + using CCVal. Let T(I) be the arrival time of the earliest valid + received packet with CCVal = I. (Of course, when the window counter + value wraps around to the same value mod 16, we must recalculate + T(I).) Let D = 2, 3, or 4 and say that T(K) and T(K+D) both exist + (packets were received with window counters K and K+D). Then the + value (T(K+D) - T(K)) * 4/D MAY serve as an estimate of the round- + trip time. Values of D = 4 SHOULD be preferred for RTT estimation. + Concretely, say that the following packets arrived: + + Time: T1 T2 T3 T4 T5 T6 T7 T8 T9 + ------*---*---*-*----*------------*---*----*--*----> + CCVal: K-1 K-1 K K K+1 K+3 K+4 K+3 K+4 + + + + + +Floyd, et al. Standards Track [Page 16] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + Then T7 - T3, the difference between the receive times of the first + packet received with window counter K+4 and the first packet received + with window counter K, is a reasonable round-trip time estimate. + Because of the necessary constraint that measurements only come from + packet pairs whose CCVals differ by at most 4, this procedure does + not work when the inter-packet sending times are significantly + greater than the RTT, resulting in packet pairs whose CCVals differ + by 5. Explicit RTT measurement techniques, such as Timestamp and + Timestamp Echo, should be used in that case. + +8.2. Elapsed Time Options + + The data receiver MUST include an elapsed time value on every + required acknowledgement. This helps the sender distinguish between + network round-trip time, which it must include in its rate equations, + and delay at the receiver due to TFRC's infrequent acknowledgement + rate, which it need not include. The receiver MUST at least include + an Elapsed Time option on every feedback packet, but if at least one + recent data packet (i.e., a packet received after the previous DCCP- + Ack was sent) included a Timestamp option, then the receiver SHOULD + include the corresponding Timestamp Echo option, with Elapsed Time + value, as well. All of these option types are defined in the main + DCCP specification [RFC4340]. + +8.3. Receive Rate Option + + +--------+--------+--------+--------+--------+--------+ + |11000010|00000110| Receive Rate | + +--------+--------+--------+--------+--------+--------+ + Type=194 Len=6 + + This option MUST be sent by the data receiver on all required + acknowledgements. Its four data bytes indicate the rate at which the + receiver has received data since it last sent an acknowledgement, in + bytes per second. To calculate this receive rate, the receiver sets + t to the larger of the estimated round-trip time and the time since + the last Receive Rate option was sent. (Received data packets' + window counters can be used to produce a suitable RTT estimate, as + described in Section 8.1.) The receive rate then equals the number + of data bytes received in the most recent t seconds, divided by t. + + Receive Rate options MUST NOT be sent on DCCP-Data packets, and any + Receive Rate options on received DCCP-Data packets MUST be ignored. + + + + + + + + +Floyd, et al. Standards Track [Page 17] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + +8.4. Send Loss Event Rate Feature + + The Send Loss Event Rate feature lets CCID 3 endpoints negotiate + whether the receiver MUST provide Loss Event Rate options on its + acknowledgements. DCCP A sends a "Change R(Send Loss Event Rate, 1)" + option to ask DCCP B to send Loss Event Rate options as part of its + acknowledgement traffic. + + Send Loss Event Rate has feature number 192 and is server-priority. + It takes one-byte Boolean values. DCCP B MUST send Loss Event Rate + options on its acknowledgements when Send Loss Event Rate/B is one, + although it MAY send Loss Event Rate options even when Send Loss + Event Rate/B is zero. Values of two or more are reserved. A CCID 3 + half-connection starts with Send Loss Event Rate equal to zero. + +8.5. Loss Event Rate Option + + +--------+--------+--------+--------+--------+--------+ + |11000000|00000110| Loss Event Rate | + +--------+--------+--------+--------+--------+--------+ + Type=192 Len=6 + + The option value indicates the inverse of the loss event rate, + rounded UP, as calculated by the receiver. Its units are data + packets per loss interval. Thus, if the Loss Event Rate option value + is 100, then the loss event rate is 0.01 loss events per data packet + (and the average loss interval contains 100 data packets). When each + loss event has exactly one data packet loss, the loss event rate is + the same as the data packet drop rate. + + See [RFC3448], Section 5, for a normative calculation of loss event + rate. Before any losses have occurred, when the loss event rate is + zero, the Loss Event Rate option value is set to + "11111111111111111111111111111111" in binary (or, equivalently, to + 2^32 - 1). The loss event rate calculation uses loss interval data + lengths, as defined in Section 6.1.1. + + Loss Event Rate options MUST NOT be sent on DCCP-Data packets, and + any Loss Event Rate options on received DCCP-Data packets MUST be + ignored. + +8.6. Loss Intervals Option + + +--------+--------+--------+--------...--------+--------+--- + |11000001| Length | Skip | Loss Interval | More Loss + | | | Length | | Intervals... + +--------+--------+--------+--------...--------+--------+--- + Type=193 9 bytes + + + +Floyd, et al. Standards Track [Page 18] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + Each 9-byte Loss Interval contains three fields, as follows: + + ____________________ Loss Interval _____________________ + / \ + +--------...-------+--------...--------+--------...--------+ + | Lossless Length |E| Loss Length | Data Length | + +--------...-------+--------...--------+--------...--------+ + 3 bytes 3 bytes 3 bytes + + The receiver reports its observed loss intervals using a Loss + Intervals option. Section 6.1 defines loss intervals. This option + MUST be sent by the data receiver on all required acknowledgements. + The option reports up to 28 loss intervals seen by the receiver, + although TFRC currently uses at most the latest 9 of these. This + lets the sender calculate a loss event rate and probabilistically + verify the receiver's ECN Nonce Echo. + + The Loss Intervals option serves several purposes. + + o The sender can use the Loss Intervals option to calculate the loss + event rate. + + o Loss Intervals information is easily checked for consistency + against previous Loss Intervals options, and against any Loss + Event Rate calculated by the receiver. + + o The sender can probabilistically verify the ECN Nonce Echo for + each Loss Interval, reducing the likelihood of misbehavior. + + Loss Intervals options MUST NOT be sent on DCCP-Data packets, and any + Loss Intervals options on received DCCP-Data packets MUST be ignored. + +8.6.1. Option Details + + The Loss Intervals option contains information about one to 28 + consecutive loss intervals, always including the most recent loss + interval. Intervals are listed in reverse chronological order. + Should more than 28 loss intervals need to be reported, then multiple + Loss Intervals options can be sent; the second option begins where + the first left off, and so forth. The options MUST contain + information about at least the most recent NINTERVAL + 1 = 9 loss + intervals unless (1) there have not yet been NINTERVAL + 1 loss + intervals, or (2) the receiver knows, because of the sender's + acknowledgements, that some previously transmitted loss interval + information has been received. In this second case, the receiver + need not send loss intervals that the sender already knows about, + except that it MUST transmit at least one loss interval regardless. + + + + +Floyd, et al. Standards Track [Page 19] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + The NINTERVAL parameter is equal to "n" as defined in [RFC3448], + Section 5.4. + + Loss interval sequence numbers are delta encoded starting from the + Acknowledgement Number. Therefore, Loss Intervals options MUST NOT + be sent on packets without an Acknowledgement Number, and any Loss + Intervals options received on such packets MUST be ignored. + + The first byte of option data is Skip Length, which indicates the + number of packets up to and including the Acknowledgement Number that + are not part of any Loss Interval. As discussed above, Skip Length + must be less than or equal to NDUPACK = 3. In a packet containing + multiple Loss Intervals options, the Skip Lengths of the second and + subsequent options MUST equal zero; such options with nonzero Skip + Lengths MUST be ignored. + + Loss Interval structures follow Skip Length. Each Loss Interval + consists of a Lossless Length, a Loss Length, an ECN Nonce Echo (E), + and a Data Length. + + Lossless Length, a 24-bit number, specifies the number of packets in + the loss interval's lossless part. Note again that this part may + contain lost or marked non-data packets. + + Loss Length, a 23-bit number, specifies the number of packets in the + loss interval's lossy part. The sum of the Lossless Length and the + Loss Length equals the loss interval's sequence length. Receivers + SHOULD report the minimum valid Loss Length for each loss interval, + making the first and last sequence numbers in each lossy part + correspond to lost or marked data packets. + + The ECN Nonce Echo, stored in the high-order bit of the 3-byte field + containing Loss Length, equals the one-bit sum (exclusive-or, or + parity) of data packet nonces received over the loss interval's + lossless part (which is Lossless Length packets long). If Lossless + Length is 0, the receiver is ECN Incapable, or the Lossless Length + contained no data packets, then the ECN Nonce Echo MUST be reported + as 0. Note that any ECN nonces on received non-data packets MUST NOT + contribute to the ECN Nonce Echo. + + Finally, Data Length, a 24-bit number, specifies the loss interval's + data length, as defined in Section 6.1.1. + +8.6.2. Example + + Consider the following sequence of packets, where "-" represents a + safely delivered packet and "*" represents a lost or marked packet. + + + + +Floyd, et al. Standards Track [Page 20] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + Sequence + Numbers: 0 10 20 30 40 44 + | | | | | | + ----------*--------***-*--------*----------*- + + Assuming that packet 43 was lost, not marked, this sequence might be + divided into loss intervals as follows: + + 0 10 20 30 40 44 + | | | | | | + ----------*--------***-*--------*----------*- + \________/\_______/\___________/\_________/ + L0 L1 L2 L3 + + A Loss Intervals option sent on a packet with Acknowledgement Number + 44 to acknowledge this set of loss intervals might contain the bytes + 193,39,2, 0,0,10, 128,0,1, 0,0,10, 0,0,8, 0,0,5, 0,0,10, 0,0,8, + 0,0,1, 0,0,8, 0,0,10, 128,0,0, 0,0,15. This option is interpreted as + follows. + + 193 The Loss Intervals option number. + + 39 The length of the option, including option type and length bytes. + This option contains information about (39 - 3)/9 = 4 loss + intervals. + + 2 The Skip Length is 2 packets. Thus, the most recent loss + interval, L3, ends immediately before sequence number 44 - 2 + 1 + = 43. + + 0,0,10, 128,0,1, 0,0,10 + These bytes define L3. L3 consists of a 10-packet lossless part + (0,0,10), preceded by a 1-packet lossy part. Continuing to + subtract, the lossless part begins with sequence number 43 - 10 = + 33, and the lossy part begins with sequence number 33 - 1 = 32. + The ECN Nonce Echo for the lossless part (namely, packets 33 + through 42, inclusive) equals 1. The interval's data length is + 10, so the receiver believes that the interval contained exactly + one non-data packet. + + 0,0,8, 0,0,5, 0,0,10 + This defines L2, whose lossless part begins with sequence number + 32 - 8 = 24; whose lossy part begins with sequence number 24 - 5 + = 19; whose ECN Nonce Echo (for packets [24,31]) equals 0; and + whose data length is 10. + + + + + + +Floyd, et al. Standards Track [Page 21] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + 0,0,8, 0,0,1, 0,0,8 + L1's lossless part begins with sequence number 11, its lossy part + begins with sequence number 10, its ECN Nonce Echo (for packets + [11,18]) equals 0, and its data length is 8. + + 0,0,10, 128,0,0, 0,0,15 + L0's lossless part begins with sequence number 0, it has no lossy + part, its ECN Nonce Echo (for packets [0,9]) equals 1, and its + data length is 15. (This must be the first loss interval in the + connection; otherwise, a data length greater than the sequence + length would be invalid.) + +9. Verifying Congestion Control Compliance with ECN + + The sender can use Loss Intervals options' ECN Nonce Echoes (and + possibly any Ack Vectors' ECN Nonce Echoes) to probabilistically + verify that the receiver is correctly reporting all dropped or marked + packets. Even if ECN is not used (the receiver's ECN Incapable + feature is set to one), the sender could still check on the receiver + by occasionally not sending a packet, or sending a packet out-of- + order, to catch the receiver in an error in Loss Intervals or Ack + Vector information. This is not as robust or non-intrusive as the + verification provided by the ECN Nonce, however. + +9.1. Verifying the ECN Nonce Echo + + To verify the ECN Nonce Echo included with a Loss Intervals option, + the sender maintains a table with the ECN nonce sum for each data + packet. As defined in [RFC3540], the nonce sum for sequence number S + is the one-bit sum (exclusive-or, or parity) of data packet nonces + over the sequence number range [I,S], where I is the initial sequence + number. Let NonceSum(S) represent this nonce sum for sequence number + S, and define NonceSum(I - 1) as 0. Note that NonceSum does not + account for the nonces of non-data packets such as DCCP-Ack. Then + the Nonce Echo for an interval of packets with sequence numbers X to + Y, inclusive, should equal the following one-bit sum: + + NonceSum(X - 1) + NonceSum(Y) + + Since an ECN Nonce Echo is returned for the lossless part of each + Loss Interval, a misbehaving receiver -- meaning a receiver that + reports a lost or marked data packet as "received non-marked", to + avoid rate reductions -- has only a 50% chance of guessing the + correct Nonce Echo for each loss interval. + + To verify the ECN Nonce Echo included with an Ack Vector option, the + sender maintains a table with the ECN nonce value sent for each + packet. The Ack Vector option explicitly says which packets were + + + +Floyd, et al. Standards Track [Page 22] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + received non-marked; the sender just adds up the nonces for those + packets using a one-bit sum and compares the result to the Nonce Echo + encoded in the Ack Vector's option type. Again, a misbehaving + receiver has only a 50% chance of guessing an Ack Vector's correct + Nonce Echo. Alternatively, an Ack Vector's ECN Nonce Echo may also + be calculated from a table of ECN nonce sums, rather than from ECN + nonces. If the Ack Vector contains many long runs of non-marked, + non-dropped packets, the nonce sum-based calculation will probably be + faster than a straightforward nonce-based calculation. + + Note that Ack Vector's ECN Nonce Echo is measured over both data + packets and non-data packets, while the Loss Intervals option reports + ECN Nonce Echoes for data packets only. Thus, different nonce sum + tables are required to verify the two options. + +9.2. Verifying the Reported Loss Intervals and Loss Event Rate + + Besides probabilistically verifying the ECN Nonce Echoes reported by + the receiver, the sender may also verify the loss intervals and any + loss event rate reported by the receiver, if it so desires. + Specifically, the Loss Intervals option explicitly reports the size + of each loss interval as seen by the receiver; the sender can verify + that the receiver is not falsely combining two loss events into one + reported Loss Interval by using saved window counter information. + The sender can also compare any Loss Event Rate option to the loss + event rate it calculates using the Loss Intervals option. + + Note that in some cases the loss event rate calculated by the sender + could differ from an explicit Loss Event Rate option sent by the + receiver. In particular, when a number of successive packets are + dropped, the receiver does not know the sending times for these + packets and interprets these losses as a single loss event. In + contrast, if the sender has saved the sending times or window counter + information for these packets, then the sender can determine if these + losses constitute a single loss event or several successive loss + events. Thus, with its knowledge of the sending times of dropped + packets, the sender is able to make a more accurate calculation of + the loss event rate. These kinds of differences SHOULD NOT be + misinterpreted as attempted receiver misbehavior. + +10. Implementation Issues + +10.1. Timestamp Usage + + CCID 3 data packets need not carry Timestamp options. The sender can + store the times at which recent packets were sent; the + Acknowledgement Number and Elapsed Time option contained on each + required acknowledgement then provide sufficient information to + + + +Floyd, et al. Standards Track [Page 23] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + compute the round trip time. Alternatively, the sender MAY include + Timestamp options on some of its data packets. The receiver will + respond with Timestamp Echo options including Elapsed Times, allowing + the sender to calculate round-trip times without storing sent + packets' timestamps at all. + +10.2. Determining Loss Events at the Receiver + + The window counter is used by the receiver to determine whether + multiple lost packets belong to the same loss event. The sender + increases the window counter by one every quarter round-trip time. + This section describes in detail the procedure for using the window + counter to determine when two lost packets belong to the same loss + event. + + [RFC3448], Section 3.2.1 specifies that each data packet contains a + timestamp and gives as an alternative implementation a "timestamp" + that is incremented every quarter of an RTT, as is the window counter + in CCID 3. However, [RFC3448], Section 5.2 on "Translation from Loss + History to Loss Events" is written in terms of timestamps, not in + terms of window counters. In this section, we give a procedure for + the translation from loss history to loss events that is explicitly + in terms of window counters. + + To determine whether two lost packets with sequence numbers X and Y + belong to different loss events, the receiver proceeds as follows. + Assume Y > X in circular sequence space. + + o Let X_prev be the greatest valid sequence number received with + X_prev < X. + + o Let Y_prev be the greatest valid sequence number received with + Y_prev < Y. + + o Given a sequence number N, let C(N) be the window counter value + associated with that packet. + + o Packets X and Y belong to different loss events if there exists a + packet with sequence number S so that X_prev < S <= Y_prev, and + the distance from C(X_prev) to C(S) is greater than 4. (The + distance is the number D so that C(X_prev) + D = C(S) (mod + WCTRMAX), where WCTRMAX is the maximum value for the window + counter -- in our case, 16.) + + That is, the receiver only considers losses X and Y as separate + loss events if there exists some packet S received between X and + Y, with the distance from C(X_prev) to C(S) greater than 4. This + complex calculation is necessary in order to handle the case where + + + +Floyd, et al. Standards Track [Page 24] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + window counter space wrapped completely between X and Y. When + that space does not wrap, the receiver can simply check whether + the distance from C(X_prev) to C(Y_prev) is greater than 4; if so, + then X and Y belong to separate loss events. + + Window counters can help the receiver disambiguate multiple losses + after a sudden decrease in the actual round-trip time. When the + sender receives an acknowledgement acknowledging a data packet with + window counter i, the sender increases its window counter, if + necessary, so that subsequent data packets are sent with window + counter values of at least i+4. This can help minimize errors where + the receiver incorrectly interprets multiple loss events as a single + loss event. + + We note that if all of the packets between X and Y are lost in the + network, then X_prev and Y_prev are equal, and the series of + consecutive losses is treated by the receiver as a single loss event. + However, the sender will receive no DCCP-Ack packets during a period + of consecutive losses, and the sender will reduce its sending rate + accordingly. + + As an alternative to the window counter, the sender could have sent + its estimate of the round-trip time to the receiver directly in a + round-trip time option; the receiver would use the sender's round- + trip time estimate to infer when multiple lost or marked packets + belong in the same loss event. In some respects, a round-trip time + option would give a more precise encoding of the sender's round-trip + time estimate than does the window counter. However, the window + counter conveys information about the relative *sending* times for + packets, while the receiver could only use the round-trip time option + to distinguish between the relative *receive* times (in the absence + of timestamps). That is, the window counter will give more robust + performance when there is a large variation in delay for packets sent + within a window of data. Slightly more speculatively, a round-trip + time option might possibly be used more easily by middleboxes + attempting to verify that a flow used conforming end-to-end + congestion control. + +10.3. Sending Feedback Packets + + [RFC3448], Sections 6.1 and 6.2 specify that the TFRC receiver must + send a feedback packet when a newly calculated loss event rate p is + greater than its previous value. CCID 3 follows this rule. + + In addition, [RFC3448], Section 6.2, specifies that the receiver use + a feedback timer to decide when to send additional feedback packets. + If the feedback timer expires and data packets have been received + since the previous feedback was sent, then the receiver sends a + + + +Floyd, et al. Standards Track [Page 25] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + feedback packet. When the feedback timer expires, the receiver + resets the timer to expire after R_m seconds, where R_m is the most + recent estimate of the round-trip time received from the sender. + CCID 3 receivers, however, generally use window counter values + instead of a feedback timer to determine when to send additional + feedback packets. This section describes how. + + Whenever the receiver sends a feedback message, the receiver sets a + local variable last_counter to the greatest received value of the + window counter since the last feedback message was sent, if any data + packets have been received since the last feedback message was sent. + If the receiver receives a data packet with a window counter value + greater than or equal to last_counter + 4, then the receiver sends a + new feedback packet. ("Greater" and "greatest" are measured in + circular window counter space.) + + This procedure ensures that when the sender is sending at a rate less + than one packet per round-trip time, the receiver sends a feedback + packet after each data packet. Similarly, this procedure ensures + that when the sender is sending several packets per round-trip time, + the receiver will send a feedback packet each time that a data packet + arrives with a window counter at least four greater than the window + counter when the last feedback packet was sent. Thus, the feedback + timer is not necessary when the window counter is used. + + However, the feedback timer still could be useful in some rare cases + to prevent the sender from unnecessarily halving its sending rate. + In particular, one could construct scenarios where the use of the + feedback timer at the receiver would prevent the unnecessary + expiration of the nofeedback timer at the sender. Consider the case + below, in which a feedback packet is sent when a data packet arrives + with a window counter of K. + + Window + Counters: K K+1 K+2 K+3 K+4 K+5 K+6 ... K+15 K+16 K+17 ... + | | | | | | | | | | + Data | | | | | | | | | | + Packets | | | | | | | | | | + Received: - - --- - ... - - -- - -- -- - + | | | | | | + | | | | | | + Events: 1: 2: 3: 4: 5: 6: + "A" "B" Timer "B" + sent sent received + + 1: Feedback message A is sent. + 2: A feedback message would have been sent if feedback + timers had been used. + + + +Floyd, et al. Standards Track [Page 26] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + 3: Feedback message B is sent. + 4: Sender's nofeedback timer expires. + 5: Feedback message B is received at the sender. + 6: Sender's nofeedback timer would have expired if feedback + timers had been used, and the feedback message at 2 had + been sent. + + The receiver receives data after the feedback packet has been sent + but has received no data packets with a window counter between K+4 + and K+14. A data packet with a window counter of K+4 or larger would + have triggered sending a new feedback packet, but no feedback packet + is sent until time 3. + + The TFRC protocol specifies that after a feedback packet is received, + the sender sets a nofeedback timer to at least four times the round- + trip time estimate. If the sender doesn't receive any feedback + packets before the nofeedback timer expires, then the sender halves + its sending rate. In the figure, the sender receives feedback + message A (time 1) and then sets the nofeedback timer to expire + roughly four round-trip times later (time 4). The sender starts + sending again just before the nofeedback timer expires but doesn't + receive the resulting feedback message until after its expiration, + resulting in an unnecessary halving of the sending rate. If the + connection had used feedback timers, the receiver would have sent a + feedback message when the feedback timer expired at time 2, and the + halving of the sending rate would have been avoided. + + For implementors who wish to implement a feedback timer for the data + receiver, we suggest estimating the round-trip time from the most + recent data packet, as described in Section 8.1. We note that this + procedure does not work when the inter-packet sending times are + greater than the RTT. + +11. Security Considerations + + Security considerations for DCCP have been discussed in [RFC4340], + and security considerations for TFRC have been discussed in + [RFC3448], Section 9. The security considerations for TFRC include + the need to protect against spoofed feedback and the need to protect + the congestion control mechanisms against incorrect information from + the receiver. + + In this document, we have extensively discussed the mechanisms the + sender can use to verify the information sent by the receiver. When + ECN is used, the receiver returns ECN Nonce information to the + sender. When ECN is not used, then, as Section 9 shows, the sender + could still use various techniques that might catch the receiver in + + + + +Floyd, et al. Standards Track [Page 27] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + an error in reporting congestion, but this is not as robust or non- + intrusive as the verification provided by the ECN Nonce. + +12. IANA Considerations + + This specification defines the value 3 in the DCCP CCID namespace + managed by IANA. This assignment is also mentioned in [RFC4340]. + + CCID 3 also introduces three sets of numbers whose values should be + allocated by IANA; namely, CCID 3-specific Reset Codes, option types, + and feature numbers. These ranges will prevent any future CCID 3- + specific allocations from polluting DCCP's corresponding global + namespaces; see [RFC4340], Section 10.3. However, we note that this + document makes no particular allocations from the Reset Code range, + except for experimental and testing use [RFC3692]. We refer to the + Standards Action policy outlined in [RFC2434]. + +12.1. Reset Codes + + Each entry in the DCCP CCID 3 Reset Code registry contains a CCID 3- + specific Reset Code, which is a number in the range 128-255; a short + description of the Reset Code; and a reference to the RFC defining + the Reset Code. Reset Codes 184-190 and 248-254 are permanently + reserved for experimental and testing use. The remaining Reset Codes + -- 128-183, 191-247, and 255 -- are currently reserved and should be + allocated with the Standards Action policy, which requires IESG + review and approval and standards-track IETF RFC publication. + +12.2. Option Types + + Each entry in the DCCP CCID 3 option type registry contains a CCID + 3-specific option type, which is a number in the range 128-255; the + name of the option, such as "Loss Intervals"; and a reference to the + RFC defining the option type. The registry is initially populated + using the values in Table 1, in Section 8. This document allocates + option types 192-194, and option types 184-190 and 248-254 are + permanently reserved for experimental and testing use. The remaining + option types -- 128-183, 191, 195-247, and 255 -- are currently + reserved and should be allocated with the Standards Action policy, + which requires IESG review and approval and standards-track IETF RFC + publication. + +12.3. Feature Numbers + + Each entry in the DCCP CCID 3 feature number registry contains a CCID + 3-specific feature number, which is a number in the range 128-255; + the name of the feature, such as "Send Loss Event Rate"; and a + reference to the RFC defining the feature number. The registry is + + + +Floyd, et al. Standards Track [Page 28] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + initially populated using the values in Table 2, in Section 8. This + document allocates feature number 192, and feature numbers 184-190 + and 248-254 are permanently reserved for experimental and testing + use. The remaining feature numbers -- 128-183, 191, 193-247, and 255 + -- are currently reserved and should be allocated with the Standards + Action policy, which requires IESG review and approval and + standards-track IETF RFC publication. + +13. Thanks + + We thank Mark Handley for his help in defining CCID 3. We also thank + Mark Allman, Aaron Falk, Ladan Gharai, Sara Karlberg, Greg Minshall, + Arun Venkataramani, David Vos, Yufei Wang, Magnus Westerlund, and + members of the DCCP Working Group for feedback on versions of this + document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Floyd, et al. Standards Track [Page 29] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + +A. Appendix: Possible Future Changes to CCID 3 + + There are a number of cases where the behavior of TFRC as specified + in [RFC3448] does not match the desires of possible users of DCCP. + These include the following: + + 1. The initial sending rate of at most four packets per RTT, as + specified in [RFC3390]. + + 2. The receiver's sending of an acknowledgement for every data packet + received, when the receiver receives at a rate less than one + packet per round-trip time. + + 3. The sender's limitation of at most doubling the sending rate from + one round-trip time to the next (or, more specifically, of + limiting the sending rate to at most twice the reported receive + rate over the previous round-trip time). + + 4. The limitation of halving the allowed sending rate after an idle + period of four round-trip times (possibly down to the initial + sending rate of two to four packets per round-trip time). + + 5. The response function used in [RFC3448], Section 3.1, which does + not closely match the behavior of TCP in environments with high + packet drop rates [RFC3714]. + + One suggestion for higher initial sending rates is an initial sending + rate of up to eight small packets per RTT, when the total packet + size, including headers, is at most 4380 bytes. Because the packets + would be rate-paced out over a round-trip time, instead of sent + back-to-back as they would be in TCP, an initial sending rate of + eight small packets per RTT with TFRC-based congestion control would + be considerably milder than the impact of an initial window of eight + small packets sent back-to-back in TCP. As Section 5.1 describes, + the initial sending rate also serves as a lower bound for reductions + of the allowed sending rate during an idle period. + + We note that with CCID 3, the sender is in slow-start in the + beginning and responds promptly to the report of a packet loss or + mark. However, in the absence of feedback from the receiver, the + sender can maintain its old sending rate for up to four round-trip + times. One possibility would be that for an initial window of eight + small packets, the initial nofeedback timer would be set to two + round-trip times instead of four, so that the sending rate would be + reduced after two round-trips without feedback. + + + + + + +Floyd, et al. Standards Track [Page 30] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + Research and engineering will be needed to investigate the pros and + cons of modifying these limitations in order to allow larger initial + sending rates, to send fewer acknowledgements when the data sending + rate is low, to allow more abrupt changes in the sending rate, or to + allow a higher sending rate after an idle period. + +Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, RFC + 2434, October 1998. + + [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP + Congestion Control", RFC 2581, April 1999. + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The + Addition of Explicit Congestion Notification (ECN) to + IP", RFC 3168, September 2001. + + [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing + TCP's Initial Window", RFC 3390, October 2002. + + [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, + "TCP Friendly Rate Control (TFRC): Protocol + Specification", RFC 3448, January 2003. + + [RFC3692] Narten, T., "Assigning Experimental and Testing + Numbers Considered Useful", BCP 82, RFC 3692, January + 2004. + + [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram + Congestion Control Protocol (DCCP)", RFC 4340, March + 2006. + +Informative References + + [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust + Explicit Congestion Notification (ECN) Signaling with + Nonces", RFC 3540, June 2003. + + + + + + + + + +Floyd, et al. Standards Track [Page 31] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + + [RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding + Congestion Control for Voice Traffic in the Internet", + RFC 3714, March 2004. + + [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram + Congestion Control Protocol (DCCP) Congestion Control + ID 2: TCP-like Congestion Control", RFC 4341, March + 2006. + + [V03] Arun Venkataramani, August 2003. Citation for + acknowledgement purposes only. + +Authors' Addresses + + Sally Floyd + ICSI Center for Internet Research + 1947 Center Street, Suite 600 + Berkeley, CA 94704 + USA + + EMail: floyd@icir.org + + + Eddie Kohler + 4531C Boelter Hall + UCLA Computer Science Department + Los Angeles, CA 90095 + USA + + EMail: kohler@cs.ucla.edu + + + Jitendra Padhye + Microsoft Research + One Microsoft Way + Redmond, WA 98052 + USA + + EMail: padhye@microsoft.com + + + + + + + + + + + + +Floyd, et al. Standards Track [Page 32] + +RFC 4342 DCCP CCID3 TFRC March 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Floyd, et al. Standards Track [Page 33] + |