Internet Engineering Task Force                              Sally Floyd   

INTERNET-DRAFT                                                      ICIR   

               Profile for DCCP Congestion Control ID 2:                   

                      TCP-like Congestion Control                          

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.                                                              

    Internet-Drafts are working documents of the Internet Engineering      

    Task Force (IETF), its areas, and its working groups.  Note that       

    other groups may also distribute working documents as Internet-        

    Drafts.                                                                

    Internet-Drafts are draft documents valid for a maximum of six         

    months and may be updated, replaced, or obsoleted by other documents   

    at any time.  It is inappropriate to use Internet-Drafts as            

    reference material or to cite them other than as "work in progress."   

    The list of current Internet-Drafts can be accessed at                 

    http://www.ietf.org/ietf/1id-abstracts.txt.                            

    The list of Internet-Draft Shadow Directories can be accessed at       

    http://www.ietf.org/shadow.html.                                       

Copyright Notice                                                           

    Copyright (C) The Internet Society (2004). All Rights Reserved.        

Floyd/Kohler                                                    [Page 1]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

Abstract                                                                   

    This document contains the profile for Congestion Control Identifier   

    2, TCP-like Congestion Control, in the Datagram Congestion Control     

    Protocol (DCCP).  CCID 2 should be used by senders who would like to   

    take advantage of the available bandwidth in an environment with       

    rapidly changing conditions, and who are able to adapt to the abrupt   

    changes in the congestion window typical of TCP's Additive Increase    

    Multiplicative Decrease (AIMD) congestion control.                     

Floyd/Kohler                                                    [Page 2]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

    TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:                      

    Changes from draft-ietf-dccp-ccid2-07.txt:                             

    * Restrict the use of byte-counting to be at most as aggressive        

      as the current TCP (without byte-counting).                          

    Changes from draft-ietf-dccp-ccid2-06.txt:                             

    * Moved three citations to Informational.                              

    * Added that "The sender SHOULD not attempt Ack Ratio                  

      renegotiations more than once per round-trip time."                  

    * Specified that ssthresh is never less than two, instead of one.      

    * Added references to RFC 2988 and RFC 2018.                           

    * Specify that the congestion window is only increased for packets     

    that aren't ECN-marked.                                                

    Changes from draft-ietf-dccp-ccid2-05.txt:                             

    * Changes to the discussion about how the sender infers that DCCP-     

    Ack packets are lost.  The sender does not know for sure whether a     

    missing sequence number is for a dropped ACK packet or a dropped       

    data packet.  Our changes include a new appendix on "The Costs of      

    Inferring Lost Ack Packets".                                           

    * Minor editing for clarity, including some reordering of sections.    

    * Added a section on response to idle and application-limited          

    periods.                                                               

    * Clarifications on changing the Ack Ratio, based on feedback from     

    Nils-Erik Mattsson.                                                    

    Changes from draft-ietf-dccp-ccid2-04.txt:                             

    * Minor editing, as follows:                                           

      - Added a note that CCID2 implementations MAY check for apps that    

    are                                                                    

        gaming with regard to the packet size.                             

      - Deleted a statement that the maximum packet size is 1500 bytes.    

      - Added that the receiver MAY know the round-trip time from its      

    role as                                                                

      - Added a note that the initial cwnd is up to four packets.          

Floyd/Kohler                                                    [Page 3]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

    * Added Intellectual Property Notice.                                  

    Changes from draft-ietf-dccp-ccid2-03.txt:                             

    * Disallow direct tracking of TCP standards.                           

    Changes from draft-ietf-dccp-ccid2-02.txt:                             

    * Added to the section on application requirements.                    

    * Changed the default Ack Ratio to be two, as recommended for TCP.     

    * Added a paragraph about packet sizes.                                

    Changes from draft-ietf-dccp-ccid2-01.txt:                             

    * Added "Security Considerations" and "IANA Considerations"            

    sections.                                                              

    * Refer explicitly to SACK-based TCP, and flesh out Section 3          

    ("Congestion Control on Data Packets").                                

    * When cwnd < ssthresh, increase cwnd by one per newly acknowledged    

    packet up to some limit, in line with TCP Appropriate Byte Counting.   

    * Refined definition of quiescence.                                    

    Changes from draft-ietf-dccp-ccid2-00.txt:                             

    * Said that the Acknowledgement Number reports the largest sequence    

    number, not the most recent packet, for consistency with draft-ietf-   

    dccp-spec.                                                             

    * Added notes about ECN nonces for acknowledgements, and about         

    dealing with piggybacked acknowledgements.                             

Floyd/Kohler                                                    [Page 4]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

                             Table of Contents                             

    1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   6   

    2. Conventions and Notation. . . . . . . . . . . . . . . . . . .   6   

    3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . .   6   

       3.1. Relationship with TCP. . . . . . . . . . . . . . . . . .   7   

       3.2. Example Half-Connection. . . . . . . . . . . . . . . . .   7   

    4. Connection Establishment. . . . . . . . . . . . . . . . . . .   9   

    5. Congestion Control on Data Packets. . . . . . . . . . . . . .   9   

       5.1. Response to Idle and Application-limited                       

       Periods . . . . . . . . . . . . . . . . . . . . . . . . . . .  11   

       5.2. Response to Data Dropped and Slow Receiver . . . . . . .  12   

       5.3. Packet Size. . . . . . . . . . . . . . . . . . . . . . .  12   

       6.1. Congestion Control on Acknowledgements . . . . . . . . .  13   

          6.1.1. Detecting Lost and Marked                                 

          Acknowledgements . . . . . . . . . . . . . . . . . . . . .  13   

          6.1.2. Changing Ack Ratio. . . . . . . . . . . . . . . . .  14   

       6.2. Acknowledgements of Acknowledgements . . . . . . . . . .  15   

          6.2.1. Determining Quiescence. . . . . . . . . . . . . . .  15   

    8. Options and Features. . . . . . . . . . . . . . . . . . . . .  16   

    9. Security Considerations . . . . . . . . . . . . . . . . . . .  16   

    10. IANA Considerations. . . . . . . . . . . . . . . . . . . . .  16   

       10.2. Option Types. . . . . . . . . . . . . . . . . . . . . .  17   

       10.3. Feature Numbers . . . . . . . . . . . . . . . . . . . .  17   

    11. Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . .  17   

    B. Appendix: Cost of Loss Inference Mistakes to Ack                    

    Ratio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  18   

    Normative References . . . . . . . . . . . . . . . . . . . . . .  20   

    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  21   

    Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  21   

Floyd/Kohler                                                    [Page 5]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

1.  Introduction                                                           

    This document contains the profile for Congestion Control Identifier   

    2, TCP-like Congestion Control, in the Datagram Congestion Control     

    Protocol (DCCP) [DCCP].  DCCP uses Congestion Control Identifiers,     

    or CCIDs, to specify the congestion control mechanism in use on a      

    half-connection.                                                       

    The TCP-like Congestion Control CCID sends data using a close          

    variant of TCP's congestion control mechanisms, incorporating          

    suitable for senders who can adapt to the abrupt changes in            

    congestion window typical of TCP's Additive Increase Multiplicative    

    Decrease (AIMD) congestion control, and particularly useful for        

    senders who would like to take advantage of the available bandwidth    

    in an environment with rapidly changing conditions.  See Section 3     

    for more on application requirements.                                  

2.  Conventions and Notation                                               

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",    

    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 [DCCP] 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.                                       

3.  Usage                                                                  

    CCID 2, TCP-like Congestion Control, is appropriate for DCCP flows     

    that would like to receive as much bandwidth as possible over the      

    long term, consistent with the use of end-to-end congestion control,   

    and that can tolerate the large sending rate variations                

    characteristic of AIMD congestion control, including halving of the    

    congestion window in response to a congestion event.                   

Floyd/Kohler                                        Section 3.  [Page 6]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

    Applications that simply need to transfer as much data as possible     

    in as short a time as possible should use CCID 2.  This contrasts      

    with CCID 3, TCP-Friendly Rate Control (TFRC) Congestion Control       

    [CCID 3 PROFILE], which is appropriate for flows that would prefer     

    to minimize abrupt changes in the sending rate.  For example, CCID 2   

    is recommended over CCID 3 for streaming media applications that       

    buffer a considerable amount of data at the application receiver       

    before playback time, insulating the application somewhat from         

    abrupt changes in the sending rate.  Such applications could easily    

    choose DCCP's CCID 2 over TCP itself, possibly adding some form of     

    selective reliability at the application layer.  CCID 2 is also        

    recommended over CCID 3 for applications where halving the sending     

    rate in response to congestion is not likely to interfere with         

    application-level performance.                                         

    An additional advantage of CCID 2 is that its TCP-like congestion      

    control mechanisms are reasonably well-understood, with traffic        

    dynamics quite similar to those of TCP.  While the network research    

    community is still learning about the dynamics of TCP after 15 years   

    of its being the dominant transport protocol in the Internet, some     

    applications might prefer the more well-known dynamics of TCP-like     

    congestion control over that of newer congestion control mechanisms,   

    which haven't yet met the test of widespread Internet deployment.      

3.1.  Relationship with TCP                                                

    The congestion control mechanisms described here closely follow        

    mechanisms standardized by the IETF for use in SACK-based TCP, and     

    retransmits a packet, so congestion control mechanisms that            

    distinguish retransmissions from new packets have been redesigned      

    for the DCCP context.                                                  

3.2.  Example Half-Connection                                              

    This example shows the typical progress of a half-connection using     

    CCID 2's TCP-like Congestion Control, not including connection         

    initiation and termination.  The example is informative, not           

    normative.                                                             

Floyd/Kohler                                      Section 3.2.  [Page 7]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

    1.  The sender sends DCCP-Data packets, where the number of packets    

        sent is governed by a congestion window, cwnd, as in TCP.  Each    

        DCCP-Data packet uses a sequence number.  The sender also sends    

        an Ack Ratio feature option specifying the number of data          

        packets to be covered by an Ack packet from the receiver; Ack      

        Ratio defaults to two.  The DCCP header's CCVal field is set to    

        zero.                                                              

        Assuming that the half-connection is Explicit Congestion           

        Notification (ECN) capable (the ECN Incapable feature is zero --   

        the default), each DCCP-Data packet is sent as ECN-Capable with    

        either the ECT(0) or the ECT(1) codepoint set, as described in     

    2.  The receiver sends a DCCP-Ack packet acknowledging the data        

        packets for every Ack Ratio data packets transmitted by the        

        sender.  Each DCCP-Ack packet uses a sequence number and           

        contains an Ack Vector.  The sequence number acknowledged in a     

        DCCP-Ack packet is that of the received packet with the highest    

        sequence number, rather than a TCP-like cumulative                 

        acknowledgement.                                                   

        The receiver returns the sum of received ECN Nonces via Ack        

        Vector options, allowing the sender to probabilistically verify    

        that the receiver is not misbehaving.  DCCP-Ack packets from the   

        receiver are also sent as ECN-Capable, since the sender will       

        control the acknowledgement rate in a roughly TCP-friendly way     

        using the Ack Ratio feature.  There is little need for the         

        receiver to verify the nonces of its DCCP-Ack packets, since the   

        sender cannot get significant benefit from misreporting the ack    

        mark rate.                                                         

    3.  The sender continues sending DCCP-Data packets as controlled by    

        the congestion window.  Upon receiving DCCP-Ack packets, the       

        sender examines their Ack Vectors to learn about marked or         

        dropped data packets, and adjusts its congestion window            

        accordingly.  Because this is unreliable transfer, the sender      

        does not retransmit dropped packets.                               

    4.  Because DCCP-Ack packets use sequence numbers, the sender has      

        some information about lost or marked DCCP-Ack packets.  The       

        sender responds to lost or marked DCCP-Ack packets by modifying    

        the Ack Ratio sent to the receiver.                                

    5.  The sender acknowledges the receiver's acknowledgements at least   

        once per congestion window.  If both half-connections are          

        active, the sender's acknowledgement of the receiver's             

        acknowledgements is included in the sender's acknowledgement of    

Floyd/Kohler                                      Section 3.2.  [Page 8]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

        the receiver's data packets.  If the reverse-path half-            

        connection is quiescent, the sender sends a DCCP-DataAck packet    

        that includes an Acknowledgement Number in the header.             

    6.  The sender estimates round-trip times, either through keeping      

        track of acknowledgement round-trip times as TCP does or through   

        explicit Timestamp options, and calculates a TimeOut (TO) value    

        much as the RTO (Retransmit Timeout) is calculated in TCP.  The    

        TO is used to determine when a new DCCP-Data packet can be         

        transmitted when the sender has been limited by the congestion     

        window and no feedback has been received from the receiver.        

4.  Connection Establishment                                               

    Use of the Ack Vector is MANDATORY on CCID 2 half-connections, so      

    the sender MUST send a "Change R(Send Ack Vector, 1)" option to the    

    receiver as part of connection establishment.  The sender SHOULD NOT   

    send data until it has received the corresponding "Confirm L(Send      

    Ack Vector, 1)" from the receiver, except possibly for data included   

    on the initial DCCP-Request packet.                                    

5.  Congestion Control on Data Packets                                     

    CCID 2's congestion control mechanisms are based on those for SACK-    

    based TCP [RFC 3517], since the Ack Vector provides all the            

    information that might be transmitted in SACK options.                 

    A CCID 2 data sender maintains three integer parameters measured in    

    packets.                                                               

    1.  The congestion window "cwnd", which equals the maximum number of   

        data packets allowed in the network at any time.  ("Data packet"   

        means any DCCP packet that contains user data: DCCP-Data, DCCP-    

        DataAck, and occasionally DCCP-Request and DCCP-Response.)         

    2.  The slow-start threshold "ssthresh", which controls adjustments    

        to cwnd.                                                           

    3.  The pipe value "pipe", which is the sender's estimate of the       

        number of data packets outstanding in the network.                 

    These parameters are manipulated, and their initial values             

    determined, according to SACK-based TCP's behavior, except that they   

    are measured in packets, not bytes.  The rest of this section          

    provides more specific guidance.                                       

    The sender MAY send a data packet when pipe < cwnd, but MUST NOT       

    send a data packet when pipe >= cwnd.  Every data packet sent          

Floyd/Kohler                                        Section 5.  [Page 9]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

    increases pipe by 1.                                                   

    The sender reduces pipe as it infers that data packets have left the   

    network, either by being received or by being dropped.  In             

    particular:                                                            

    1.  Acked data packets.  The sender reduces pipe by 1 for each data    

        packet newly-acknowledged as received (Ack Vector State 0 or       

        State 1) by some DCCP-Ack.                                         

    2.  Dropped data packets.  The sender reduces pipe by 1 for each       

        data packet it can infer as lost due to the DCCP equivalent of     

        TCP's "duplicate acknowledgements".  This depends on the           

        NUMDUPACK parameter, the number of duplicate acknowledgements      

        needed to infer a loss.  The NUMDUPACK parameter is set to         

        three, as is currently the case in TCP.  A packet P is inferred    

        to be lost, rather than delayed, when at least NUMDUPACK packets   

        transmitted after P have been acknowledged as received (Ack        

        Vector State 0 or 1) by the receiver.  Note that the               

        acknowledged packets following the hole may be DCCP-Acks or        

        other non-data packets.                                            

    3.  Transmit timeouts.  Finally, the sender needs transmit timeouts,   

        handled like TCP's retransmission timeouts, in case an entire      

        window of packets is lost.  The sender estimates the round-trip    

        time at most once per window of data, and uses the TCP             

        algorithms for maintaining the average round-trip time, mean       

        deviation, and timeout value [RFC 2988].  (If more than one        

        measurement per round-trip time was used for these calculations,   

        then the weights of the averagers would have to be adjusted, so    

        that the average round-trip time is effectively derived from       

        measurements over multiple round-trip times.)  Because DCCP does   

        not retransmit data, DCCP does not require TCP's recommended       

        minimum timeout of one second.  The exponential backoff of the     

        timer is exactly as in TCP.  When a transmit timeout occurs, the   

        sender sets pipe to zero.  The adjustments to cwnd and ssthresh    

        are described below.                                               

    The sender MUST NOT decrement pipe more than once per data packet.     

    True duplicate acknowledgements, for example, MUST NOT affect pipe.    

    Furthermore, the sender MUST NOT decrement pipe for non-data           

    packets, such as DCCP-Acks, even though the Ack Vector will contain    

    information about them.                                                

Floyd/Kohler                                       Section 5.  [Page 10]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

    When cwnd < ssthresh, meaning that the sender is in slow-start, the    

    congestion window is increased by one packet for every two newly       

    acknowledged data packets with Ack Vector State 0 (not ECN-marked),    

    up to a maximum of Ack Ratio/2 packets per acknowledgement.  This is   

    a modified form of Appropriate Byte Counting [RFC 3465] that is        

    consistent with TCP's current standard (which does not include byte-   

    counting), but allows CCID 2 to increase as aggressively as TCP when   

    CCID-2's Ack Ratio is greater than the default value of two.  When     

    cwnd >= ssthresh, the congestion window is increased by one packet     

    for every window of data acknowledged without lost or marked           

    packets.  The cwnd parameter is initialized to at most four packets    

    for new connections, following the rules from RFC 3390; the ssthresh   

    parameter is initialized to an arbitrarily high value.                 

    Senders MAY use a form of rate-based pacing when sending multiple      

    data packets liberated by a single ack packet, rather than sending     

    all liberated data packets in a single burst.                          

5.1.  Response to Idle and Application-limited Periods                     

    CCID 2 is designed to follow TCP's congestion control mechanisms to    

    the extent possible, but TCP does not have complete standardization    

    for its congestion control response to idle periods (when no data      

    packets are sent) or to application-limited periods (when the          

    sending rate is less than that allowed by cwnd).  This section is a    

    brief guide to the standards for TCP in this area.                     

    For idle periods, RFC 2581 recommends that the TCP sender SHOULD       

    slow-start after an idle period, where an idle period is defined as    

    a period exceeding the timeout interval.  RFC 2861, currently          

    Experimental, suggests a slightly more moderate mechanism where the    

    congestion window is halved for every round-trip time that the         

    sender has remained idle.                                              

Floyd/Kohler                                     Section 5.1.  [Page 11]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

    There are currently no standards governing TCP's use of the            

    congestion window during an application-limited period.  In            

    particular, it is possible for TCP's congestion window to grow quite   

    large during a long uncongested period when the sender is              

    application-limited, sending at a low rate.  RFC 2861 essentially      

    suggests that TCP's congestion window not be increased during          

    application-limited periods, when the congestion window is not being   

    fully utilized.                                                        

5.2.  Response to Data Dropped and Slow Receiver                           

    As described in [DCCP], the Data Dropped option lets an endpoint       

    declare that a packet was dropped at the end host before delivery to   

    the application -- for instance, because of corruption or receive      

    buffer overflow.  CCID 2 senders respond to these options as           

    described in [DCCP], with the following further clarifications.        

    o  Drop Code 2 ("receive buffer drop").  The congestion window         

       "cwnd" is reduced by one for each packet newly acknowledged as      

       Drop Code 2, except that it is never reduced below one.             

    o  Exiting slow-start.  The sender MUST exit slow start whenever it    

       receives a relevant Data Dropped or Slow Receiver option.           

5.3.  Packet Size                                                          

    CCID 2 is optimized for applications that generally use a fixed        

    packet size, and that vary their sending rate in packets per second    

    in response to congestion.  CCID 2 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.  CCID 2 maintains a congestion window in packets, and   

    does not increase the congestion window in response to a decrease in   

    the packet size.  However, some attention might be required for        

    applications using CCID 2 that vary their packet size not in           

    response to congestion, but in response to other application-level     

    requirements.                                                          

    CCID 2 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 this manipulation will occur in practice [V03].)             

Floyd/Kohler                                     Section 5.3.  [Page 12]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

6.  Acknowledgements                                                       

    CCID 2 acknowledgements are generally paced by the sender's data       

    packets.  Each required acknowledgement MUST contain Ack Vector        

    options that declare exactly which packets arrived, and whether        

    those packets were ECN-marked.  Acknowledgement data in the Ack        

    Vector options SHOULD generally cover the receiver's entire            

    CCID 2 senders use DCCP's Ack Ratio feature to influence the rate at   

    which DCCP-Ack packets are generated, thus controlling reverse-path    

    congestion.  This differs from TCP, which presently has no             

    congestion control for pure acknowledgement traffic.  CCID 2's         

    reverse-path congestion control does not try to be TCP-friendly; it    

    just tries to avoid congestion collapse, and to be somewhat better     

    than TCP in the presence of a high packet loss or mark rate on the     

    reverse path.  The default Ack Ratio is two, and CCID 2 with this      

6.1.  Congestion Control on Acknowledgements                               

    When Ack Ratio is R, the receiver sends one DCCP-Ack packet per R      

    data packets, more or less.  Since the sender sends cwnd data          

    packets per round-trip time, the acknowledgement rate equals cwnd/R    

    DCCP-Acks per round-trip time.  The sender keeps the acknowledgement   

    rate roughly TCP-friendly by monitoring the acknowledgement stream     

    for lost and marked DCCP-Ack packets, and modifying R accordingly.     

    For every RTT containing a DCCP-Ack congestion event (that is, a       

    lost or marked DCCP-Ack), the sender halves the acknowledgement rate   

    by doubling Ack Ratio; for every RTT containing no DCCP-Ack            

    congestion event, it additively increases the acknowledgement rate     

    through gradual decreases in Ack Ratio.                                

6.1.1.  Detecting Lost and Marked Acknowledgements                         

    All packets from the receiver contain sequence numbers, so the         

    sender can detect both losses and marks on the receiver's packets.     

    The sender infers receiver packet loss in the same way as it infers    

    losses of its data packets: a packet from the receiver is considered   

    lost after at least NUMDUPACK packets with greater sequence numbers    

    have been received.                                                    

Floyd/Kohler                                   Section 6.1.1.  [Page 13]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

    DCCP-Ack packets are generally small, so they might impose less load   

    on congested network links than DCCP-Data and DCCP-DataAck packets.    

    For this reason, Ack Ratio depends on losses and marks on the          

    receiver's non-data packets, not on aggregate losses and marks on      

    all of the receiver's packets.  The non-data packet category           

    consists of those packet types that cannot carry application data:     

    DCCP-Ack, DCCP-Close, DCCP-CloseReq, DCCP-Reset, DCCP-Sync, and        

    DCCP-SyncAck.  The sender can easily distinguish non-data marks from   

    other marks.  This is harder for losses, though, since the sender      

    can't always know whether a lost packet carried data.  Unless it has   

    better information, the sender SHOULD assume, for the purpose of Ack   

    Ratio calculation, that every lost packet was a non-data packet.       

    Better information is available via DCCP's NDP Count option, if        

    necessary.  (Appendix B discusses the costs of mistaking data packet   

    loss for non-data packet loss.)                                        

    A receiver that implements its own acknowledgement congestion          

    control SHOULD NOT reduce its DCCP-Ack acknowledgement rate due to     

    losses or marks on its data packets.                                   

6.1.2.  Changing Ack Ratio                                                 

    Ack Ratio always meets three constraints: (1) Ack Ratio is an          

    integer.  (2) Ack Ratio does not exceed cwnd/2, rounded up, except     

    that Ack Ratio 2 is always acceptable.  (3) Ack Ratio is two or more   

    for a congestion window of four or more packets.                       

    The sender changes Ack Ratio within those constraints as follows.      

    For each congestion window of data with lost or marked DCCP-Ack        

    packets, Ack Ratio is doubled; and for each cwnd/(R^2 - R)             

    consecutive congestion windows of data with no lost or marked DCCP-    

    Ack packets, Ack Ratio is decreased by 1.  (See Appendix A for the     

    derivation.)  Changes in Ack Ratio are signalled through feature       

    For a constant congestion window, this gives an Ack sending rate       

    that is roughly TCP-friendly.  Of course, cwnd usually varies over     

    time; the dynamics will be rather complex, but roughly TCP-friendly.   

    We recommend that the sender use the most recent value of cwnd when    

    determining whether to decrease Ack Ratio by 1.                        

    The sender need not keep Ack Ratio completely up to date.  For         

    instance, it MAY rate-limit Ack Ratio renegotiations to once every     

    four or five round-trip times, or to once every second or two.  The    

    sender SHOULD NOT attempt to renegotiate the Ack Ratio more than       

    once per round-trip time.  Additionally, it MAY bound Ack Ratio        

    below by two, or it MAY set Ack Ratio to one for half-connections      

    with persistent congestion windows of 1 or 2 packets.                  

Floyd/Kohler                                   Section 6.1.2.  [Page 14]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

    Putting it all together, the receiver always sends at least one        

    acknowledgement per window of data when cwnd = 1, and at least two     

    acknowledgements per window of data otherwise.  Thus, the receiver     

    could be sending two ack packets per window of data even in the face   

    of very heavy congestion on the reverse path.  We would note,          

    however, that if congestion is sufficiently heavy that all of the      

    ack packets are dropped, then the sender falls back on an              

    exponentially-backed-off timeout, as in TCP.  Thus, if congestion is   

    sufficiently heavy on the reverse path, then the sender reduces its    

    sending rate on the forward path, which reduces the rate on the        

    reverse path as well.                                                  

6.2.  Acknowledgements of Acknowledgements                                 

    An active sender DCCP A MUST occasionally acknowledge its peer DCCP    

    B's acknowledgements, so that DCCP B can free up Ack Vector state.     

    When both half-connections are active, A's acknowledgements of B's     

    acknowledgements are automatically contained in A's acknowledgements   

    of B's data. If the B-to-A half-connection is quiescent, however,      

    DCCP A must occasionally send acknowledgements proactively, such as    

    by sending a DCCP-DataAck packet that includes an Acknowledgement      

    Number in the header.                                                  

    An active sender SHOULD acknowledge the receiver's acknowledgements    

    at least once per congestion window. Of course, the sender's           

    application might fall silent.  This is no problem; when neither       

    side is sending data, a sender can wait arbitrarily long before        

    sending an ack.                                                        

6.2.1.  Determining Quiescence                                             

    Let T equal the greater of 0.2 seconds and two round-trip times.       

    (The receiver may know the round-trip time in its role as the sender   

    for the other half-connection.  If it does not, it should use a        

    Once the sender acknowledges the receiver's Ack Vectors, and the       

    sender has not sent additional data for at least T seconds, the        

    receiver can infer that the sender is quiescent.  More precisely,      

    the receiver infers that th