Network Working Group P. O'Hanlon Internet-Draft University of Oxford Intended status: Informational K. Carlberg Expires: January 10, 2013 G11 July 9, 2012 Congestion control algorithm for lower latency and lower loss media transport draft-ohanlon-rmcat-dflow-00 Abstract This memo provides an initial design for a congestion control algorithm, for media transport, which aims to provide for lower delay and lower loss communications. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 10, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. O'Hanlon & Carlberg Expires January 10, 2013 [Page 1] Internet-Draft DFlow media congestion control July 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. TFRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Delay-Based schemes . . . . . . . . . . . . . . . . . . . . 5 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Design Outline . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Congestion Detection . . . . . . . . . . . . . . . . . . . 7 6. Further Work . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 O'Hanlon & Carlberg Expires January 10, 2013 [Page 2] Internet-Draft DFlow media congestion control July 2012 1. Introduction This memo outlines DFlow, a congestion control algorithm that aims to minimise delay and loss by using delay-based techniques. The scheme is based upon TCP Friendly Rate Control (TFRC) [RFC5348], and adds a delay-based congestion detection scheme which feeds into a 'congestion event history' mechanism based upon TFRC's loss history. This then provides for a 'congestion event rate' which drives the TCP equation. Low delay congestion control is important for real-time streams as high delay can render the communication unacceptable [ITU.G114.2003]. Unfortunately on today's Internet many paths have an excess of buffering which can lead to persistent high latencies, which has become known as the Bufferbloat phenomenon. These problems are particularly apparent with loss-based congestion control schemes such as TCP, as they operate by filling the queues on a path till loss occurs, thus maximising the delay. The unfortunate consequence is that loss-based approaches not only lead to high delay for their own packets but also introduce delays and losses for all other flows that traverse those filled queues. Thus when competing with TCP, without the widespread deployment of Active Queue Management, it is not possible to maintain low delay as TCP will do its best to keep the queues full and maximise the delay. Furthermore when competing with TCP other flows will incur losses which should be used to operate a loss-based algorithm whilst in the presence of the TCP flows. However there are a many paths where the flows are not competing directly with TCP and where delay may be minimised. The DFlow scheme can transport media with low delay and loss on paths where there is no direct competion with TCP in the same queue. Though we are currently testing some techniques to enable it compete with loss-based schemes (at the expense of delay) but they will be included in a later version of the draft. In simulations it has been seen to be reasonably fair when competing with other DFlow streams. 2. Conventions, Definitions and Acronyms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. O'Hanlon & Carlberg Expires January 10, 2013 [Page 3] Internet-Draft DFlow media congestion control July 2012 3. Background Whilst the existing standard for media transport, Real-time Transport Protocol (RTP) [RFC3550], suggest that congestion control should be employed, in practice many systems tend to use fixed or variable bit rate UDP and do very little or no adaptation to their network environment. Most of the existing work on realtime congestion control algorithms has been rooted in TCP-friendly approaches but with smoother adaptation cycles. TCP congestion control is unsuitable for interactive media for a number of reasons including the fact that it is loss-based so it maximises the latency on a path, it changes its transmit rate to quickly for multimedia, and favours reliability over timeliness. Various TCP-friendly congestion control algorithms such as TFRC [RFC5348], Sislem's LDA+, and Choi's TFWC have been devised for unreliable media transport, that attempt to smooth the short-term variation in sending rate. More recently there have been development of some delay-based schemes which aim to provide for low delay. 3.1. TFRC TFRC is a rate based receiver driven congestion control algorithm which utilises the Padhye TCP equation to provide a TCP-friendly rate. The sender explicitly sets the transmission rate, using the TCP equation driven by the loss event rate which is measured and fed back by the receiver, where a loss event consists of one or more packet losses within a single RTT. It utilises a weighted smoothed loss event rate, and EWMA smoothed RTT, as input to the TCP Equation which enables it to achieve a smoother rate adaptation that provides for a more suitable transport for multimedia. TFRC was primarily aimed at streaming media delivery where a smooth rate and TCP- friendliness are more important than low latency operation. However there are number of issues with TFRC as regards media transport: Loss-based operation: Firstly since it is a loss-based based scheme the latency is maximised which is a problem for real-time transport over heavily buffered paths. The other problem with loss-based protocols is that they rely on a certain level of packet loss which can be an issue for media traffic since retransmissions are problematic. This problem is more of a concern as rates decrease since the TCP equation requires a corresponding increase in loss rates. O'Hanlon & Carlberg Expires January 10, 2013 [Page 4] Internet-Draft DFlow media congestion control July 2012 Bursty media flows: Many media flows exhibit bursty behaviour due to a number of factors. Firstly there may be negative bursts (i.e. gaps) due to silence or low motion which can lead oscillatory behaviours due to the its data-limited and/or idle behaviours. Secondly there may be postive bursts (i.e. larger than normal) can also be due to the bursty nature of the media and codec (e.g. I-frames) which can be lead to drops or increased latency. Whilst the current version of TFRC [RFC5348] has attempted to address these issues, they are still a concern. Small RTTs environments: When operating in low RTT environments (<5ms), such as a LAN, TFRC has can have problems with scheduling packet transmissions as interpacket timings can be lower than application level clock granularity. Furthermore these conditions can Whilst the current version of TFRC [RFC5348] has attempted to address these issues, they can still be a concern in low RTT environments. Variable packet sizes: As originally designed TFRC will only operate correctly when packet sizes are close to MTU size, and when the packet sizes are much smaller fairness issues arise. Although there have been attempts to address this problem for small packets [RFC4828] it is not clear how to deal with flows that do vary their packet sizes substantially. Though this issue is only really a marked problem with lower bit rate video flows or variable packet rate audio. 3.2. Delay-Based schemes In the last few years there has been a renewed interest in the use of delay based congestion control for media, with a slightly different emphasis to that of the history of TCP approaches such as Jain's CARD, Crowcroft and Jon's Tri-S, Brakmo's Vegas, and more recently Tan et al's Compound TCP. Whilst the goal with these media based transports is to actually minimise the latency of the flow, as opposed to just using delay as an early indication of loss. This is of particular relevance on paths with large queues, as is the case with a number of today's Internet paths. In 2007 Ghanbari et al did some pioneering work on delay-based video congestion control using fuzzy logic based systems. Recently there has been on going activity in the IETF as part of the Low Extra Delay Background Transport (LEDBAT) Working Group which aims to provide a less than best effort delay-based transport with lower delay. More recently Google published a contribution to the Real-Time Communication in WEB- browsers (RTCWeb) Working Group, which has now been spun off to the new BOF on RTP Media Congestion Avoidance Techniques (rmcat). O'Hanlon & Carlberg Expires January 10, 2013 [Page 5] Internet-Draft DFlow media congestion control July 2012 4. Objectives The objectives of DFlow are to provide for low delay and low loss media transport when possible. We also aim to provide (in a future version of the draft) mechanisms to provide for better burst management, and loss-mode operation (the key being the switch from loss-mode back to delay-mode). Lower Delay: The one-way delay should be kept well within the acceptable levels of 150ms, and MUST NOT exceed 400ms [ITU.G114.2003]. Lower Loss: For media transport is important to minimise loss as it is usually not possible to retransmit within the delay budget for many connections. Whilst modern codecs can tolerate some loss it is beneficial to avoid it. The benefit of low delay congestion control is that since it aims to operate within the queuing boundaries it generally avoids loss. Smoothness: The media rate should aim to be smooth within the constraints of the media, codec, and the network path. A smooth rate generally provides for a more palatable media consumption. Fairness: The system should aim to be reasonably fair with TCP flows and itself. Initially we aim for self fairness and we will aim to tackle TCP fairness when we have sufficiently robust loss-mode operation. [Burst Management]: [Due in later rev] We aim to work on mechanisms to manage the bursty nature of media allowing it maintain a smoother quality. A smooth rate generally provides for a more palatable media consumption. [Loss-based mode]: [Due in later rev] We aim to wrok on mechanisms to allow the system to compete with loss-based congestion control and maintain throughput, though without additional network support it is understood that the delay (and loss) would be largely beyond control. 5. Design Outline At this stage DFlow utilises the core aspects of TFRC, such as its rate based operation, utilisation of the TCP equation, and its smoother rate. It also utilises similar packet contents and signalling mechanisms. However as the design evolves we realise that DFlow may become quite separate from TFRC. O'Hanlon & Carlberg Expires January 10, 2013 [Page 6] Internet-Draft DFlow media congestion control July 2012 5.1. Congestion Detection The delay-based detection algorithm operates by sampling the one-way delay (OWD) of each packet arrival by comparing the send timestamp with the receive time. The OWD is sampled over a small set time period, sample_period, (typically 100ms) and the minima stored as the BaseDelay over a longer period, base_period, (typically 5-10xRTT). The current OWD is then compared to the BaseDelay and if it exceeds a set threshold, CDthresh, (typically around 50ms) then the packet is considered for the next stage of detection. The following test is based upon the gradient of the delay change over two sample_periods, indicating that delay is on the increase, if it is positive then a 'congestion event' is logged. The minima of the OWDs are used to reduce noise of the measurements, which is beneficial in the case of variable link types such as Wifi. If ((BaseDelayMinNxRTT - OWD) > CDthresh AND DelayIncreaseOver2RTTs > 0) DelayCongestionEvent = True Figure 1 This algorithm then provides input to the 'congestion interval history' (or TFRC's 'loss interval history') mechanism, which is combined with normal input from the TFRC packet loss detection mechanisms, from which a 'congestion event rate' is derived which is then fed into the TCP equation to determine the send rate. Note that we disable TFRC's oscillation reduction mechanism from Section 4.5 [RFC5348] as it adversely affects the delay-based operation. We have performed some simulations of the above mechanism in operation and have found it to be reasonable fair to itself, though it is not as smooth as TFRC. 6. Further Work The design is still under development and there is clearly more work to be done. But we are seeking feeback on these ideas and future directions. 7. IANA Considerations This document makes no requests of IANA. O'Hanlon & Carlberg Expires January 10, 2013 [Page 7] Internet-Draft DFlow media congestion control July 2012 8. Security Considerations With a congestion control algorithm an attacker can attempt to interfere with the protocol to cause rate changes. However encryption of the protocol will protect it against such threats. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2007. [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008. 9.2. Informative References [ITU.G114.2003] International Telecommunications Union, "One-way transmission time", ITU-T Recommendation G.707, May 2003. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. Authors' Addresses Piers O'Hanlon University of Oxford Oxford Internet Institute 1 St Giles Oxford OX1 3JS United Kingdom Email: piers.ohanlon@oii.ox.ac.uk O'Hanlon & Carlberg Expires January 10, 2013 [Page 8] Internet-Draft DFlow media congestion control July 2012 Ken Carlberg G11 1600 Clarendon Blvd Arlington VA USA Email: carlberg@g11.org.uk O'Hanlon & Carlberg Expires January 10, 2013 [Page 9]