draft-ietf-rmcat-cc-codec-interactions-01.txt   draft-ietf-rmcat-cc-codec-interactions-02.txt 
Network Working Group M. Zanaty Network Working Group M. Zanaty
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track V. Singh Intended status: Standards Track V. Singh
Expires: April 20, 2016 Aalto University Expires: September 19, 2016 Aalto University
S. Nandakumar S. Nandakumar
Cisco Cisco
Z. Sarkar Z. Sarkar
Ericsson AB Ericsson AB
October 18, 2015 March 18, 2016
Congestion Control and Codec interactions in RTP Applications Congestion Control and Codec interactions in RTP Applications
draft-ietf-rmcat-cc-codec-interactions-01 draft-ietf-rmcat-cc-codec-interactions-02
Abstract Abstract
Interactive real-time media applications that use the Real-time Interactive real-time media applications that use the Real-time
Transport Protocol (RTP) over the User Datagram Protocol (UDP) must Transport Protocol (RTP) over the User Datagram Protocol (UDP) must
use congestion control techniques above the UDP layer since it use congestion control techniques above the UDP layer since it
provides none. This memo describes the interactions and conceptual provides none. This memo describes the interactions and conceptual
interfaces necessary between the application components that relate interfaces necessary between the application components that relate
to congestion control, specifically the media codec control layer, to congestion control, specifically the media codec control layer,
and the components dedicated to congestion control functions. and the components dedicated to congestion control functions.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 April 20, 2016. This Internet-Draft will expire on September 19, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 28 skipping to change at page 2, line 28
5. Codec - CC Interactions . . . . . . . . . . . . . . . . . . . 6 5. Codec - CC Interactions . . . . . . . . . . . . . . . . . . . 6
5.1. Mandatory Interactions . . . . . . . . . . . . . . . . . 6 5.1. Mandatory Interactions . . . . . . . . . . . . . . . . . 6
5.1.1. Allowed Rate . . . . . . . . . . . . . . . . . . . . 6 5.1.1. Allowed Rate . . . . . . . . . . . . . . . . . . . . 6
5.2. Optional Interactions . . . . . . . . . . . . . . . . . . 7 5.2. Optional Interactions . . . . . . . . . . . . . . . . . . 7
5.2.1. Media Elasticity . . . . . . . . . . . . . . . . . . 7 5.2.1. Media Elasticity . . . . . . . . . . . . . . . . . . 7
5.2.2. Startup Ramp . . . . . . . . . . . . . . . . . . . . 7 5.2.2. Startup Ramp . . . . . . . . . . . . . . . . . . . . 7
5.2.3. Delay Tolerance . . . . . . . . . . . . . . . . . . . 8 5.2.3. Delay Tolerance . . . . . . . . . . . . . . . . . . . 8
5.2.4. Loss Tolerance . . . . . . . . . . . . . . . . . . . 8 5.2.4. Loss Tolerance . . . . . . . . . . . . . . . . . . . 8
5.2.5. Forward Error Correction . . . . . . . . . . . . . . 8 5.2.5. Forward Error Correction . . . . . . . . . . . . . . 8
5.2.6. Probing for Available Bandwidth . . . . . . . . . . . 8 5.2.6. Probing for Available Bandwidth . . . . . . . . . . . 8
5.2.7. Throughput Sensitivity . . . . . . . . . . . . . . . 8 5.2.7. Throughput Sensitivity . . . . . . . . . . . . . . . 9
5.2.8. Rate Stability . . . . . . . . . . . . . . . . . . . 9 5.2.8. Rate Stability . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Interactive real-time media applications most commonly use RTP Interactive real-time media applications most commonly use RTP
[RFC3550] over UDP [RFC0768]. Since UDP provides no form of [RFC3550] over UDP [RFC0768]. Since UDP provides no form of
congestion control, which is essential for any application deployed congestion control, which is essential for any application deployed
on the Internet, these RTP applications have historically implemented on the Internet, these RTP applications have historically implemented
one of the following options at the application layer to address one of the following options at the application layer to address
their congestion control requirements. their congestion control requirements.
skipping to change at page 7, line 40 skipping to change at page 7, line 40
5.2.2. Startup Ramp 5.2.2. Startup Ramp
Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an
important moment in a conversation. Rapid rate adaptation during important moment in a conversation. Rapid rate adaptation during
startup is therefore important. The codec should minimize its startup is therefore important. The codec should minimize its
startup media rate as much as possible without adversely impacting startup media rate as much as possible without adversely impacting
the user experience, and support a strategy for rapid rate ramp. The the user experience, and support a strategy for rapid rate ramp. The
CC should allow the highest startup media rate as possible without CC should allow the highest startup media rate as possible without
adversely impacting network conditions, and also support rapid rate adversely impacting network conditions, and also support rapid rate
ramp until stabilizing on the available bandwidth. Startup can be ramp until stabilizing on the available bandwidth. Startup can be
viewed as a negotiation between the codec and the CC. The codec viewed as a negotiation between the codec and the CC. The
requests a startup rate and ramp, and the CC responds with the specification of the ramp may take a number of forms depending on the
allowable parameters which may be lower/slower. The RMCAT interface to the codec; for example, a percentage bit rate increase
requirements also include the possibility of bandwidth history to per RTT (or other time interval), or an increased transmit window (in
further accelerate or even eliminate startup ramp time. While this number of packets and/or octets allowed outstanding) are all
is highly desirable from an application viewpoint, it may be less potential forms. The codec requests a startup rate and ramp, and the
acceptable to network operators, since it is in essence a gamble on CC responds with the allowable parameters which may be lower/slower.
current congestion state matching historical state, with the The RMCAT requirements also include the possibility of bandwidth
potential for significant congestion contribution if the gamble was history to further accelerate or even eliminate startup ramp time.
wrong. Note that startup can often commence before user interaction While this acceleration or elimination in ramp time is beneficial to
or conversation to reduce the chance of clipped media. the session user experience when bandwidth is sufficient, it can be
detrimental if significant congestion results (the user experience of
this session and all other sessions traversing the point of
congestion may unnecessarily degrade). Therefore, it is recommended
that use of potentially stale congestion state for acceleration or
elimination in ramp up be limited to topologies or deployments
believed to have sufficient bandwidth margin or those in which the
potential transient congestion risk is acceptable. Note that startup
can often commence before user interaction or conversation to reduce
the chance of clipped media.
5.2.3. Delay Tolerance 5.2.3. Delay Tolerance
Delay Tolerance (from Codec to CC): An ideal CC will always minimize Delay Tolerance (from Codec to CC): An ideal CC will always minimize
delay and target zero. However, real solutions often need a real delay and target zero. However, real solutions often need a real
non-zero delay tolerance. The codec should provide an absolute delay non-zero delay tolerance. The codec should provide an absolute delay
tolerance, perhaps expressed as an impairment factor to mix with tolerance, perhaps expressed as an impairment factor to mix with
other metrics. other metrics.
5.2.4. Loss Tolerance 5.2.4. Loss Tolerance
skipping to change at page 9, line 16 skipping to change at page 9, line 24
Rate Stability (from Codec to CC): The CC algorithm must strike a Rate Stability (from Codec to CC): The CC algorithm must strike a
balance between rate stability and fast reaction to changes in balance between rate stability and fast reaction to changes in
available bandwidth. The codec should provide its preference for available bandwidth. The codec should provide its preference for
rate stability versus fast and frequent reaction to rate changes, rate stability versus fast and frequent reaction to rate changes,
perhaps expressed as an impairment factor (for high rate variance perhaps expressed as an impairment factor (for high rate variance
over short timescales) to mix with other metrics. over short timescales) to mix with other metrics.
6. Acknowledgements 6. Acknowledgements
The RMCAT design team discussions contributed to this memo. The RMCAT design team discussions contributed to this memo. The
authors would also like to thank Michael Ramalho for reviewing and
suggesting text improvements.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.alvestrand-rmcat-remb] [I-D.alvestrand-rmcat-remb]
Alvestrand, H., "RTCP message for Receiver Estimated Alvestrand, H., "RTCP message for Receiver Estimated
Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in
progress), October 2013. progress), October 2013.
[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. Varun, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", draft-ietf- Circuit Breakers for Unicast RTP Sessions", draft-ietf-
avtcore-rtp-circuit-breakers-11 (work in progress), avtcore-rtp-circuit-breakers-14 (work in progress), March
October 2015. 2016.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-23 (work in progress), July 2015. negotiation-27 (work in progress), February 2016.
[I-D.ietf-rmcat-cc-requirements] [I-D.ietf-rmcat-cc-requirements]
Jesup, R. and Z. Sarker, "Congestion Control Requirements Jesup, R. and Z. Sarker, "Congestion Control Requirements
for Interactive Real-Time Media", draft-ietf-rmcat-cc- for Interactive Real-Time Media", draft-ietf-rmcat-cc-
requirements-09 (work in progress), December 2014. requirements-09 (work in progress), December 2014.
[I-D.welzl-rmcat-coupled-cc] [I-D.welzl-rmcat-coupled-cc]
Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion
control for RTP media", draft-welzl-rmcat-coupled-cc-05 control for RTP media", draft-welzl-rmcat-coupled-cc-05
(work in progress), June 2015. (work in progress), June 2015.
 End of changes. 12 change blocks. 
23 lines changed or deleted 34 lines changed or added

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