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
negotiation; see [RFC4340], Section 11.3.
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 enforce a minimum Ack
Ratio of two, or it MAY set Ack Ratio to one for half-connections
with persistent congestion windows of 1 or 2 packets.
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, all the ack
packets are dropped, and 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
This section describes how a CCID 2 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.
(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
default RTT of 0.2 seconds, as described in [RFC4340], Section 3.4.)
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 the sender has gone quiescent when at least T
seconds have passed without receiving any data from the sender, and
when the sender has acknowledged receiver Ack Vectors covering all
data packets received at the receiver.
7. Explicit Congestion Notification
CCID 2 supports Explicit Congestion Notification (ECN) [RFC3168].
The sender will use the ECN Nonce for data packets, and the receiver
will echo those nonces in its Ack Vectors, as specified in [RFC4340],
Section 12.2. Information about marked packets is also returned in
the Ack Vector. Because the information in the Ack Vector is
reliably transferred, DCCP does not need the TCP flags of ECN-Echo
and Congestion Window Reduced.
For unmarked data packets, the receiver computes the ECN Nonce Echo
as in [RFC3540] and returns it as part of its Ack Vector options.
The sender SHOULD check these ECN Nonce Echoes against the expected
values, thus protecting against the accidental or malicious
concealment of marked packets.
Because CCID 2 acknowledgements are congestion controlled, ECN may
also be used for its acknowledgements. In this case we do not make
use of the ECN Nonce, because it would not be easy to provide
protection against the concealment of marked ack packets by the
sender, and because the sender does not have much motivation for
lying about the mark rate on acknowledgements.
8. Options and Features
DCCP’s Ack Vector option, and its ECN Capable, Ack Ratio, and Send
Ack Vector features, are relevant for CCID 2.
9. Security Considerations
Security considerations for DCCP have been discussed in [RFC4340],
and security considerations for TCP have been discussed in [RFC2581].
[RFC2581] discusses ways in which an attacker could impair the
performance of a TCP connection by dropping packets, or by forging
extra duplicate acknowledgements or acknowledgements for new data.
We are not aware of any new security considerations created by this
document in its use of TCP-like congestion control.
10. IANA Considerations
This specification defines the value 2 in the DCCP CCID namespace
managed by IANA. This assignment is also mentioned in [RFC4340].
CCID 2 also introduces three sets of numbers whose values should be
allocated by IANA; namely, CCID 2-specific Reset Codes, option types,
and feature numbers. These ranges will prevent any future CCID
2-specific allocations from polluting DCCP’s corresponding global
namespaces; see [RFC4340], Section 10.3. However, this document
makes no particular allocations from any range, except for
experimental and testing use [RFC3692]. We refer to the Standards
Action policy outlined in [RFC2434].
10.1. Reset Codes
Each entry in the DCCP CCID 2 Reset Code registry contains a CCID
2-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.
10.2. Option Types
Each entry in the DCCP CCID 2 option type registry contains a CCID
2-specific option type, which is a number in the range 128-255; the
name of the option; and a reference to the RFC defining the option
type. Option types 184-190 and 248-254 are permanently reserved for
experimental and testing use. The remaining option types -- 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.
10.3. Feature Numbers
Each entry in the DCCP CCID 2 feature number registry contains a CCID
2-specific feature number, which is a number in the range 128-255;
the name of the feature; and a reference to the RFC defining the
feature number. Feature numbers 184-190 and 248-254 are permanently
reserved for experimental and testing use. The remaining feature
numbers -- 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.
11. Thanks
We thank Mark Handley and Jitendra Padhye for their help in defining
CCID 2. We also thank Mark Allman, Aaron Falk, Nils-Erik Mattsson,
Greg Minshall, Arun Venkataramani, Magnus Westerlund, and members of
the DCCP Working Group for feedback on this document.
A. Appendix: Derivation of Ack Ratio Decrease
This section justifies the algorithm for increasing and decreasing
the Ack Ratio given in Section 6.1.2.
The congestion avoidance phase of TCP halves the cwnd for every
window with congestion. Similarly, CCID 2 doubles Ack Ratio for
every window with congestion on the return path, roughly halving the
DCCP-Ack sending rate.
The congestion avoidance phase of TCP increases cwnd by one MSS for
every congestion-free window. When this congestion avoidance
behavior is applied to acknowledgement traffic, this would correspond
to increasing the number of DCCP-Ack packets per window by one after
every congestion-free window of DCCP-Ack packets. We cannot achieve
this exactly using Ack Ratio, since it is an integer. Instead, we
must decrease Ack Ratio by one after K windows have been sent without
a congestion event on the reverse path, where K is chosen so that the
long-term number of DCCP-Ack packets per congestion window is roughly
TCP friendly, following AIMD congestion control.
In CCID 2, rough TCP-friendliness for the ack traffic can be
accomplished by setting K to cwnd/(R^2 - R), where R is the current
Ack Ratio.
This result was calculated as follows:
R = Ack Ratio = # data packets / ack packets, and
W = Congestion Window = # data packets / window, so
W/R = # ack packets / window.
Requirement: Increase W/R by 1 per congestion-free window. Since
we can only reduce R by increments of one, we find K so that,
after K congestion-free windows, W/R + K would equal W/(R-1).
(W/R) + K = W/(R-1), so
K = W/(R-1) - W/R = W/(R^2 - R).
B. Appendix: Cost of Loss Inference Mistakes to Ack Ratio
As discussed in Section 6.1.1, the sender often cannot determine
whether lost packets carried data. This hinders its ability to
separate non-data loss events from other loss events. In the absence
of better information, the sender assumes, for the purpose of Ack
Ratio calculation, that all lost packets were non-data packets. This
may overestimate the non-data loss event rate, which can lead to a
too-high Ack Ratio, and thus to a too-slow acknowledgement rate. All
acknowledgement information will still get through -- DCCP
acknowledgements are reliable -- but acknowledgement information will
arrive in a burstier fashion. Absent some form of rate-based pacing,
this could lead to increased burstiness for the sender’s data
traffic.
There are several cases when the problem of an overly-high Ack Ratio,
and the resulting increased burstiness of the data traffic, will not
arise. In particular, call the receiver DCCP B and the sender DCCP
A:
o The problem won’t arise unless DCCP B is sending a significant
amount of data itself. When the B-to-A half-connection is
quiescent or low rate, most packets sent by DCCP B will, in fact,
be pure acknowledgements, and DCCP A’s estimate of the DCCP-Ack
loss rate will be reasonably accurate.
o The problem won’t arise if DCCP B habitually piggybacks
acknowledgement information on its data packets. The piggybacked
acknowledgements are not limited by Ack Ratio, so they can arrive
frequently enough to prevent burstiness.
o The problem won’t arise if DCCP A’s sending rate is low, since
burstiness isn’t a problem at low rates.
o The problem won’t arise if DCCP B’s sending rate is high relative
to DCCP A’s sending rate, since the B-to-A loss rate must be low
to support DCCP B’s sending rate. This bounds the Ack Ratio to
reasonable values even when DCCP A labels every loss as a DCCP-
Ack loss.
o The problem won’t arise if DCCP B sends NDP Count options when
appropriate (the Send NDP Count/B feature is true). Then the
sender can use the receiver’s NDP Count options to detect, in most
cases, whether lost packets were data packets or DCCP-Acks.
o Finally, the problem won’t arise if DCCP A rate-paces its data
packets.
This leaves the case when DCCP B is sending roughly the same amount
of data packets and non-data packets, without NDP Count options, and
with all acknowledgement information in DCCP-Ack packets. We now
quantify the potential cost, in terms of a too-large Ack Ratio, due
to the sender’s misclassifying data packet losses as DCCP-Ack losses.
For simplicity, we assume an environment of large-scale statistical
multiplexing where the packet drop rate is independent of the sending
rate of any individual connection.
Assume that when DCCP A correctly counts non-data losses, Ack Ratio
is set so that B-to-A data and acknowledgement traffic both have a
sending rate of D packets per second. Then when DCCP A incorrectly
counts data losses as non-data losses, the sending rate for the
B-to-A data traffic is still D pps, but the reduced sending rate for
the B-to-A acknowledgement traffic is f*D pps, with f < 1. Let the
packet loss rate be p. The sender incorrectly estimates the non-data
loss rate as (pD+pfD)/fD, or, equivalently, as p(1 + 1/f). Because
the congestion control mechanism for acknowledgement traffic is
roughly TCP friendly, and therefore the non-data sending rate and the
data sending rate both grow as 1/sqrt(x) for x the packet drop rate,
we have
fD/D = sqrt(p)/sqrt(p(1 + 1/f)),
so
f^2 = 1/(1 + 1/f).
Solving, we get f = 0.62. If the sender incorrectly counts lost data
packets as non-data in this scenario, the acknowledgement rate is
decreased by a factor of 0.62. This would result in a moderate
increase in burstiness for the A-to-B data traffic, which could be
mitigated by sending NDP Count options or piggybacked
acknowledgements, or by rate-pacing out the data.
Normative References
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow,
"TCP Selective Acknowledgement Options", RFC 2018,
October 1996.
[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.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP’s
Retransmission Timer", RFC 2988, November 2000.
[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.
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
Conservative Selective Acknowledgment (SACK)-based
Loss Recovery Algorithm for TCP", RFC 3517, April
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
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion
Window Validation", RFC 2861, June 2000.
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate
Byte Counting (ABC)", RFC 3465, February 2003.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust
Explicit Congestion Notification (ECN) Signaling with
Nonces", RFC 3540, June 2003.
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
Datagram Congestion Control Protocol (DCCP) Congestion
Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC
4342, 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
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).