Internet Engineering Task Force Yuchun Guo INTERNET-DRAFT Changjia Chen draft-guo-tsvwg-ctfrc-01.txt Yongxiang Zhao Univ. Northern Jiaotong Oct. 2001 Expires: April 2002 CTFRC(Coupon TFRC): An enhanced version of TFRC Protocol Specification Status of this Memo 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 proposes CTFRC (Coupon TFRC), an end-to-end congestion control mechanism friendly to both continuous streams and TCP flows, based on the modification of TFRC protocol and RED protocol. Taking account of the specific requirements of continuous streams, CTFRC protocol introduces a coupon function into TFRC to represent the bandwidth utilization of each stream, and revises RED to adjust drop probability according to the coupon value carried in each packet header. It inherits the merits of TFRC and promotes the QoS for continuous streams to a much higher level. Chen/Zhao/Guo [Page 1] INTERNET-DRAFT Expires: April 2002 October 2001 Table of Contents 1. Specification . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Mechanism . . . . . . . . . . . . . . . . . . . 4 3.1 Framework of CTFRC . . . . . . . . . . . . . . . . . 4 3.2 Coupon mechanism . . . . . . . . . . . . . . . . . . 4 3.2.1 Coupon evaluation mechanism . . . . . . . . . . . 4 3.2.2 Coupon execution mechanism . . . . . . . . . . . 5 3.3 Packet contents and coupon field . . . . . . . . . . 5 4. Protocol specifications . . . . . . . . . . . . . . . . 5 4.1 End-protocol . . . . . . . . . . . . . . . . . . . . 5 4.2 Network-protocol . . . . . . . . . . . . . . . . . . 7 5. Fairness Criterion of Coupon Function . . . . . . . . . 8 6. Authors' Addresses . . . . . . . . . . . . . . . . . . . 8 7. Reference . . . . . . . . . . . . . . . . . . . . . . . 8 Chen/Zhao/Guo [Page 2] INTERNET-DRAFT Expires: April 2002 October 2001 1. Specification In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119. 2. Introduction TFRC [1] is a TCP-friendly congestion control mechanism designed for streaming media. It has much lower variations of throughput over time compared with TCP, which makes it much suitable for continuous applications than TCP. While to probe smoother bandwidth than TCP does is the main object of TFRC, the bandwidth it probes still has large fluctuations observed in our simulations, thus only adaptive or layered coding schemes might exploit such a probed bandwidth efficiently. More seriously, TFRC does not give enough considerations to the specific characteristics distinguishing realtime streams from non-realtime applications including the following: (1) A realtime stream has its own traffic characteristics independent of the available network resources; (2) A realtime stream is delay-sensitive; (3) A realtime stream cannot endure the heavy network loss as a non-realtime flow does. TFRC assumes each flow can use up its fair share of bandwidth. However in many cases, a realtime application, such as the IP voice or low quality IP video application in today's Internet can consume only a fraction of the bandwidth it is allocated and won't change its working rate as the network bandwidth increases. Furthermore our simulation shows that for any stream transported by TFRC, no matter its working rate is smaller or larger than the TCP fair bandwidth, the loss rate and time delay it endures is at least in the same order as that of a competing TCP connection. Today's Internet has a loss rate in the order of 10%, which is intolerable for most applications. In this sense, we think TFRC is not so friendly to real-time streams as it is friendly to TCP in the network aspect. CTFRC is proposed to be friendly both to the TCP flows and continuous streams. The friendliness to continuous streams is defined as that the control mechanism manages to satisfy the specific requirements of continuous streams with best effort. When the working rate of a realtime stream is higher than the network fair bandwidth, CTFRC transmits this stream at the fair rate. Otherwise the CTFRC will pay back the stream some favorite QoS treatments as a compensation for the unused fraction of its fair share. This compensation could be a lower network loss rate, Chen/Zhao/Guo [Page 3] INTERNET-DRAFT Expires: April 2002 October 2001 a shorter delay, or a less delay jitter, or some combination of them, compared with that of TCP flows. With CTFRC, QoS can be dynamically adjusted at the transport layer and a straightforward encoding scheme can be used at the application layer. To implement this double friendliness, CTFRC introduces the concept of coupon that represents the intensity of some QoS favorite rights bartered with the unused bandwidth share and connects the network fairness with the QoS. Current coupon value is calculated and attached to a data packet header at the source terminal. Proper Per-Hop-Behavior (PHB) can be specified in the network to put the QoS favorites into effect according to the coupon. In this document a modified RED (Random Early Discard) algorithm is used in the network to tradeoff lower loss rate with unused bandwidth. To maintain the continuity in protocol stack and reduce the unnecessary work in programming of the protocol code, CTFRC proposed in this draft has very little modification to the already proposed protocols of TFRC and RED. In fact CTFRC can be viewed as a part of a new version of TFRC with a coupon mechanism. When the coupon mechanism is disabled in this new version of TFRC, it is the original TFRC. 3. Protocol Mechanism 3.1 Framework of CTFRC A model of CTFRC consists of two parts: end-protocol and network protocol. The end-protocol is essential a TFRC with only one change to add a coupon evaluation mechanism to calculate a coupon which is attached to the header of each sending packet. The network protocol is a slightly modified RED, which uses the coupon value carried by the received packet to adjust its dropping probability for this packet. Since the protocol of CTFRC is essential a modification to the existed two protocols, only the modified parts to these two existed protocols are specified in this draft. The essential part of these two protocols (TFRC and RED) is not changed and is embedded in the protocol of CTFRC as a whole. In the rest part of this document, the word "TFRC" and "RED" stand for the TFRC and RED part embedded in CTFRC if there has no any further specifications. 3.2 Coupon mechanism Coupon mechanism is the main feature CTFRC contributed to TFRC. It consists two parts: the coupon evaluation mechanism at the sending terminal and the coupon execution mechanism at the network. 3.2.1 Coupon evaluation mechanism Coupon evaluation mechanism uses a coupon function to evaluate a current Chen/Zhao/Guo [Page 4] INTERNET-DRAFT Expires: April 2002 October 2001 coupon value from probed bandwidth r_pb and user-consumed rate r_use, and attaches this coupon value to the header of each sending packet. In this draft, the probed bandwidth is provided by TFRC, the user-consumed rate is either estimated at the sending terminal (which needs a new component in CTFRC) or adopted from the report of receiving terminal (which has been specified in TFRC). The key component of coupon evaluation mechanism is the coupon function C(r_pb, r_use). The choice of coupon functions is largely influenced by the fairness criterion one may take. Further more, even for a given fairness criterion, one needs to slightly tune a given coupon function to overcome some implementation problems. In this document, we will specify CTFRC with an arbitrary coupon function, which will leave the room for the protocol to adopt any possible fairness considerations. saving space and further more for easy to understand what is changed, we discussion and test. In Section 5, the relations of coupon function and fairness criterion are discussed for further development in the protocol. 3.2.2 Coupon execution mechanism Coupon execution mechanism is an AQM scheme. It drops a packet with a probability that is related to the average buffer occupation and the coupon value stamped at the packet. In this document, modified RED is suggested as the coupon execution mechanism. This does not mean to exclude other possible AQM schemes to play a role in coupon execution mechanism. 3.3 Packet contents and coupon field CTFRC follows the TFRC specifications for the contents of data packets and feedback packets in [1] except of an additional coupon field inserted to the TFRC data packet header. This coupon field holds the coupon value the sender calculates for a packet. 4. Protocol specifications 4.1 End-protocol The end-protocol of CTFRC is a slightly modification to TFRC [1]. For saving space and further more for easy to understand what is changed, we use IETF draft [1] as the main body of the end-protocol of CTFRC. Only the changed parts are listed here. In this section we will use the following conventions: /number/, to indicate the section number in [1], for example /1.2/ means the Sec.1.2 in [1]. /text/, to denote the original sentences in draft [1]. //number//, to indicate the addition section we add to draft [1], for example //4.7// leads a section that we add to [1] and is Chen/Zhao/Guo [Page 5] INTERNET-DRAFT Expires: April 2002 October 2001 numbered according to the numbering sequence in [1]. Following are the changed parts to [1]. Add in /3.2.1/: /3.2.1. Data Packets Each data packet sent by the data sender contains the following information: o A ... .../ o A coupon value. The coupon value attached in packet i is denoted by C_i. Add a new section in /4/: /4. Data Sender Protocol The data ... We specify the sender-side protocol in the following steps: Measurement .... ..../ .../ /4.6. ... ... If t_gran is not known, a value of 10 ms can be safely assumed./ //4.7.// Coupon evaluation mechanism Probed bandwidth and user-consumed rate are denoted as r_pb and r_use respectively. The coupon function used is denoted as C(r_pb, r_use). // 4.7.1.// Calculation of user-consumed rate There are two options in getting user-consumed rate: estimated at the sending part (option E ) or adopted from the report of the receiving part (option A ): If option E r_use=r_ue Else if option A r_use= X_recv. Where X-recv is the actual user-consumed rate measured by the receiver (See Sec. 6.2 in [1]), r_ue is the estimated sending rate and can be calculated as follows [3]: r_ue = (1-exp(-T_i/K)) * l_i/T_i + exp(-T_i/K) * r_ue Where T_i = t_i - t_[i-1], the inter-packet interval, t_i, the arrival time of the packet i respectively, l_i, the length of the packet i respectively, l_i/T_i , the currently measured value of r, K, a constant, exp(-T_i/K), the exponential weight. Chen/Zhao/Guo [Page 6] INTERNET-DRAFT Expires: April 2002 October 2001 //4.7.2// Calculation of the coupon value For packet i that is sending do If nofeedback timer is not expired C_i = C(r_pb, r_use) Else C_i = 1 //4.7.3// Coupon Function In this document, following 3 coupon functions are recommended: 1). Simple coupon function: Cs(r_pb, r_use) = r_use/r_pb; 2). Lower-Limited Simple coupon function: the coupon value is lower bounded by a pre-set number of b_lower. The LL-S coupon function is denoted as CLL(r_pb, r_use) and defined as follows: If Cs(r_pb, r_use) >= b_lower CLL(r_pb, r_use) = Cs(r_pb, r_use) Else CLL(r_pb, r_use) = b_lower. 3). Run-Length Simple coupon function: In RL-S, the coupon function is varied periodically with a fixed number of packets being sent out. The period is named as the Coupon-Period and denoted as PC. In fact the value of PC can be chosen according to different applications and different network conditions just like b_lower for LL-S. The coupon function, after k packets being sent out from the start of a new period, is denoted as CRL(r_pb, r_use, k) for RL- S. The coupon function is defined as follows: If k = 0 CRL(r_pb, r_use,k) = 1 Else if 0< k < P_c CRL(r_pb, r_use, k) = (1-W_c) * CRL(r_pb, r_use, k-1) + W_c*r_use/r_pb. 4.2. Network-protocol CRED has only an additional function put on RED. A router calculates a drop probability p_drop based on the conventional RED algorithm. At receiving a packet i, the router extracts its coupon value C_i and weights the drop probability as follows: p_drop = p_drop* C_i . Then it drops this newly arrived packet with this modified probability much smaller than the real loss rate of the network when the coupon value is smaller than 1. Chen/Zhao/Guo [Page 7] INTERNET-DRAFT Expires: April 2002 October 2001 5. Fairness Criterion of Coupon Function We define Rate Consumption Factor f_rc as the consumed rate r_use normalized by the TCP-Fair Bandwidth r_tcp: f_rc = r_use/r_tcp. In general a coupon function should be a non-decreasing function of f_rc with an upper limit of 1. This will guarantee the fairness among CTFRC flows and the TCP friendliness of the resulted protocol in all cases. The simple coupon function we proposed above equivalents to Cs(r_pb, r_use) = min (f_rc^2,1) [2]. We name the inverse of a coupon value as the loss gain factor f_lg. The inverse of a coupon function 1/C(r_pb, r_use) physically means the gain factor of a CTFRC flow acquired in the loss probability compared with that of a TCP or TFRC flow in same network conditions. A fairness criterion is a rule that specifies how to trade the Rate Consumption Factor f_rc with the loss gain factor f_lg(f_rc). The fairness criterion adopted by the simple coupon function is f_lg(f_rc) = f_rc^(-2) approximately. The framework of the proposed CTFRC is broad enough to accommodate any possible fairness criterion simply by modifying the coupon function. 6. Authors' Addresses Yuchun Guo, Changjia Chen, Yongxiang Zhao Faculty of Electrical and Information Engineering Northern Jiaotong University Beijing, 100044 People's Republic of China guoyuchun21@sina.com.cn, changjiachen@sina.com.cn, yongxiang_zh@sina.com.cn 7. Reference [1] Mark Handley, Jitendra Padhye, Sally Floyd, Joerg Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", INTERNET-DRAFT, 20 July 2001. draft-ietf-tsvwg-tfrc-03 [2] Yongxiang Zhao, and Chang-jia Chen. "Coupon TFRC: A Mechanism Being Friendly to Both TCP and Continuous Streams", Computer Networks Journal, 2001.8ú¼accepted . [3] I. Stoica, S. Shenker, and H. Zhang, "Core-Stateless Fair Queue: A Scalable Architecture to Approximate Fair Bandwidth Allocation in High Speed Networks", In Proc. of ACM SIGCOMM'98, September 1998. Chen/Zhao/Guo [Page 8]