INTERNET-DRAFT Media Friendly Rate Control (MFRC) July 2004 Media Friendly Rate Control (MFRC) Internet Draft T. Phelan Document: draft-phelan-mfrc-00.txt Sonus Networks Expires: January 2005 July 2004 Media Friendly Rate Control (MFRC) Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I 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.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Media Friendly Rate Control (MFRC) is a mechanism for rate control of unicast media streams that is intended to be a better fit for the requirements of streaming media applications than TCP-Friendly Rate Control (TFRC), while still maintaining fairness with competing TCP applications. Phelan Expires - January 2005 [Page 1] INTERNET-DRAFT Media Friendly Rate Control (MFRC) July 2004 Table of Contents 1. Introduction...................................................3 2. Conventions....................................................3 3. Media Un-Friendly Rate Control.................................4 4. Media Friendly Rate Control....................................5 5. Usage..........................................................6 6. Receiver Feedback..............................................6 6.1 Congestion Control on Acknowledgements.....................7 6.2 Acknowledgement of Acknowledgments.........................7 7. Congestion Control on Data Packets.............................7 7.1 Congestion Control in the Uncongested Phase................7 7.2 Congestion Control in the Congested Phase..................8 7.3 Congestion Control in the Recovery Phase...................8 8. Explicit Congestion Notification...............................8 9. DCCP Options...................................................8 9.1 Window Counter.............................................8 9.2 Elapsed Time Options.......................................9 9.3 Loss Event Rate Option.....................................9 9.4 Receive Rate Option........................................9 10. Next Steps....................................................9 11. Security Considerations......................................10 12. IANA Considerations..........................................10 13. Normative References.........................................10 14. Informative References.......................................10 15. Author's Address.............................................10 16. Full Copyright Statement.....................................10 Phelan Expires - January 2005 [Page 2] INTERNET-DRAFT Media Friendly Rate Control (MFRC) July 2004 1. Introduction One of the driving applications for the Datagram Congestion Control Protocol (DCCP) [DCCP] has been streaming media. The DCCP User Guide [DCCPUG] shows how streaming media applications can be adapted to DCCP with TCP-Friendly Rate Control (TFRC) [RFC 3448], as implemented for DCCP in Congestion Control ID 3 [CCID3]. Unfortunately, the fit is not perfect. In particular, the slow-start, restart and rate variation aspects of TFRC are at odds with some bandwidth-saving techniques in common use such as silence suppression for voice streams and "stillness" suppression for video streams. This is especially true for two-way media streams where the requirements for end-to-end delay are very tight. Where the multiplexing level is high, these bandwidth-saving techniques can significantly increase the number of sessions that can be served by a given link. Also, for centralized conferencing applications, the ability to stop and immediately restart streams as the conference focus changes can significantly reduce the server load. The gradual throughput changes imposed by TFRC (and for that matter, all congestion control algorithms standardized by the IETF) make these techniques impossible in many circumstances. Many people feel that the loss of these benefits isn't outweighed by the additional benefits of TFRC congestion control. This document outlines a scheme for Media Friendly Rate Control (MFRC) that will allow streaming media applications to behave in more natural ways, while still behaving fairly towards TCP applications. At this point the ideas here are in their formative stages, and much more work needs to be done, including simulations, to reach a fully operational protocol. The purpose of the document is to gain community feedback on the feasibility of the concepts, or at least stimulate some new thinking on the subject. This document defines MFRC in the context of a new CCID for DCCP. This is not meant to circumvent any processes; it's just a matter of expediency. It's much easier to define the protocol in the framework of DCCP than to invent some new abstract framework. As (if) this moves forward, other formats are possible. 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 [RFC 2119]. Phelan Expires - January 2005 [Page 3] INTERNET-DRAFT Media Friendly Rate Control (MFRC) July 2004 All multi-byte numerical quantities, such as arguments to options, are transmitted in network byte order (most significant byte first). 3. Media Un-Friendly Rate Control TFRC and other standard congestion control algorithms use a "guilty until proven innocent" approach to rate control. Streams must enter the network gently, and gradually increase to the available capacity. This is entirely reasonable for many data applications. Can you imagine what would happen with a World Wide Web server on a gigabit Ethernet interface and a client on a dialup connection without TCP slow start? Each file transfer would cause massive congestion at the Remote Access Server handling the client, and possibly at several other points in the network (the gigabit-connected server probably has only a T3 access link to the Internet, for example). This is because of the inherent greediness of file-transfer applications. They can always use every bit of capacity that's available. In the vast majority of cases they will cause congestion if not restrained, especially in the normal client-server mode of operation where servers have high capacity relative to most clients. On the other hand, imagine our same gigabit server and dialup client using a streaming media application, operating in the normal practice without some form of slow-start. In this case the client will typically pick a media encoding that's suitable for its local conditions. The server will deliver the program at that encoding rate, and the vast majority of times nothing will be congested. If the server is forced to slow start up to the encoding rate, the only effective result, most of the time, will be to uselessly delay the start of the program. Now imagine that the media stream is not encoded at a constant bit rate, but varies its encoding rate depending on activity in the signal (silence or "stillness" suppression). This doesn't matter to the client. It is only receiving one stream, and so must choose an encoding with a maximum rate suitable to its circumstances. The server, however, is serving multiple streams, and variable-rate encoding can greatly increase the number of simultaneous streams served. Some video codecs can vary their transmission rate by a factor of ten from frame to frame, allowing very large rates of statistical multiplexing in many circumstances. But TFRC only allows gentle rate increases and restarts from idle, so these capacity increases are not available to the server, even though it's highly likely that they won't cause congestion. What is needed is an "innocent until proven guilty" approach. Phelan Expires - January 2005 [Page 4] INTERNET-DRAFT Media Friendly Rate Control (MFRC) July 2004 4. Media Friendly Rate Control Media Friendly Rate Control (MFRC) uses a three-phase approach to implement the "innocent until proven guilty" policy while still maintaining reasonable fairness with competing TCP streams. The three phases are: o Uncongested phase -- Connections begin operation in the uncongested phase. In this phase an application is free to vary its transmissions as it pleases, up to some maximum value set at connection startup. While in this phase, media stream operations are identical to the usual UDP practice. o Congested phase -- Connections enter the congested phase from the uncongested phase when there's a packet loss event. The allowed transmission rate is initially half of the uncongested rate. The allowed transmission rate continues to decrease by half for each round trip time (RTT) that contains a packet loss event. o Recovery phase -- Connections enter the recovery phase from the congested phase when there have been no packet loss events for a number of RTTs. Initially, the allowed transmission rate is the last rate from the congested phase. During the recovery phase, the allowed transmission rate follows TFRC operation, as specified in [RFC 3448], gradually decreasing in response to loss events, and gradually increasing in the absence of loss. The connection returns to the uncongested phase when the allowed transmission rate returns to the connection's maximum rate. In all phases, the receiver sends acknowledgements to the sender roughly once per RTT. Phelan Expires - January 2005 [Page 5] INTERNET-DRAFT Media Friendly Rate Control (MFRC) July 2004 Graphically, the phase transitions are: Connection start | V +-------------+ | | Max xmit rate set by application | Uncongested | Free variation up to max rate | | +-------------+<------------------------------+ | | | Packet loss event | | Allowed rate = max rate/2 | V | +-----------+ | | |<----+ Packet loss event | | Congested | | Allowed rate /= 2 | | |-----+ | +-----------+ | | | | No packet loss events for X RTTs | V | +----------+ | | | Allowed rate controlled by TFRC | | Recovery | | | |----------------------------------+ +----------+ Allowed rate = connection max rate 5. Usage MFRC is intended for use by applications that can choose a maximum transmission rate that is reasonably unlikely to cause congestion, under normal operating conditions, and are willing to live within the chosen rate and forgo any extra capacity that might be available. Because TFRC measures the transmission rate in packets per second, not bytes, the applications also must use packets of a relatively fixed size, and vary the transmit rate by varying the rate at which packets are emitted. 6. Receiver Feedback In all phases of operation, the receiver sends acknowledgement packets to the sender roughly once per RTT, or once per packet if it receives less than one packet per RTT. At the receiver, the RTT can be estimated by using the window counter value (see section 9.1) in received packets, using the procedure defined in [CCID3]. Acknowledgements can use DCCP-Ack or DCCP-DataAck packets. If the receiver is sending a return data stream it may send piggybacked acknowledgements more that once per RTT. Phelan Expires - January 2005 [Page 6] INTERNET-DRAFT Media Friendly Rate Control (MFRC) July 2004 The Acknowledgement Number in the acknowledgement packet acknowledges the greatest valid sequence number received on this connection (measured in circular sequence space). Each acknowledgement also includes the following options: 1) An Elapsed Time option specifying the amount of time elapsed since the receiver received the packet whose sequence number appears in the Acknowledgement Number field. 2) A Receive Rate option specifying the rate at which the receiver received data since the last acknowledgement. 3) A Loss Event Rate option specifying the loss event rate calculated by the receiver. 6.1 Congestion Control on Acknowledgements As acknowledgements are only sent once per RTT, there is no need for congestion control on acknowledgements. 6.2 Acknowledgement of Acknowledgments There is no need for the sender to acknowledge received acknowledgements. 7. Congestion Control on Data Packets The mechanisms for controlling the rate at which data packets can be sent vary, depending on the phase of the connection. In all phases, the sender calculates an RTT estimate from received feedback packets as described in [RFC 3448]. The sender also maintains a no feedback timer, set to expire in two RTTs if no feedback packets are received (initially set to expire in 2 seconds). In all phases, transmission rates are calculated as packets of a certain size per second, not bytes per second. Implementations SHOULD allow the applications to indicate the desired packet size. 7.1 Congestion Control in the Uncongested Phase In the uncongested phase, the allowed sending rate is limited to a value set at connection startup (referred to as the "connection's maximum rate"), and can vary up to and down from that rate as the application desires. A connection starts out in this phase and remains there until it receives an acknowledgement packet that reports a non-zero loss event rate, or if the no feedback timer expires. When a connection leaves the uncongested phase it enters the congested phase. Phelan Expires - January 2005 [Page 7] INTERNET-DRAFT Media Friendly Rate Control (MFRC) July 2004 7.2 Congestion Control in the Congested Phase In the congested phase, the initial allowed sending rate is half of the connection's maximum rate. As acknowledgement packets with non- zero loss event rates are received, the allowed sending rate is set to the lesser of half the current rate or the received rate indicated in the acknowledgement. If the no feedback timer expires, the allowed sending rate is halved. The connection leaves the congested phase, and enters the recovery phase, when acknowledgements have been received for the last X (actual number needs more study) RTTs and all had zero loss event rates. 7.3 Congestion Control in the Recovery Phase In the recovery phase, the initial allowed sending rate is unchanged from the last congested phase rate. From there, it varies up and down as described in [RFC 3448], based on feedback (or lack thereof) from the receiver. The connection leaves the recovery phase, and re- enters the uncongested phase when the allowed sending rate equals the connection's maximum sending rate. 8. Explicit Congestion Notification The use of Explicit Congestion Notification (ECN) is for further study. 9. DCCP Options MFRC makes use of DCCP's Elapsed Time option, and uses the CCVal field in the generic DCCP header as a window counter. In addition, it defines two CCID-specific options: Type Length Meaning Section ---- ------ ------- ------- 128-191 Reserved 192 6 Loss Event Rate 9.3 193 6 Receive Rate 9.4 194-255 Reserved 9.1 Window Counter 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. The full procedure for updating and transmitting the window counter is given in [CCID3]. Phelan Expires - January 2005 [Page 8] INTERNET-DRAFT Media Friendly Rate Control (MFRC) July 2004 9.2 Elapsed Time Options The receiver MUST include an elapsed time value on every required acknowledgement. Its value indicates the time (in tenths of milliseconds) elapsed at the receiver from the reception of the acknowledged packet to the transmission of the acknowledgement packet. The sender uses this value to adjust its RTT calculation for the delay at the receiver due to the infrequent acknowledgement rate. The format of this option is defined in the main DCCP specification [DCCP]. 9.3 Loss Event Rate Option +--------+--------+--------+--------+--------+--------+ |11000010|00000010| 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 packets per loss interval. See [RFC 3448] for a normative calculation of loss event rate. 9.4 Receive Rate Option +--------+--------+--------+--------+--------+--------+ |11000011|00000010| Receive Rate | +--------+--------+--------+--------+--------+--------+ Type=193 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. The Receive Rate is calculated as the number of bytes received in the most recent t seconds, divided by t, where t is the larger of the following: o the time since the last Receive Rate Option was sent o the estimated round-trip time. The receiver has an estimate of the round-trip time from the Window Counter Value in received data packets. 10. Next Steps Obviously these ideas are in the formative stage, and a great deal more effort will be necessary to realize a working mechanism. At this stage, I'm just hoping to get high-level feedback and stimulate more thinking on this matter. Phelan Expires - January 2005 [Page 9] INTERNET-DRAFT Media Friendly Rate Control (MFRC) July 2004 11. Security Considerations Security considerations are for further study. 12. IANA Considerations MRFC is defined here as a new CCID for DCCP, but at this time there is no request to allocate a new CCID value. The use of a new CCID value is for further study. 13. Normative References [DCCP] E. Kohler, M. Handley, S. Floyd, Datagram Congestion Control Protocol (DCCP), draft-ietf-dccp-spec-06.txt, February 2004, work in progress. [RFC 3448] M. Handley, S. Floyd, J. Padhye, J. Widmer, TCP Friendly Rate Control (TFRC): Protocol Specification, RFC 3448, January 2003. [CCID3] S. Floyd, E. Kohler, J. Padhye, Profile for DCCP Congestion Control ID 3: TFRC Congestion Control, draft- ietf-dccp-ccid3-05.txt, February 2004, work in progress. [RFC 2119] S. Bradner, Key Words for Use in RFCs to Indicate Requirement Levels, RFC 2119, March 1997. 14. Informative References [DCCPUG] T. Phelan, Datagram Congestion Control Protocol (DCCP) User Guide, draft-ietf-dccp-user-guide-02.txt, July 2004, work in progress. 15. Author's Address Tom Phelan Sonus Networks 5 Carlisle Rd. Westford, MA USA 01886 Phone: 978-681-8456 Email: tphelan@sonusnet.com 16. Full Copyright Statement Copyright ¨ The Internet Society (2004). 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 Phelan Expires - January 2005 [Page 10] INTERNET-DRAFT Media Friendly Rate Control (MFRC) July 2004 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. Phelan Expires - January 2005 [Page 11]