Internet Engineering Task Force
INTERNET-DRAFT Jitendra Padhye
draft-padhye-dcp-ccid3-00.txt Sally Floyd
Eddie Kohler
ACIRI
13 July 2001
Expires: January 2002
Profile for DCP Congestion Control ID 3:
TFRC Congestion Control
Status of this Document
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This document contains the profile for Congestion Control
Identifier 3, TCP-friendly rate control (TFRC), in the
Datagram Control Protocol (DCP). DCP implements a congestion-
controlled unreliable datagram flow suitable for use by
applications such as streaming media. The TFRC CCID is used by
applications that want a TCP-friendly send rate, possibly with
Explicit Congestion Notification (ECN), while minimizing
Padhye/Floyd/Kohler [Page 1]
INTERNET-DRAFT Expires: January 2002 July 2001
abrupt rate changes.
Padhye/Floyd/Kohler [Page 2]
INTERNET-DRAFT Expires: January 2002 July 2001
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4
1.1. Usage Scenario . . . . . . . . . . . . . . . . . . . 4
1.2. Example Half-Connection. . . . . . . . . . . . . . . 4
2. Connection Establishment. . . . . . . . . . . . . . . . 5
3. Congestion Control on Data Packets. . . . . . . . . . . 5
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . 6
4.1. Congestion Control on Acknowledgments. . . . . . . . 6
4.2. Quiescence . . . . . . . . . . . . . . . . . . . . . 6
4.3. Acknowledgments of Acknowledgments . . . . . . . . . 7
5. Explicit Congestion Notification. . . . . . . . . . . . 7
6. Relevant Options and Features . . . . . . . . . . . . . 7
6.1. RTT Option . . . . . . . . . . . . . . . . . . . . . 7
6.2. Send Rate Option . . . . . . . . . . . . . . . . . . 8
6.3. Loss Event Rate Option . . . . . . . . . . . . . . . 8
6.4. Receive Rate Option. . . . . . . . . . . . . . . . . 8
6.5. ECN NONCE Option . . . . . . . . . . . . . . . . . . 9
7. Application Requirements. . . . . . . . . . . . . . . . 9
8. Thanks. . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References. . . . . . . . . . . . . . . . . . . . . . . 10
10. Authors' Addresses . . . . . . . . . . . . . . . . . . 11
Padhye/Floyd/Kohler [Page 3]
INTERNET-DRAFT Expires: January 2002 July 2001
1. Introduction
This document contains the profile for Congestion Control Identifier
3, TCP-friendly rate control (TFRC), in the Datagram Control
Protocol (DCP). DCP uses Congestion Control Identifiers, or CCIDs,
to specify the congestion control mechanism in use on a half-
connection. (A half-connection might consist of data packets sent
from DCP A to DCP B, plus acknowledgments sent from DCP B to DCP A.
DCP A is the sending DCP, and DCP B the acknowledging DCP, for this
half-connection.)
TFRC is a receiver-based congestion control mechanism that provides
a TCP-friendly send rate, while minimizing abrupt rate changes [1].
The basic TFRC protocol is as follows. The sender sends a stream of
data packets to the receiver at some rate. The receiver sends a
feedback packet to the sender once every round-trip time. Based on
the information contained in the feedback packets, the sender
adjusts its sending rate in accordance with the TCP throughput
equation [2], to maintain TCP-friendliness. If no feedback is
received from the receiver in two round-trip times, the sender
halves its sending rate.
The values of the round-trip time (RTT), the loss event rate (p) and
the base timeout value T_0 are needed to calculate the send rate
using the TCP throughput equation. In the TFRC protocol, the sender
is responsible for calculating the values of RTT and T_0, while the
receiver is responsible for calculating the value of p.
We note that this draft is a first pass, and is not necessarily
complete.
1.1. Usage Scenario
TFRC is intended to provide congestion control for the flow of data
packets from the server to the client for applications that do not
require fully reliable data transmission.
1.2. Example Half-Connection
This example, taken from the main DCP draft, is of a half-connection
using TFRC Congestion Control specified by CCID 3. The "sender" is
the HC-Sender, and the "receiver" is the HC-Receiver.
1 The server sends DCP-Data packets, where the number of packets
sent is governed by an allowed transmit rate, as specified in
[1]. Each DCP-Data packet has a sequence number, and includes an
Padhye/Floyd/Kohler Section 1.2. [Page 4]
INTERNET-DRAFT Expires: January 2002 July 2001
Acknowledgment Number that is the sequence number of the most
recent acknowledgment packet received from the client. Each
DCP-Data packet also contains a timestamp, the server's estimate
of the round-trip time, and the current sending rate.
One or more of these data packets are DCP-DataAck packets
acknowledging the data packet from the client, but for
simplicity we will not discuss the half-connection of data from
the client to the server in this example.
2 The client sends DCP-Ack packets at least once per round-trip
time acknowledging the data packets, or as indicated by the TFRC
specification [1]. Each DCP-Ack packet uses a sequence number
and identifies the most recent packet received from the server.
Each DCP-Ack packet includes feedback about the loss event rate
calculated by the client, as specified below.
3 The server continues sending DCP-Data packets as controlled by
the allowed transmit rate. Upon receiving DCP-Ack packets, the
server updates its allowed transmit rate as specified in [1].
4 The server estimates round-trip times and calculates a TimeOut
(TO) value as specified in [1].
5 Each DCP-Data, DCP-DataAck, and DCP-Ack 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 below.
2. Connection Establishment
The connection is initiated by the client using mechanisms described
in the DCP specification [3]. The client and the server MAY
negotiate the use of ACK Vector option. Both the server and the
client MUST support the timestamp option. The ACK vector option and
the timestamp option are described in [3].
3. Congestion Control on Data Packets
The sender sends DCP-Data packets to the receiver at the rate
specified by the TCP throughput equation [2].
Each DCP-Data packet has a sequence number, and an acknowledgment
number that is the sequence number of the most recent acknowledgment
packet received from the receiver. Each data packet contains the
following options:
Padhye/Floyd/Kohler Section 3. [Page 5]
INTERNET-DRAFT Expires: January 2002 July 2001
1. Timestamp option, as described in [3].
2. An option specifying sender's estimate of the round-trip
time.
3. An option specifying the current sending rate.
The format of options 2 and 3 is described below.
After each feedback packet is received from the receiver, the sender
updates values of RTT, T_0 and the sending rate using procedures
specified in [1].
If no feedback packet is received from the receiver, the sending
rate is halved. However, the sending rate is never reduced below
one packet per 64 seconds. See [1] for more details.
4. Acknowledgments
The receiver sends DCP-Ack packets to the sender once per round-trip
time, or more frequently. This rate is determined by details of the
TFRC protocol, as specified in [1].
The acknowledgment number in DCP-Ack acknowledges the most recent
packet received from the sender. Each Ack packet from the receiver
includes the following options:
1. The echo timestamp option described in [3].
2. An option specifying the loss event rate (p) calculated by
the receiver as described in [1].
3. An option specifying the rate at which the receiver received
data since the last DCP-Ack was sent.
The format of options 2 and 3 is described below.
4.1. Congestion Control on Acknowledgments
The rate and timing for generating acknowledgments is determined by
the TFRC algorithm [1].
4.2. Quiescence
This section refers to quiescence in the DCP sense (see section 6.1
of [3]): How does a CCID 3 receiver determine that the corresponding
Padhye/Floyd/Kohler Section 4.2. [Page 6]
INTERNET-DRAFT Expires: January 2002 July 2001
sender is not sending any data?
The receiver detects that the sender has gone quiescent after two
round-trip times have passed without receiving any additional data.
Since ACKs are not required to be reliable, the receiver needs to do
nothing special in this case, unlike CCID 2 [5].
4.3. Acknowledgments of Acknowledgments
Acknowledgments in TFRC are entirely unreliable -- TFRC works even
if every acknowledgment is dropped -- and it is never necessary for
the sender to acknowledge an acknowledgment.
5. Explicit Congestion Notification
ECN [6] MAY be used with CCID 3. If ECN is used, then the ECN Nonce
will automatically be used for the data packets, following the
specification for the ECN Nonce [4] for TCP. For the data sub-flow,
the sender sets either the ECT[0] or ECT[1] codepoint on DCP-Data
packets. If the ACK vector option is being used, the ECN-NONCE
information is returned via the ACK vector. Otherwise, the
information about ECN-NONCE is returned by the receiver using the
ECN-NONCE option described below. The receiver MUST return this
option if ECN is being used, and if it is reporting a lower packet
loss rate than the one it reported in the previous acknowledgment.
We are working on this further.
6. Relevant Options and Features
6.1. RTT Option
+--------+--------+----...-----+
|10000000|00000100| RTT Value |
+--------+--------+----...-----+
Type=128 Len=4 2 bytes
This option is set by the data sender on all data packets. The first
byte gives the option type and the second gives the option length.
The last two bytes indicate sender's estimation of round-trip time
in whole milliseconds.
Padhye/Floyd/Kohler Section 6.1. [Page 7]
INTERNET-DRAFT Expires: January 2002 July 2001
6.2. Send Rate Option
+--------+--------+----...-----+
|10000001|00000110| Send rate |
+--------+--------+----...-----+
Type=129 Len=6 4 bytes
This option is set by the data sender on all data packets. The first
byte gives the option type and the second gives the option length.
The last four bytes indicate the current sending rate in bits per
second.
6.3. Loss Event Rate Option
+--------+--------+----...-----+
|11000000|00000110| Loss rate |
+--------+--------+----...-----+
Type=192 Len=6 4 bytes
This option is set by the data receiver on all acknowledgment
packets. The first byte gives the option type and the second gives
the option length. The last four bytes indicate the inverse of the
loss event rate, rounded UP, as calculated by the receiver.
6.4. Receive Rate Option
+--------+--------+----...-----+
|10000001|00000110| Recv rate |
+--------+--------+----...-----+
Type=129 Len=6 4 bytes
This option is set by the data receiver on all acknowledgment
packets. The first byte gives the option type and the second gives
the option length. The last four bytes indicate the the rate at
which the receiver received the data since it last sent the
acknowledgment, in bits per second.
Padhye/Floyd/Kohler Section 6.4. [Page 8]
INTERNET-DRAFT Expires: January 2002 July 2001
6.5. ECN NONCE Option
+--------+--------+----...-----+----...-----+--------+
|10000010|00001001| Left Edge | Right Edge |X0000000|
+--------+--------+----...-----+----...-----+--------+
Type=130 Len=9 3 bytes 3 bytes 1 byte
This option is set by the data receiver on any acknowledgment packet
that reports a loss rate lower than the loss rate reported in the
previous acknowledgment packet. The first byte gives the option
type and the second gives the option length. The right edge (RE)
and the left edge (LE) are sequence numbers of data packets, such
that:
- Let LastAck be the sequence number of the data packet
acknowledged by the previous acknowledgment.
- If (LastAck + 1) was a dropped or marked packet, then RE
should be the highest non-dropped and non-marked packet before
(LastAck + 1).
- If (LastAck + 1) was not a dropped or marked packet, the RE
should be the greatest sequence number such that all data
packets between (LastAck + 1) and RE, inclusive, were received
and not ECN-marked. Clearly (RE >= LastAck + 1).
- LE should be the smallest sequence number such that all data
packets between LE and RE, inclusive, were received and not ECN-
marked. Clearly (LE <= RE).
The first bit of the final byte is the Nonce Echo. It equals the
base-2 modulus of the number of received ECN Nonce packets between
LE and RE, both included.
Note that the interval [LE, RE] would be the largest non-loss
interval containing the first packet received since the last report,
or, if that was a dropped packet, containing the run before this
drop. That is, [LE, RE] would continue to grow during non-drop and
non-mark periods.
7. Application Requirements
As described in the TFRC specifications [1], this CCID should not be
used by applications that change sending rate by varying packet
size, rather than varying the rate at which packets are sent.
Padhye/Floyd/Kohler Section 7. [Page 9]
INTERNET-DRAFT Expires: January 2002 July 2001
8. Thanks
We thank Mark Handley for his help in defining CCID 3.
9. References
[1] M. Handley, J. Padhye, and S. Floyd. TCP Friendly Rate Control
(TFRC): Protocol Specification. draft-ietf-tsvwg-tfrc-02.txt,
work in progress.
[2] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose. Modeling TCP
Throughput: A Simple Model and its Empirical Validation. Proc
ACM SIGCOMM 1998.
[3] E. Kohler, M. Handley, S. Floyd, and J. Padhye. Datagram
Control Protocol. Work in progress.
[4] David Wetherall, David Ely, and Neil Spring. Robust ECN
Signaling with Nonces. draft-ietf-tsvwg-tcp-nonce-00.txt, work
in progress.
[5] S. Floyd, E. Kohler. Profile for DCP Congestion Control ID 2:
TCP-like Congestion Control. Work in progress.
[6] K. Ramakrishnan and S. Floyd. A Proposal to add Explicit
Congestion Notification (ECN) to IP. RFC 2481.
Padhye/Floyd/Kohler Section 9. [Page 10]
INTERNET-DRAFT Expires: January 2002 July 2001
10. Authors' Addresses
Jitendra Padhye <padhye@aciri.org>
Sally Floyd <floyd@aciri.org>
Eddie Kohler <kohler@aciri.org>
AT&T Center for Internet Research at ICSI (ACIRI),
ICSI,
1947 Center Street, Suite 600
Berkeley, CA 94704.
Padhye/Floyd/Kohler Section 10. [Page 11]