draft-ietf-rmcat-cc-codec-interactions-00.txt   draft-ietf-rmcat-cc-codec-interactions-01.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: March 20, 2016 Aalto University Expires: April 20, 2016 Aalto University
S. Nandakumar S. Nandakumar
Cisco Cisco
Z. Sarkar Z. Sarkar
Ericsson AB Ericsson AB
September 17, 2015 October 18, 2015
Congestion Control and Codec interactions in RTP Applications Congestion Control and Codec interactions in RTP Applications
draft-ietf-rmcat-cc-codec-interactions-00 draft-ietf-rmcat-cc-codec-interactions-01
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 March 20, 2016. This Internet-Draft will expire on April 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 2, line 19 skipping to change at page 2, line 19
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Key Words for Requirements . . . . . . . . . . . . . . . . . 3 2. Key Words for Requirements . . . . . . . . . . . . . . . . . 3
3. Conceptual Model . . . . . . . . . . . . . . . . . . . . . . 4 3. Conceptual Model . . . . . . . . . . . . . . . . . . . . . . 4
4. Implementation Model . . . . . . . . . . . . . . . . . . . . 5 4. Implementation Model . . . . . . . . . . . . . . . . . . . . 5
5. Codec - CC Interactions . . . . . . . . . . . . . . . . . . . 6 5. Codec - CC Interactions . . . . . . . . . . . . . . . . . . . 6
5.1. Allowed Rate . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Mandatory Interactions . . . . . . . . . . . . . . . . . 6
5.2. Media Elasticity . . . . . . . . . . . . . . . . . . . . 7 5.1.1. Allowed Rate . . . . . . . . . . . . . . . . . . . . 6
5.3. Startup Ramp . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Optional Interactions . . . . . . . . . . . . . . . . . . 7
5.4. Delay Tolerance . . . . . . . . . . . . . . . . . . . . . 7 5.2.1. Media Elasticity . . . . . . . . . . . . . . . . . . 7
5.5. Loss Tolerance . . . . . . . . . . . . . . . . . . . . . 8 5.2.2. Startup Ramp . . . . . . . . . . . . . . . . . . . . 7
5.6. Forward Error Correction . . . . . . . . . . . . . . . . 8 5.2.3. Delay Tolerance . . . . . . . . . . . . . . . . . . . 8
5.7. Probing for Available Bandwidth . . . . . . . . . . . . . 8 5.2.4. Loss Tolerance . . . . . . . . . . . . . . . . . . . 8
5.8. Throughput Sensitivity . . . . . . . . . . . . . . . . . 8 5.2.5. Forward Error Correction . . . . . . . . . . . . . . 8
5.9. Rate Stability . . . . . . . . . . . . . . . . . . . . . 8 5.2.6. Probing for Available Bandwidth . . . . . . . . . . . 8
5.2.7. Throughput Sensitivity . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Interactive real-time media applications most commonly use RTP Interactive real-time media applications most commonly use RTP
skipping to change at page 6, line 34 skipping to change at page 6, line 34
| Network UDP | | Network UDP |
| Stack | | | Stack | |
| IP | | IP |
+----------------------------+ +----------------------------+
Figure 2 Figure 2
5. Codec - CC Interactions 5. Codec - CC Interactions
The following subsections identify the necessary interactions between The following subsections identify the necessary interactions between
the Codec and congestion control layer interfaces that needs to be the Codec and congestion control (CC) layer interfaces that needs to
considered important be considered important.
5.1. Allowed Rate 5.1. Mandatory Interactions
5.1.1. Allowed Rate
Allowed Rate (from CC to Codec): The max transmit rate allowed over Allowed Rate (from CC to Codec): The max transmit rate allowed over
the next time interval. The time interval may be specified or may the next time interval. The time interval may be specified or may
use a default. The rate may be specified in bytes or packets or use a default. The rate may be specified in bytes or packets or
both. The rate must never exceed permanent limits established in both. The rate must never exceed permanent limits established in
session signaling such as the SDP bandwidth attribute [RFC4566] nor session signaling such as the SDP bandwidth attribute [RFC4566] nor
temporary limits in RTCP such as TMMBR [RFC5104] or REMB temporary limits in RTCP such as TMMBR [RFC5104] or REMB
[I-D.alvestrand-rmcat-remb]. This is the most important interface [I-D.alvestrand-rmcat-remb]. This is the most important interface
among all components, and is always required in any RMCAT solution. among all components, and is always required in any RMCAT solution.
In the simplest possible solution, it may be the only CC interface In the simplest possible solution, it may be the only CC interface
required. required.
5.2. Media Elasticity 5.2. Optional Interactions
This section identifies certain advanced interactions that if
implemented by an RMCAT solution shall provide more granular control
over the congestion control state and the encoder behavior. As of
today, these interactions are optional to implement and future
evaluations of the existing/upcoming codecs might result in
considering some or all of these as Mandatory interactions.
5.2.1. Media Elasticity
Media Elasticity (from Codec to CC): Many live media encoders are Media Elasticity (from Codec to CC): Many live media encoders are
highly elastic, often able to achieve any target bit rate within a highly elastic, often able to achieve any target bit rate within a
wide range, by adapting the media quality. For example, a video wide range, by adapting the media quality. For example, a video
encoder may support any bit rate within a range of a few tens or encoder may support any bit rate within a range of a few tens or
hundreds of kbps up to several Mbps, with rate changes registering as hundreds of kbps up to several Mbps, with rate changes registering as
fast as the next video frame, although there may be limitations in fast as the next video frame, although there may be limitations in
the frequency of changes. Other encoders may be less elastic, the frequency of changes. Other encoders may be less elastic,
supporting a narrower rate range, coarser granularity of rate steps, supporting a narrower rate range, coarser granularity of rate steps,
slower reaction to rate changes, etc. Other media, particularly some slower reaction to rate changes, etc. Other media, particularly some
audio codecs, may be fully inelastic with a single fixed rate. CC audio codecs, may be fully inelastic with a single fixed rate. CC
can beneficially use codec elasticity, if provided, to plan Allowed can beneficially use codec elasticity, if provided, to plan Allowed
Rate changes, especially when there are multiple flows sharing CC Rate changes, especially when there are multiple flows sharing CC
state and bandwidth. state and bandwidth.
5.3. 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 codec
skipping to change at page 7, line 43 skipping to change at page 8, line 5
allowable parameters which may be lower/slower. The RMCAT allowable parameters which may be lower/slower. The RMCAT
requirements also include the possibility of bandwidth history to requirements also include the possibility of bandwidth history to
further accelerate or even eliminate startup ramp time. While this further accelerate or even eliminate startup ramp time. While this
is highly desirable from an application viewpoint, it may be less is highly desirable from an application viewpoint, it may be less
acceptable to network operators, since it is in essence a gamble on acceptable to network operators, since it is in essence a gamble on
current congestion state matching historical state, with the current congestion state matching historical state, with the
potential for significant congestion contribution if the gamble was potential for significant congestion contribution if the gamble was
wrong. Note that startup can often commence before user interaction wrong. Note that startup can often commence before user interaction
or conversation to reduce the chance of clipped media. or conversation to reduce the chance of clipped media.
5.4. 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.5. Loss Tolerance 5.2.4. Loss Tolerance
Loss Tolerance (from Codec to CC): An ideal CC will always minimize Loss Tolerance (from Codec to CC): An ideal CC will always minimize
packet loss and target zero. However, real solutions often need a packet loss and target zero. However, real solutions often need a
real non-zero loss tolerance. The codec should provide an absolute real non-zero loss tolerance. The codec should provide an absolute
loss tolerance, perhaps expressed as an impairment factor to mix with loss tolerance, perhaps expressed as an impairment factor to mix with
other metrics. Note this is unrecoverable post-repair loss after other metrics. Note this is unrecoverable post-repair loss after
retransmission or forward error correction. retransmission or forward error correction.
5.6. Forward Error Correction 5.2.5. Forward Error Correction
Forward Error Correction (FEC): Simple FEC schemes like XOR Parity Forward Error Correction (FEC): Simple FEC schemes like XOR Parity
codes [RFC5109] may not handle consecutive or burst loss well. More codes [RFC5109] may not handle consecutive or burst loss well. More
complex FEC schemes like Reed-Solomon [RFC6865] or Raptor [RFC6330] complex FEC schemes like Reed-Solomon [RFC6865] or Raptor [RFC6330]
codes are more effective at handling bursty loss. The sensitivity to codes are more effective at handling bursty loss. The sensitivity to
packet loss therefore depends on the media (source) encoding as well packet loss therefore depends on the media (source) encoding as well
as the FEC (channel) encoding, and this sensitivity may differ for as the FEC (channel) encoding, and this sensitivity may differ for
different loss patterns like random, periodic, or consecutive loss. different loss patterns like random, periodic, or consecutive loss.
Expressing this sensitivity to the congestion controller may help it Expressing this sensitivity to the congestion controller may help it
choose the right balance between optimizing for throughput versus low choose the right balance between optimizing for throughput versus low
loss. loss.
5.7. Probing for Available Bandwidth 5.2.6. Probing for Available Bandwidth
FEC can also be used to probe for additional available bandwidth, if FEC can also be used to probe for additional available bandwidth, if
the application desires a higher target rate than the current rate. the application desires a higher target rate than the current rate.
FEC is preferable to synthetic probes since any contribution to FEC is preferable to synthetic probes since any contribution to
congestion by the FEC probe will not impact the post-repair loss rate congestion by the FEC probe will not impact the post-repair loss rate
of the source media flow while synthetic probes may adversely affect of the source media flow while synthetic probes may adversely affect
the loss rate. Note that any use of FEC or retransmission must the loss rate. Note that any use of FEC or retransmission must
ensure that the total flow of all packets including FEC, ensure that the total flow of all packets including FEC,
retransmission and original media never exceeds the Allowed Rate. retransmission and original media never exceeds the Allowed Rate.
5.8. Throughput Sensitivity 5.2.7. Throughput Sensitivity
Throughput Sensitivity (from Codec to CC): An ideal CC will always Throughput Sensitivity (from Codec to CC): An ideal CC will always
maximize throughput. However, real solutions often need a trade-off maximize throughput. However, real solutions often need a trade-off
between throughput and other metrics such as delay or loss. The between throughput and other metrics such as delay or loss. The
codec should provide throughput sensitivity, perhaps expressed as an codec should provide throughput sensitivity, perhaps expressed as an
impairment factor (for low throughputs) to mix with other metrics. impairment factor (for low throughputs) to mix with other metrics.
5.9. Rate Stability 5.2.8. Rate Stability
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
skipping to change at page 9, line 27 skipping to change at page 9, line 34
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. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", draft-ietf- Circuit Breakers for Unicast RTP Sessions", draft-ietf-
avtcore-rtp-circuit-breakers-10 (work in progress), March avtcore-rtp-circuit-breakers-11 (work in progress),
2015. October 2015.
[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-23 (work in progress), July 2015.
[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-
 End of changes. 16 change blocks. 
26 lines changed or deleted 39 lines changed or added

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