draft-ietf-rmcat-cc-requirements-08.txt   draft-ietf-rmcat-cc-requirements-09.txt 
Network Working Group R. Jesup Network Working Group R. Jesup
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Informational Z. Sarker, Ed. Intended status: Informational Z. Sarker, Ed.
Expires: May 15, 2015 Ericsson Expires: June 15, 2015 Ericsson
November 11, 2014 December 12, 2014
Congestion Control Requirements for Interactive Real-Time Media Congestion Control Requirements for Interactive Real-Time Media
draft-ietf-rmcat-cc-requirements-08 draft-ietf-rmcat-cc-requirements-09
Abstract Abstract
Congestion control is needed for all data transported across the Congestion control is needed for all data transported across the
Internet, in order to promote fair usage and prevent congestion Internet, in order to promote fair usage and prevent congestion
collapse. The requirements for interactive, point-to-point real-time collapse. The requirements for interactive, point-to-point real-time
multimedia, which needs low-delay, semi-reliable data delivery, are multimedia, which needs low-delay, semi-reliable data delivery, are
different from the requirements for bulk transfer like FTP or bursty different from the requirements for bulk transfer like FTP or bursty
transfers like Web pages. Due to an increasing amount of RTP-based transfers like Web pages. Due to an increasing amount of RTP-based
real-time media traffic on the Internet (e.g. with the introduction real-time media traffic on the Internet (e.g. with the introduction
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 4 skipping to change at page 4, line 4
2. Requirements 2. Requirements
1. The congestion control algorithm must attempt to provide as-low- 1. The congestion control algorithm must attempt to provide as-low-
as-possible-delay transit for interactive real-time traffic as-possible-delay transit for interactive real-time traffic
while still providing a useful amount of bandwidth. There may while still providing a useful amount of bandwidth. There may
be lower limits on the amount of bandwidth that is useful, but be lower limits on the amount of bandwidth that is useful, but
this is largely application-specific and the application may be this is largely application-specific and the application may be
able to modify or remove flows in order allow some useful flows able to modify or remove flows in order allow some useful flows
to get enough bandwidth. (Example: not enough bandwidth for to get enough bandwidth. (Example: not enough bandwidth for
low-latency video+audio, but enough for audio-only.) low-latency video+audio, but enough for audio-only.)
A. Jitter (variation in the bitrate over short timescales) also A. Jitter (variation in the bitrate over short time scales)
is relevant, though moderate amounts of jitter will be also is relevant, though moderate amounts of jitter will be
absorbed by jitter buffers. Transit delay should be absorbed by jitter buffers. Transit delay should be
considered to track the short-term maximums of delay considered to track the short-term maximums of delay
including jitter. including jitter.
B. It should provide this as-low-as-possible-delay transit and B. It should provide this as-low-as-possible-delay transit and
minimize self-induced latency even when faced with minimize self-induced latency even when faced with
intermediate bottlenecks and competing flows. Competing intermediate bottlenecks and competing flows. Competing
flows may limit what's possible to achieve. flows may limit what's possible to achieve.
C. It should handle the effect of routing changes which may C. It should be resilience to the effects of the events, such
alter or remove bottlenecks or change the bandwidth as routing changes, which may alter or remove bottlenecks or
available especially if there is a reduction in available change the bandwidth available especially if there is a
bandwidth or increase in observed delay. It is expected reduction in available bandwidth or increase in observed
that the mechanism reacts quickly to the routing change delay. It is expected that the mechanism reacts quickly to
events to avoid delay buildup. In the context of this memo, the such events to avoid delay buildup. In the context of
a 'quick' reaction is on the order of a few RTTs, subject to this memo, a 'quick' reaction is on the order of a few RTTs,
the constraints of the media codec, but is likely within a subject to the constraints of the media codec, but is likely
second. Reaction on the next RTT is explicitly not within a second. Reaction on the next RTT is explicitly not
required, since many codecs cannot adapt their sending rate required, since many codecs cannot adapt their sending rate
that quickly, but equally response cannot be arbitrarily that quickly, but equally response cannot be arbitrarily
delayed. delayed.
D. It should react quickly to handle both local and remote D. It should react quickly to handle both local and remote
interface changes (WLAN to 3G data, etc) which may radically interface changes (WLAN to 3G data, etc) which may radically
change the bandwidth available or bottlenecks, especially if change the bandwidth available or bottlenecks, especially if
there is a reduction in available bandwidth or increase in there is a reduction in available bandwidth or increase in
bottleneck delay. It is assumed that an interface change bottleneck delay. It is assumed that an interface change
can generate a notification to the algorithm. can generate a notification to the algorithm.
E. The algorithm must consider the case where offered loads are E. The real-time interactive media applications can be rate
less than the available bandwidth at any given moment, and limited. This means the offered loads can be less than the
may vary dramatically over time, including dropping to no available bandwidth at any given moment, and may vary
load and then resuming a high load, such as in a mute/unmute dramatically over time, including dropping to no load and
operation. Note that the reaction time between a change in then resuming a high load, such as in a mute/unmute
the bandwidth available from the algorithm and a change in operation. Hence, the algorithm must be designed to handle
the offered load is variable, and may be different when such behavior from media source or application. Note that
increasing versus decreasing. 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 F. The algorithm requires to avoid building up queues when
competing with short-term bursts of traffic (for example, competing with short-term bursts of traffic (for example,
traffic generated by web-browsing) which can quickly traffic generated by web-browsing) which can quickly
saturate a local-bottleneck router or link, but also clear saturate a local-bottleneck router or link, but also clear
quickly. The algorithm should also react quickly to regain quickly. The algorithm should also react quickly to regain
its previous share of the bandwidth when the local- its previous share of the bandwidth when the local-
bottleneck or link is cleared. bottleneck or link is cleared.
G. Similarly periodic bursty flows such as MPEG DASH G. Similarly periodic bursty flows such as MPEG DASH
skipping to change at page 6, line 41 skipping to change at page 6, line 44
and fairer sharing of bandwidth with other network users. and fairer sharing of bandwidth with other network users.
A. The algorithm should also share information and adaptation A. The algorithm should also share information and adaptation
with other non-RTP flows between the same endpoints, such as with other non-RTP flows between the same endpoints, such as
a WebRTC DataChannel [I-D.ietf-rtcweb-data-channel], when a WebRTC DataChannel [I-D.ietf-rtcweb-data-channel], when
possible. possible.
B. When there are multiple streams across the same 5-tuple B. When there are multiple streams across the same 5-tuple
coordinating their bandwidth use and congestion control, the coordinating their bandwidth use and congestion control, the
algorithm should allow the application to control the algorithm should allow the application to control the
relative split of available bandwidth.The most correlated relative split of available bandwidth. The most correlated
bandwidth usage would be with other flows on the same bandwidth usage would be with other flows on the same
5-tuple, but there may be use in coordinating measurement 5-tuple, but there may be use in coordinating measurement
and control of the local link(s). Use of information about and control of the local link(s). Use of information about
previous flows, especially on the same 5-tuple, may be previous flows, especially on the same 5-tuple, may be
useful input to the algorithm, especially to startup useful input to the algorithm, especially to startup
performance of a new flow. performance of a new flow.
7. The algorithm should not require any special support from 7. The algorithm should not require any special support from
network elements to convey congestion related information to be network elements to convey congestion related information to be
functional. As much as possible, it should leverage available functional. As much as possible, it should leverage available
skipping to change at page 10, line 5 skipping to change at page 10, line 8
An attacker with the ability to delete, delay or insert messages in An attacker with the ability to delete, delay or insert messages in
the flow can fake congestion signals, unless they are passed on a the flow can fake congestion signals, unless they are passed on a
tamper-proof path. Since some possible algorithms depend on the tamper-proof path. Since some possible algorithms depend on the
timing of packet arrival, even a traditional protected channel does timing of packet arrival, even a traditional protected channel does
not fully mitigate such attacks. not fully mitigate such attacks.
An attack that reduces bandwidth is not necessarily significant, An attack that reduces bandwidth is not necessarily significant,
since an on-path attacker could break the connection by discarding since an on-path attacker could break the connection by discarding
all packets. Attacks that increase the perceived available bandwidth 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- Algorithm designers should consider the possibility of malicious on-
path attackers. path attackers.
6. Acknowledgements 6. Acknowledgements
This document is the result of discussions in various fora of the This document is the result of discussions in various fora of the
WebRTC effort, in particular on the rtp-congestion@alvestrand.no WebRTC effort, in particular on the rtp-congestion@alvestrand.no
mailing list. Many people contributed their thoughts to this. mailing list. Many people contributed their thoughts to this.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-12 Browser-based Applications", draft-ietf-rtcweb-overview-13
(work in progress), October 2014. (work in progress), November 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
skipping to change at page 10, line 50 skipping to change at page 11, line 8
7.2. Informative References 7.2. Informative References
[CH09] Choi, S. and M. Handley, "Designing TCP-Friendly Window- [CH09] Choi, S. and M. Handley, "Designing TCP-Friendly Window-
based Congestion Control for Real-time Multimedia based Congestion Control for Real-time Multimedia
Applications", PFLDNeT 2009 Workshop , May 2009. Applications", PFLDNeT 2009 Workshop , May 2009.
[I-D.ietf-avtcore-rtp-circuit-breakers] [I-D.ietf-avtcore-rtp-circuit-breakers]
Perkins, C. and V. Singh, "Multimedia Congestion Control: Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", draft-ietf- Circuit Breakers for Unicast RTP Sessions", draft-ietf-
avtcore-rtp-circuit-breakers-07 (work in progress), avtcore-rtp-circuit-breakers-08 (work in progress),
October 2014. December 2014.
[I-D.ietf-rtcweb-data-channel] [I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-12 (work in Channels", draft-ietf-rtcweb-data-channel-12 (work in
progress), September 2014. progress), September 2014.
[MPEG_DASH] [MPEG_DASH]
"Dynamic adaptive streaming over HTTP (DASH) -- Part 1: "Dynamic adaptive streaming over HTTP (DASH) -- Part 1:
Media presentation description and segment formats", April Media presentation description and segment formats", April
2012. 2012.
 End of changes. 10 change blocks. 
29 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/