--- 1/draft-ietf-rmcat-cc-requirements-08.txt 2014-12-12 02:15:14.577839896 -0800 +++ 2/draft-ietf-rmcat-cc-requirements-09.txt 2014-12-12 02:15:14.605840587 -0800 @@ -1,19 +1,19 @@ Network Working Group R. Jesup Internet-Draft Mozilla Intended status: Informational Z. Sarker, Ed. -Expires: May 15, 2015 Ericsson - November 11, 2014 +Expires: June 15, 2015 Ericsson + December 12, 2014 Congestion Control Requirements for Interactive Real-Time Media - draft-ietf-rmcat-cc-requirements-08 + draft-ietf-rmcat-cc-requirements-09 Abstract Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like Web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g. with the introduction @@ -43,21 +43,21 @@ 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 May 15, 2015. + This Internet-Draft will expire on June 15, 2015. Copyright Notice Copyright (c) 2014 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 @@ -135,59 +135,62 @@ 2. Requirements 1. The congestion control algorithm must attempt to provide as-low- as-possible-delay transit for interactive real-time traffic while still providing a useful amount of bandwidth. There may be lower limits on the amount of bandwidth that is useful, but this is largely application-specific and the application may be able to modify or remove flows in order allow some useful flows to get enough bandwidth. (Example: not enough bandwidth for low-latency video+audio, but enough for audio-only.) - A. Jitter (variation in the bitrate over short timescales) also - is relevant, though moderate amounts of jitter will be + A. Jitter (variation in the bitrate over short time scales) + also is relevant, though moderate amounts of jitter will be absorbed by jitter buffers. Transit delay should be considered to track the short-term maximums of delay including jitter. B. It should provide this as-low-as-possible-delay transit and minimize self-induced latency even when faced with intermediate bottlenecks and competing flows. Competing flows may limit what's possible to achieve. - C. It should handle the effect of routing changes which may - alter or remove bottlenecks or change the bandwidth - available especially if there is a reduction in available - bandwidth or increase in observed delay. It is expected - that the mechanism reacts quickly to the routing change - events to avoid delay buildup. In the context of this memo, - a 'quick' reaction is on the order of a few RTTs, subject to - the constraints of the media codec, but is likely within a - second. Reaction on the next RTT is explicitly not + C. It should be resilience to the effects of the events, such + as routing changes, which may alter or remove bottlenecks or + change the bandwidth available especially if there is a + reduction in available bandwidth or increase in observed + delay. It is expected that the mechanism reacts quickly to + the such events to avoid delay buildup. In the context of + this memo, a 'quick' reaction is on the order of a few RTTs, + subject to the constraints of the media codec, but is likely + within a second. Reaction on the next RTT is explicitly not required, since many codecs cannot adapt their sending rate that quickly, but equally response cannot be arbitrarily delayed. D. It should react quickly to handle both local and remote interface changes (WLAN to 3G data, etc) which may radically change the bandwidth available or bottlenecks, especially if there is a reduction in available bandwidth or increase in bottleneck delay. It is assumed that an interface change can generate a notification to the algorithm. - E. The algorithm must consider the case where offered loads are - less than the available bandwidth at any given moment, and - may vary dramatically over time, including dropping to no - load and then resuming a high load, such as in a mute/unmute - operation. Note that the reaction time between a change in - the bandwidth available from the algorithm and a change in - the offered load is variable, and may be different when - increasing versus decreasing. + E. The real-time interactive media applications can be rate + limited. This means the offered loads can be less than the + available bandwidth at any given moment, and may vary + dramatically over time, including dropping to no load and + then resuming a high load, such as in a mute/unmute + operation. Hence, the algorithm must be designed to handle + such behavior from media source or application. Note that + the reaction time between a change in the bandwidth + available from the algorithm and a change in the offered + load is variable, and may be different when increasing + versus decreasing. F. The algorithm requires to avoid building up queues when competing with short-term bursts of traffic (for example, traffic generated by web-browsing) which can quickly saturate a local-bottleneck router or link, but also clear quickly. The algorithm should also react quickly to regain its previous share of the bandwidth when the local- bottleneck or link is cleared. G. Similarly periodic bursty flows such as MPEG DASH @@ -423,39 +426,40 @@ An attacker with the ability to delete, delay or insert messages in the flow can fake congestion signals, unless they are passed on a tamper-proof path. Since some possible algorithms depend on the timing of packet arrival, even a traditional protected channel does not fully mitigate such attacks. An attack that reduces bandwidth is not necessarily significant, since an on-path attacker could break the connection by discarding all packets. Attacks that increase the perceived available bandwidth - are conceivable, and need to be evaluated. + are conceivable, and need to be evaluated. Such attacks could result + in starvation of competing flows and permit amplification attacks. Algorithm designers should consider the possibility of malicious on- path attackers. 6. Acknowledgements This document is the result of discussions in various fora of the WebRTC effort, in particular on the rtp-congestion@alvestrand.no mailing list. Many people contributed their thoughts to this. 7. References 7.1. Normative References [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for - Browser-based Applications", draft-ietf-rtcweb-overview-12 - (work in progress), October 2014. + Browser-based Applications", draft-ietf-rtcweb-overview-13 + (work in progress), November 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control @@ -468,22 +472,22 @@ 7.2. Informative References [CH09] Choi, S. and M. Handley, "Designing TCP-Friendly Window- based Congestion Control for Real-time Multimedia Applications", PFLDNeT 2009 Workshop , May 2009. [I-D.ietf-avtcore-rtp-circuit-breakers] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", draft-ietf- - avtcore-rtp-circuit-breakers-07 (work in progress), - October 2014. + avtcore-rtp-circuit-breakers-08 (work in progress), + December 2014. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-12 (work in progress), September 2014. [MPEG_DASH] "Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats", April 2012.