draft-ietf-rmcat-app-interaction-00.txt   draft-ietf-rmcat-app-interaction-01.txt 
RMCAT WG M. Zanaty RMCAT WG M. Zanaty
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational V. Singh Intended status: Informational V. Singh
Expires: February 8, 2015 Aalto University Expires: April 30, 2015 Aalto University
S. Nandakumar S. Nandakumar
Cisco Cisco
Z. Sarker Z. Sarker
Ericsson AB Ericsson AB
August 7, 2014 October 27, 2014
RTP Application Interaction with Congestion Control RTP Application Interaction with Congestion Control
draft-ietf-rmcat-app-interaction-00 draft-ietf-rmcat-app-interaction-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, including the RTP layer, the higher-level to congestion control, including the RTP layer, the higher-level
media codec control layer, and the lower-level transport interface, media codec control layer, and the lower-level transport interface,
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 February 8, 2015. This Internet-Draft will expire on April 30, 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
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
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 . . . . . . . . . . . . . . . . . 4
3. Conceptual Model . . . . . . . . . . . . . . . . . . . . . . 4 3. Conceptual Model . . . . . . . . . . . . . . . . . . . . . . 4
4. Implementation Model . . . . . . . . . . . . . . . . . . . . 5 4. Implementation Model . . . . . . . . . . . . . . . . . . . . 5
5. Interfaces and Interactions . . . . . . . . . . . . . . . . . 6 5. Interfaces and Interactions . . . . . . . . . . . . . . . . . 6
5.1. Config - Codec Interactions . . . . . . . . . . . . . . . 6 5.1. Config - Codec Interactions . . . . . . . . . . . . . . . 7
5.2. Config - RTP/RTCP Interactions . . . . . . . . . . . . . 6 5.2. Config - RTP/RTCP Interactions . . . . . . . . . . . . . 7
5.3. Codec - RTP Interactions . . . . . . . . . . . . . . . . 6 5.3. Codec - RTP Interactions . . . . . . . . . . . . . . . . 8
5.4. Codec - CC Interactions . . . . . . . . . . . . . . . . . 7 5.4. Codec - CC Interactions . . . . . . . . . . . . . . . . . 8
5.5. RTP - CC Interactions . . . . . . . . . . . . . . . . . . 9 5.4.1. Allowed Rate . . . . . . . . . . . . . . . . . . . . 8
5.6. CC - UDP Interactions . . . . . . . . . . . . . . . . . . 9 5.4.2. Media Elasticity . . . . . . . . . . . . . . . . . . 8
5.7. CC - Shared State Interactions . . . . . . . . . . . . . 10 5.4.3. Startup Ramp . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 5.4.4. Delay Tolerance . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5.4.5. Loss Tolerance . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5.4.6. Throughput Sensitivity . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4.7. Rate Stability . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 5.5. RTP - CC Interactions . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 12 5.6. CC - UDP Interactions . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 5.7. CC - Shared State Interactions . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 3, line 37 skipping to change at page 3, line 44
including routing or interface changes, stability without over- including routing or interface changes, stability without over-
reaction or oscillation, fair bandwidth sharing with other instances reaction or oscillation, fair bandwidth sharing with other instances
of itself and TCP flows, sharing information across multiple flows of itself and TCP flows, sharing information across multiple flows
when possible [I-D.welzl-rmcat-coupled-cc], and performing as well or when possible [I-D.welzl-rmcat-coupled-cc], and performing as well or
better in networks which support Active Queue Management (AQM), better in networks which support Active Queue Management (AQM),
Explicit Congestion Notification (ECN), or Differentiated Services Explicit Congestion Notification (ECN), or Differentiated Services
Code Points (DSCP). Code Points (DSCP).
In order to meet these requirements, interactions are necessary In order to meet these requirements, interactions are necessary
between the application's congestion controller, the RTP layer, media between the application's congestion controller, the RTP layer, media
codecs, other components, and the OS UDP stack. This memo discusses codecs, other components, and the underlying UDP/IP network stack.
these interactions, presents a conceptual model of the required This memo discusses these interactions, presents a conceptual model
interfaces based on a simplified application decomposition, and of the required interfaces based on a simplified application
proposes specific information exchange across these interfaces along decomposition, and proposes specific information exchange across
with corresponding component behavior. these interfaces along with corresponding component behavior.
Note that RTP can also operate over other transports with integrated Note that RTP can also operate over other transports with integrated
congestion control such as TCP [RFC5681] and DCCP [RFC4340], but that congestion control such as TCP [RFC5681] and DCCP [RFC4340], but that
is beyond the scope of RMCAT and this memo. is beyond the scope of RMCAT and this memo.
2. Key Words for Requirements 2. Key Words for Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 4, line 26 skipping to change at page 4, line 32
| | Codec | | | | Codec | |
| | | | | | | | | | | | | |
| APP +---RTP | RTCP---+ | | APP +---RTP | RTCP---+ |
| | | | | | | | | | | |
| | | | | | | | | | | |
| +---Congestion-------|---Shared | +---Congestion-------|---Shared
| Control | State | Control | State
+----------------------------+ +----------------------------+
| |
+----------------------------+ +----------------------------+
| OS UDP | | Network UDP |
| Stack | |
| IP |
+----------------------------+ +----------------------------+
Figure 1 Figure 1
o APP: Application containing one or more RTP streams and the o APP: Application containing one or more RTP streams and the
corresponding media codecs and congestion controllers. For corresponding media codecs and congestion controllers. For
example, a WebRTC browser. example, a WebRTC browser.
o Config: Configuration specified by the application that provides o Config: Configuration specified by the application that provides
the media and transport parameters, RTP and RTCP parameters and the media and transport parameters, RTP and RTCP parameters and
skipping to change at page 5, line 23 skipping to change at page 5, line 30
messages such as TMMBR [RFC5104], but excluding existing messages such as TMMBR [RFC5104], but excluding existing
extensions and possible new extensions specific to congestion extensions and possible new extensions specific to congestion
control (CC) such as REMB [I-D.alvestrand-rmcat-remb] (for control (CC) such as REMB [I-D.alvestrand-rmcat-remb] (for
receiver-side CC), ACK (for sender-side CC), absolute and/or receiver-side CC), ACK (for sender-side CC), absolute and/or
relative timestamps (for sender-side or receiver-side CC), etc. relative timestamps (for sender-side or receiver-side CC), etc.
o Congestion Control: All functions directly responsible for o Congestion Control: All functions directly responsible for
congestion control, including possible new RTP/RTCP extensions, congestion control, including possible new RTP/RTCP extensions,
send rate computation (for sender-side CC), receive rate send rate computation (for sender-side CC), receive rate
computation (for receiver-side CC), other statistics, and control computation (for receiver-side CC), other statistics, and control
of the UDP sockets including packet scheduling for traffic shaping of the UDP sockets including packet scheduling for traffic
/pacing. shaping/pacing.
o Shared State: Storage and exchange of congestion control state for o Shared State: Storage and exchange of congestion control state for
multiple flows within the application and beyond it. multiple flows within the application and beyond it.
o OS: Operating System containing the UDP socket interface and other o Network Stack: The platform's underlying network functions,
network functions such as ECN, DSCP, physical interface events, usually part of the Operating System (OS), containing the UDP
interface-level traffic shaping and packet scheduling, etc. socket interface and other network functions such as ECN, DSCP,
physical interface events, interface-level traffic shaping and
packet scheduling, etc. This is usually part of the Operating
System, often within the kernel; however, user-space network
stacks and components are also possible.
4. Implementation Model 4. Implementation Model
There are advantages and drawbacks to implementing congestion control There are advantages and drawbacks to implementing congestion control
in the application layer. It avoids OS dependencies and allows for in the application layer. It avoids platform dependencies and allows
rapid experimentation, evolution and optimization for each for rapid experimentation, evolution and optimization for each
application. However, it also puts the burden on all applications, application. However, it also puts the burden on all applications,
which raises the risks of improper or divergent implementations. One which raises the risks of improper or divergent implementations. One
motivation of this memo is to mitigate such risks by giving proper motivation of this memo is to mitigate such risks by giving proper
guidance on how the application components relating to congestion guidance on how the application components relating to congestion
control should interact. control should interact.
Another drawback of congestion control in the application layer is Another drawback of congestion control in the application layer is
that any decomposition, including the one presented in Figure 1, is that any decomposition, including the one presented in Figure 1, is
purely conceptual and illustrative, since implementations have purely conceptual and illustrative, since implementations have
differing designs and decompositions. Conversely, this can be viewed differing designs and decompositions. Conversely, this can be viewed
skipping to change at page 6, line 14 skipping to change at page 6, line 26
+----------------------------+ +----------------------------+
| +-----Config | | +-----Config |
| | | | | | | |
| | Codec | | | Codec |
| APP | | | | APP | | |
| +---RTP+RTCP+CC------|---Shared | +---RTP+RTCP+CC------|---Shared
+----------------------------+ State +----------------------------+ State
| |
+----------------------------+ +----------------------------+
| OS UDP | | Network UDP |
| Stack | |
| IP |
+----------------------------+ +----------------------------+
Figure 2 Figure 2
The conceptual model in Figure 1 will be used throughout this memo to The conceptual model in Figure 1 will be used throughout this memo to
establish clearer boundaries between functions. But actual establish clearer boundaries between functions. But actual
implementations may be closer to the looser model in [Singh12]. implementations may be closer to the looser model in Figure 2 and
[Singh12].
5. Interfaces and Interactions 5. Interfaces and Interactions
The following subsections describe the interfaces and interactions
between each of the interfaces in the conceptual model. Within each
subsection, the most important interfaces and interactions are listed
first. This overview provides an overall priority for all
subsections, listing the top 5 interactions that CC designers and
application developers must consider.
o Allowed Rate (CC-Codec): This is the critical interface to close
the feedback loop between sender and receiver, so codec output
adapts rapidly to receiver feedback. See Section 5.4.1 for
details.
o Startup Ramp (CC-Codec): Initial rate (or number of packets in
window-based CC proposals) and strategy for increasing the rate
(or window) during media startup, similar to TCP intial congestion
window and slow start. See Section 5.4.3 for details.
o Delay Tolerance (CC-Codec): See Section 5.4.4 for details.
o Loss Tolerance (CC-Codec): See Section 5.4.5 for details.
o Priority / Weight (Config-CC-UDP): If the application has multiple
media flows, and can configure relative priority or weight among
them, the config can interact with shared state if coupled CC is
used (Section 5.7), or interact directly with a CC designed with
intrinsic distributed weighted fairness such as NADA. Priority
can also interact with the underlying network stack if it supports
layer 2/3 prioritization (Section 5.6).
5.1. Config - Codec Interactions 5.1. Config - Codec Interactions
The primary interactions between the config and the codec that are The primary interactions between the config and the codec that are
relevant to congestion control are the multiplexing of media streams relevant to congestion control are the multiplexing of media streams
[I-D.ietf-mmusic-sdp-bundle-negotiation] and RTP/RTCP [RFC5761] on [I-D.ietf-mmusic-sdp-bundle-negotiation] and RTP/RTCP [RFC5761] on
the same UDP port. the same UDP port.
The config also establishes limits for the codec such as maximum bit The config also establishes limits for the codec such as maximum bit
rate and other codec-specific parameters. For example, a video codec rate and other codec-specific parameters. For example, a video codec
config often sets limits on maximum resolution and frame rate as well config often sets limits on maximum resolution and frame rate as well
as bit rate. as bit rate.
Editor To-do: The W3C WebRTC Working Group is discussing the Media
Constraints API and the Object RTC (ORTC) Capabilities API. Once
finalized, these may impact the Config-related interactions for
WebRTC applications. Potential interactions include application
priority of media streams and application control of bandwidth, FEC,
and other parameters affecting media quality.
5.2. Config - RTP/RTCP Interactions 5.2. Config - RTP/RTCP Interactions
The config establishes the negotiated RTP and RTCP attributes and The config establishes the negotiated RTP and RTCP attributes and
extensions such as Extended Reports (XR), reduced size [RFC5506], extensions such as Extended Reports (XR), reduced size [RFC5506],
codec control [RFC5104], transmission time [RFC5450], etc. codec control [RFC5104], transmission time [RFC5450], etc.
Editor To-do: The W3C WebRTC Working Group is discussing the Stats
API. Once finalized, this may impact the RTP/RTCP-related
interactions for WebRTC applications.
5.3. Codec - RTP Interactions 5.3. Codec - RTP Interactions
Packetization of codec frames into RTP packets can be an important Packetization of codec frames into RTP packets can be an important
interaction. Some network interfaces may benefit from small packet interaction. Some network interfaces may benefit from small packet
sizes well below the MTU, while others may benefit from large packets sizes well below the MTU, while others may benefit from large packets
approaching the MTU. Equalizing packet sizes of a frame may also be approaching the MTU. Equalizing packet sizes of a frame may also be
beneficial in some cases, rather than a combination of large and beneficial in some cases, rather than a combination of large and
small packets. For example, in some FEC schemes, the FEC bandwidth small packets. For example, in some FEC schemes, the FEC bandwidth
overhead depends on the largest source packet size. Equalizing the overhead depends on the largest source packet size. Equalizing the
source packet sizes can yield lower overhead than a combination of source packet sizes can yield lower overhead than a combination of
large and small packets. large and small packets.
5.4. Codec - CC Interactions 5.4. Codec - CC Interactions
5.4.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, for example, one second. The rate may be specified in use a default. The rate may be specified in bytes or packets or
bytes or packets or both. The rate must never exceed permanent both. The rate must never exceed permanent limits established in
limits established in session signaling such as the SDP bandwidth session signaling such as the SDP bandwidth attribute [RFC4566] nor
attribute [RFC4566] nor temporary limits in RTCP such as TMMBR temporary limits in RTCP such as TMMBR [RFC5104] or REMB
[RFC5104] or REMB [I-D.alvestrand-rmcat-remb]. This is the most [I-D.alvestrand-rmcat-remb]. This is the most important interface
important interface among all components, and is always required in among all components, and is always required in any RMCAT solution.
any RMCAT solution. In the simplest possible solution, it may be the In the simplest possible solution, it may be the only CC interface
only CC interface required. required.
5.4.2. 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.4.3. 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
requests a startup rate and ramp, and the CC responds with the requests a startup rate and ramp, and the CC responds with the
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.4. 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.4.5. 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.
Throughput Sensitivity (from Codec to CC): An ideal CC will always
maximize throughput. However, real solutions often need a trade-off
between throughput and other metrics such as delay or loss. The
codec should provide throughput sensitivity, perhaps expressed as an
impairment factor (for low throughputs) to mix with other metrics.
Rate Stability (from Codec to CC): The CC algorithm must strike a
balance between rate stability and fast reaction to changes in
available bandwidth. The codec should provide its preference for
rate stability versus fast and frequent reaction to rate changes,
perhaps expressed as an impairment factor (for high rate variance
over short timescales) to mix with other metrics.
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.
skipping to change at page 9, line 7 skipping to change at page 10, line 11
Probing for Available Bandwidth: FEC can also be used to probe for Probing for Available Bandwidth: FEC can also be used to probe for
additional available bandwidth, if the application desires a higher additional available bandwidth, if the application desires a higher
target rate than the current rate. FEC is preferable to synthetic target rate than the current rate. FEC is preferable to synthetic
probes since any contribution to congestion by the FEC probe will not probes since any contribution to congestion by the FEC probe will not
impact the post-repair loss rate of the source media flow while impact the post-repair loss rate of the source media flow while
synthetic probes may adversely affect the loss rate [Nagy14]. Note synthetic probes may adversely affect the loss rate [Nagy14]. Note
that any use of FEC or retransmission must ensure that the total flow that any use of FEC or retransmission must ensure that the total flow
of all packets including FEC, retransmission and original media never of all packets including FEC, retransmission and original media never
exceeds the Allowed Rate. exceeds the Allowed Rate.
5.4.6. Throughput Sensitivity
Throughput Sensitivity (from Codec to CC): An ideal CC will always
maximize throughput. However, real solutions often need a trade-off
between throughput and other metrics such as delay or loss. The
codec should provide throughput sensitivity, perhaps expressed as an
impairment factor (for low throughputs) to mix with other metrics.
5.4.7. Rate Stability
Rate Stability (from Codec to CC): The CC algorithm must strike a
balance between rate stability and fast reaction to changes in
available bandwidth. The codec should provide its preference for
rate stability versus fast and frequent reaction to rate changes,
perhaps expressed as an impairment factor (for high rate variance
over short timescales) to mix with other metrics.
5.5. RTP - CC Interactions 5.5. RTP - CC Interactions
RTP Circuit Breakers: The intent behind RTP circuit breakers RTP Circuit Breakers: The intent behind RTP circuit breakers
[I-D.ietf-avtcore-rtp-circuit-breakers] is to provide a kill switch [I-D.ietf-avtcore-rtp-circuit-breakers] is to provide a kill switch
of last resort, not true congestion control. The breakers should of last resort, not true congestion control. The breakers should
never trip when an effective congestion control is operating. This never trip when an effective congestion control is operating. This
may impose some boundaries on RMCAT solutions to ensure the may impose some boundaries on RMCAT solutions to ensure the
congestion control never approaches situations which may trigger the congestion control never approaches situations which may trigger the
breakers. breakers.
skipping to change at page 9, line 41 skipping to change at page 11, line 18
transmission of packets to equalize inter-packet time intervals, transmission of packets to equalize inter-packet time intervals,
assuming the bottleneck is most sensitive to packet rate. More assuming the bottleneck is most sensitive to packet rate. More
complex pacing strategies may go beyond simple even distribution of complex pacing strategies may go beyond simple even distribution of
transmission times. For example, Sprout [Winstein13] attempts to transmission times. For example, Sprout [Winstein13] attempts to
predict the optimal transmission time (and rate) with the highest predict the optimal transmission time (and rate) with the highest
probability of success for each packet based on channel statistics. probability of success for each packet based on channel statistics.
Pacing may be always on, or adaptively enabled / disabled based on Pacing may be always on, or adaptively enabled / disabled based on
congestion state to minimize delay. Pacing may be performed within congestion state to minimize delay. Pacing may be performed within
the CC for a single flow or across multiple flows. It may also be the CC for a single flow or across multiple flows. It may also be
performed across all or selective traffic over the network interface performed across all or selective traffic over the network interface
if the OS supports interface-level traffic shaping. if the network stack supports interface-level traffic shaping.
Detection of Transport Capabilities: The CC can query the OS for Detection of Transport Capabilities: The CC can query the network
useful transport capabilities such as ECN, DSCP, traffic shaping, stack for useful transport capabilities such as ECN, DSCP, traffic
etc. This may also aid upper layers in making better decisions such shaping, etc. This may also aid upper layers in making better
as whether or not to multiplex media streams. For example, if audio decisions such as whether or not to multiplex media streams. For
can be given differentiated network treatment from video when using example, if audio can be given differentiated network treatment from
separate ports. video when using separate ports.
ECN: If the OS and transport path support ECN, the CC can react ECN: If the network stack and transport path support ECN, the CC can
faster than a loss-based CC and more reliably to congestion onset and react faster than a loss-based CC and more reliably to congestion
abatement. onset and abatement.
DSCP: If the OS and transport path support DSCP, the CC can map per- DSCP: If the network stack and transport path support DSCP, the CC
packet priority from RTP header extensions to DSCP (and layer 2 QoS can map per-packet priority from RTP header extensions to DSCP (and
if available) for better network handling under congestion. layer 2 QoS if available) for better network handling under
congestion.
AQM: If AQM is present in the bottleneck, and working effectively, AQM: If AQM is present in the bottleneck, and working effectively,
there should be little or no excess delay observed when varying the there should be little or no excess delay observed when varying the
transmission rate. The loss of such delay signals may hinder the transmission rate. The loss of such delay signals may hinder the
performance of congestion control algorithms that are highly performance of congestion control algorithms that are highly
dependent on delay variation for adapting transmission rate. If the dependent on delay variation for adapting transmission rate. If the
application has knowledge of the presence of AQM, through any means application has knowledge of the presence of AQM, through any means
which are beyond the scope of this memo, it should communicate this which are beyond the scope of this memo, it should communicate this
to the CC. The CC may use this to alter its signal collection and to the CC. The CC may use this to alter its signal collection and
rate adaptation strategies. The CC must not rely solely on this as a rate adaptation strategies. The CC must not rely solely on this as a
skipping to change at page 11, line 26 skipping to change at page 13, line 8
9.1. Normative References 9.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-05 (work in progress), avtcore-rtp-circuit-breakers-06 (work in progress), July
February 2014. 2014.
[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,
"Multiplexing Negotiation Using Session Description "Negotiating Media Multiplexing Using the Session
Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
bundle-negotiation-05 (work in progress), October 2013. negotiation-12 (work in progress), October 2014.
[I-D.ietf-rmcat-cc-requirements] [I-D.ietf-rmcat-cc-requirements]
Jesup, R., "Congestion Control Requirements For RMCAT", Jesup, R., "Congestion Control Requirements For RMCAT",
draft-ietf-rmcat-cc-requirements-02 (work in progress), draft-ietf-rmcat-cc-requirements-06 (work in progress),
February 2014. October 2014.
[I-D.ietf-rmcat-eval-criteria] [I-D.ietf-rmcat-eval-criteria]
Singh, V. and J. Ott, "Evaluating Congestion Control for Singh, V. and J. Ott, "Evaluating Congestion Control for
Interactive Real-time Media", draft-ietf-rmcat-eval- Interactive Real-time Media", draft-ietf-rmcat-eval-
criteria-00 (work in progress), January 2014. criteria-02 (work in progress), July 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-02 control for RTP media", draft-welzl-rmcat-coupled-cc-04
(work in progress), October 2013. (work in progress), October 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.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
skipping to change at page 13, line 21 skipping to change at page 15, line 6
[RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T.,
and L. Minder, "RaptorQ Forward Error Correction Scheme and L. Minder, "RaptorQ Forward Error Correction Scheme
for Object Delivery", RFC 6330, August 2011. for Object Delivery", RFC 6330, August 2011.
[RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K.
Matsuzono, "Simple Reed-Solomon Forward Error Correction Matsuzono, "Simple Reed-Solomon Forward Error Correction
(FEC) Scheme for FECFRAME", RFC 6865, February 2013. (FEC) Scheme for FECFRAME", RFC 6865, February 2013.
[Singh12] Singh, V., Ott, J., and C. Perkins, "Congestion Control [Singh12] Singh, V., Ott, J., and C. Perkins, "Congestion Control
for Interactive Media: Control Loops & APIs", Proc. of IAB for Interactive Media: Control Loops & APIs", Proc. of
/IRTF Workshop on Congestion Control for Interactive RTC , IAB/IRTF Workshop on Congestion Control for Interactive
7 2012. RTC , 7 2012.
[Winstein13] [Winstein13]
Winstein,, K., Sivaraman,, A., and H. Balakrishnan, Winstein,, K., Sivaraman,, A., and H. Balakrishnan,
"Stochastic Forecasts Achieve High Throughput and Low "Stochastic Forecasts Achieve High Throughput and Low
Delay over Cellular Networks", Proc. of the 10th USENIX Delay over Cellular Networks", Proc. of the 10th USENIX
Symposium on Networked Systems Design and Implementation , Symposium on Networked Systems Design and Implementation ,
4 2013. 4 2013.
Authors' Addresses Authors' Addresses
 End of changes. 33 change blocks. 
81 lines changed or deleted 152 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/