draft-ietf-rmcat-scream-cc-05.txt   draft-ietf-rmcat-scream-cc-06.txt 
RMCAT WG I. Johansson RMCAT WG I. Johansson
Internet-Draft Z. Sarker Internet-Draft Z. Sarker
Intended status: Experimental Ericsson AB Intended status: Experimental Ericsson AB
Expires: December 29, 2016 June 27, 2016 Expires: February 16, 2017 August 15, 2016
Self-Clocked Rate Adaptation for Multimedia Self-Clocked Rate Adaptation for Multimedia
draft-ietf-rmcat-scream-cc-05 draft-ietf-rmcat-scream-cc-06
Abstract Abstract
This memo describes a rate adaptation algorithm for conversational This memo describes a rate adaptation algorithm for conversational
media services such as video. The solution conforms to the packet media services such as video. The solution conforms to the packet
conservation principle and uses a hybrid loss and delay based conservation principle and uses a hybrid loss and delay based
congestion control algorithm. The algorithm is evaluated over both congestion control algorithm. The algorithm is evaluated over both
simulated Internet bottleneck scenarios as well as in a LTE (Long simulated Internet bottleneck scenarios as well as in a LTE (Long
Term Evolution) system simulator and is shown to achieve both low Term Evolution) system simulator and is shown to achieve both low
latency and high video throughput in these scenarios. latency and high video throughput in these scenarios.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 December 29, 2016. This Internet-Draft will expire on February 16, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
4.1.1. Constants and Parameter values . . . . . . . . . . . 9 4.1.1. Constants and Parameter values . . . . . . . . . . . 9
4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 9 4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 9
4.1.1.2. State variables . . . . . . . . . . . . . . . . . 10 4.1.1.2. State variables . . . . . . . . . . . . . . . . . 10
4.1.2. Network congestion control . . . . . . . . . . . . . 12 4.1.2. Network congestion control . . . . . . . . . . . . . 12
4.1.2.1. Congestion window update . . . . . . . . . . . . 15 4.1.2.1. Congestion window update . . . . . . . . . . . . 15
4.1.2.2. Competing flows compensation . . . . . . . . . . 17 4.1.2.2. Competing flows compensation . . . . . . . . . . 17
4.1.2.3. Lost packets detection . . . . . . . . . . . . . 19 4.1.2.3. Lost packets detection . . . . . . . . . . . . . 19
4.1.2.4. Send window calculation . . . . . . . . . . . . . 19 4.1.2.4. Send window calculation . . . . . . . . . . . . . 19
4.1.2.5. Resuming fast increase . . . . . . . . . . . . . 20 4.1.2.5. Resuming fast increase . . . . . . . . . . . . . 20
4.1.3. Media rate control . . . . . . . . . . . . . . . . . 20 4.1.3. Media rate control . . . . . . . . . . . . . . . . . 20
4.1.3.1. FEC and packet overhead considerations . . . . . 24 4.1.3.1. FEC and packet overhead considerations . . . . . 23
4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 24 4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 24
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 24 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Implementation status . . . . . . . . . . . . . . . . . . . . 25 6. Implementation status . . . . . . . . . . . . . . . . . . . . 24
6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 26 6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 25
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Change history . . . . . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 11. Change history . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Additional information . . . . . . . . . . . . . . . 30 Appendix A. Additional information . . . . . . . . . . . . . . . 30
A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 30 A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 30
A.2. Computation of autocorrelation function . . . . . . . . . 31 A.2. Computation of autocorrelation function . . . . . . . . . 31
A.3. Sender transmission control and packet pacing . . . . . . 31 A.3. Sender transmission control and packet pacing . . . . . . 31
A.4. RTCP feedback considerations . . . . . . . . . . . . . . 31 A.4. RTCP feedback considerations . . . . . . . . . . . . . . 31
A.4.1. Requirements on feedback elements . . . . . . . . . . 31 A.4.1. Requirements on feedback elements . . . . . . . . . . 32
A.4.2. Requirements on feedback intensity . . . . . . . . . 33 A.4.2. Requirements on feedback intensity . . . . . . . . . 34
A.5. Q-bit semantics (source quench) . . . . . . . . . . . . . 34 A.5. Q-bit semantics (source quench) . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Congestion in the Internet occurs when the transmitted bitrate is Congestion in the Internet occurs when the transmitted bitrate is
higher than the available bandwidth over a given transmission path. higher than the available bandwidth over a given transmission path.
Applications that are deployed in the Internet must have congestion Applications that are deployed in the Internet must have congestion
control schemes in place not only for the robustness of the service control schemes in place not only for the robustness of the service
that it provides but also to ensure the function of the currently that it provides but also to ensure the function of the currently
skipping to change at page 16, line 15 skipping to change at page 16, line 15
update_cwnd(bytes_newly_acked): update_cwnd(bytes_newly_acked):
# in fast increase ? # in fast increase ?
if (in_fast_increase) if (in_fast_increase)
if (qdelay_trend >= 0.2) if (qdelay_trend >= 0.2)
# incipient congestion detected, exit fast increase # incipient congestion detected, exit fast increase
in_fast_increase = false in_fast_increase = false
else else
# no congestion yet, increase cwnd if it # no congestion yet, increase cwnd if it
# is sufficiently used # is sufficiently used
if (bytes_in_flight*1.5 > cwnd) # an additional slack of bytes_newly_acked is
# added to ensure that CWND growth occurs
# even when feedback is sparse
if (bytes_in_flight*1.5+bytes_newly_acked > cwnd)
cwnd = cwnd+bytes_newly_acked cwnd = cwnd+bytes_newly_acked
end end
return return
end end
end end
# not in fast increase phase # not in fast increase phase
# off_target calculated as with LEDBAT # off_target calculated as with LEDBAT
off_target_t = (qdelay_target - qdelay) / qdelay_target off_target_t = (qdelay_target - qdelay) / qdelay_target
gain_t = GAIN gain_t = GAIN
# adjust congestion window # adjust congestion window
cwnd_delta_t = cwnd_delta_t =
gain_t * off_target_t * bytes_newly_acked * MSS / cwnd gain_t * off_target_t * bytes_newly_acked * MSS / cwnd
if (off_target_t > 0 && bytes_in_flight*1.25 <= cwnd) if (off_target_t > 0 && bytes_in_flight*1.25+bytes_newly_acked <= cwnd)
# no cwnd increase if window is underutilized # no cwnd increase if window is underutilized
# an additional slack of bytes_newly_acked is
# added to ensure that CWND growth occurs
# even when feedback is sparse
cwnd_delta_t = 0; cwnd_delta_t = 0;
end end
# apply delta # apply delta
cwnd += cwnd_delta_t cwnd += cwnd_delta_t
# limit cwnd to the maximum number of bytes in flight # limit cwnd to the maximum number of bytes in flight
cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM) cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM)
cwnd = max(cwnd, MIN_CWND) cwnd = max(cwnd, MIN_CWND)
CWND is updated differently depending on whether the congestion CWND is updated differently depending on whether the congestion
control is in fast increase state or not, as controlled by the control is in fast increase state or not, as controlled by the
variable in_fast_increase. variable in_fast_increase.
When in fast increase state, the congestion window is increased with When in fast increase state, the congestion window is increased with
the number of newly acknowledged bytes as long as the window is the number of newly acknowledged bytes as long as the window is
sufficiently used. sufficiently used. Sparse feedback can potentially limit congestion
window growth, an additional slack is therefore added, given by the
number of newly acked bytes.
The congestion window growth when in_fast_increase is false is The congestion window growth when in_fast_increase is false is
dictated by the relation between qdelay and qdelay_target, congestion dictated by the relation between qdelay and qdelay_target, congestion
window growth is limited if the window is not used sufficiently. window growth is limited if the window is not used sufficiently.
SCReAM calculates the GAIN in a similar way to what is specified in SCReAM calculates the GAIN in a similar way to what is specified in
[RFC6817]. There are however a few differences. [RFC6817]. There are however a few differences.
o [RFC6817] specifies a constant GAIN, this specification however o [RFC6817] specifies a constant GAIN, this specification however
limits the gain when CWND is increased dependent on near limits the gain when CWND is increased dependent on near
skipping to change at page 18, line 51 skipping to change at page 18, line 51
The qdelay_target is adjusted differently, depending on if The qdelay_target is adjusted differently, depending on if
qdelay_norm_var_t is above or below a given value. qdelay_norm_var_t is above or below a given value.
A low qdelay_norm_avg_t value indicates that the qdelay does not A low qdelay_norm_avg_t value indicates that the qdelay does not
change rapidly. It is desired avoid the case that the qdelay target change rapidly. It is desired avoid the case that the qdelay target
is increased due to self-congestion, indicated by a changing qdelay is increased due to self-congestion, indicated by a changing qdelay
and consequently an increased qdelay_norm_var_t. Still it should be and consequently an increased qdelay_norm_var_t. Still it should be
possible to increase the qdelay target if the qdelay continues to be possible to increase the qdelay target if the qdelay continues to be
high. This is a simple function with a certain risk of both false high. This is a simple function with a certain risk of both false
positives and negatives but it manages competing FTP flows reasonably positives and negatives but it manages competing FTP flows reasonably
well at the same time as it has proven to avoid accidental increased well at the same time as it has proven to avoid accidental increased
qdelay target relatively well in simulated LTE test cases. qdelay target relatively well in simulated LTE test cases. The
algorithm can however accidentally increase the qdelay target and
cause self-inflicted congestion in certain cases, therefore it is
recommended to turn off the algorithm if is unlikely that competing
flows will occur over the same bottleneck.
4.1.2.3. Lost packets detection 4.1.2.3. Lost packets detection
Lost packets detection is based on the received sequence number list. Lost packets detection is based on the received sequence number list.
A reordering window should be applied to avoid that packet reordering A reordering window should be applied to avoid that packet reordering
triggers loss events. triggers loss events.
The reordering window is specified as a time unit, similar to the The reordering window is specified as a time unit, similar to the
ideas behind RACK (Recent ACKnowledgement) [RACK]. The computation ideas behind RACK (Recent ACKnowledgement) [RACK]. The computation
of the reordering window is made possible by means of a lost flag in of the reordering window is made possible by means of a lost flag in
the list of transmitted RTP packets. This flag is set if the the list of transmitted RTP packets. This flag is set if the
skipping to change at page 21, line 27 skipping to change at page 21, line 30
The current throughput, current_rate, is computed as the maximum The current throughput, current_rate, is computed as the maximum
value of rate_transmit and rate_ack. The rationale behind the use of value of rate_transmit and rate_ack. The rationale behind the use of
rate_ack in addition to rate_transmit is that rate_transmit is rate_ack in addition to rate_transmit is that rate_transmit is
affected also by the amount of data that is available to transmit, affected also by the amount of data that is available to transmit,
thus a lack of data to transmit can be seen as reduced throughput thus a lack of data to transmit can be seen as reduced throughput
that may itself cause an unnecessary rate reduction. To overcome that may itself cause an unnecessary rate reduction. To overcome
this shortcoming; rate_ack is used as well. This gives a more stable this shortcoming; rate_ack is used as well. This gives a more stable
throughput estimate. throughput estimate.
The rate change behavior depends on whether a loss event has occurred The rate change behavior depends on whether a loss or ECN event has
and if the congestion control is in fast increase or not. occurred and if the congestion control is in fast increase or not.
# The target_bitrate is updated at a regular interval according # The target_bitrate is updated at a regular interval according
# to RATE_ADJUST_INTERVAL # to RATE_ADJUST_INTERVAL
on loss: on loss:
# Loss event detected
target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN) target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN)
exit exit
on ecn_mark:
# ECN event detected
target_bitrate = max(BETA_ECN* target_bitrate, TARGET_BITRATE_MIN)
exit
ramp_up_speed_t = min(RAMP_UP_SPEED, target_bitrate/2.0) ramp_up_speed_t = min(RAMP_UP_SPEED, target_bitrate/2.0)
scale_t = (target_bitrate - target_bitrate_last_max)/ scale_t = (target_bitrate - target_bitrate_last_max)/
target_bitrate_last_max target_bitrate_last_max
scale_t = max(0.2, min(1.0, (scale_t*4)^2)) scale_t = max(0.2, min(1.0, (scale_t*4)^2))
# min scale_t value 0.2 as the bitrate should be allowed to # min scale_t value 0.2 as the bitrate should be allowed to
# increase at least slowly --> avoid locking the rate to # increase at least slowly --> avoid locking the rate to
# target_bitrate_last_max # target_bitrate_last_max
if (in_fast_increase = true) if (in_fast_increase = true)
increment_t = ramp_up_speed_t*RATE_ADJUST_INTERVAL increment_t = ramp_up_speed_t*RATE_ADJUST_INTERVAL
skipping to change at page 23, line 6 skipping to change at page 22, line 39
rate_media_limit_t *= (2.0-1.0*qdelay_trend_mem) rate_media_limit_t *= (2.0-1.0*qdelay_trend_mem)
target_bitrate = min(target_bitrate, rate_media_limit_t) target_bitrate = min(target_bitrate, rate_media_limit_t)
target_bitrate = min(TARGET_BITRATE_MAX, target_bitrate = min(TARGET_BITRATE_MAX,
max(TARGET_BITRATE_MIN,target_bitrate)) max(TARGET_BITRATE_MIN,target_bitrate))
In case of a loss event the target_bitrate is updated and the rate In case of a loss event the target_bitrate is updated and the rate
change procedure is exited. Otherwise the rate change procedure change procedure is exited. Otherwise the rate change procedure
continues. The rationale behind the rate reduction due to loss is continues. The rationale behind the rate reduction due to loss is
that a congestion window reduction will take effect, a rate reduction that a congestion window reduction will take effect, a rate reduction
pro actively avoids that RTP packets are queued up when the transmit pro actively avoids that RTP packets are queued up when the transmit
rate decreases due to the reduced congestion window. An ECN event rate decreases due to the reduced congestion window. A similar rate
does not cause any action, the reason to this is that the congestion reduction happens when ECN events are detected.
window is reduced less due to ECN events than loss events, the effect
is thus that the expected additional RTP queuing delay due to ECN
events is so small that an additional decrease in media rate is not
warranted.
The rate update frequency is limited by RATE_ADJUST_INTERVAL, unless The rate update frequency is limited by RATE_ADJUST_INTERVAL, unless
a loss event occurs. The value is based on experimentation with real a loss event occurs. The value is based on experimentation with real
life limitations in video coders taken into account. A too short life limitations in video coders taken into account. A too short
interval has shown to make the video coder internal rate control loop interval has shown to make the video coder internal rate control loop
more unstable, a too long interval makes the overall congestion more unstable, a too long interval makes the overall congestion
control sluggish. control sluggish.
When in fast increase state (in_fast_increase=true), the bitrate When in fast increase state (in_fast_increase=true), the bitrate
increase is given by the desired ramp-up speed (RAMP_UP_SPEED) . The increase is given by the desired ramp-up speed (RAMP_UP_SPEED) . The
skipping to change at page 26, line 21 skipping to change at page 25, line 48
o Contact : irc://chat.freenode.net/openwebrtc o Contact : irc://chat.freenode.net/openwebrtc
6.2. A C++ Implementation of SCReAM 6.2. A C++ Implementation of SCReAM
o Organization : Ericsson Research, Ericsson. o Organization : Ericsson Research, Ericsson.
o Name : SCReAM. o Name : SCReAM.
o Implementation link : A C++ implementation of SCReAM is also o Implementation link : A C++ implementation of SCReAM is also
available [SCReAM-Cplusplus_Implementation]The code includes full available [SCReAM-Cplusplus_Implementation]. The code includes
support for congestion control, rate control and multi stream full support for congestion control, rate control and multi stream
handling, it can be integrated in web clients given the addition handling, it can be integrated in web clients given the addition
of extra code to implement the RTCP feedback and RTP queue(s). of extra code to implement the RTCP feedback and RTP queue(s).
The code also includes a rudimentary implementation of a
simulator. The code also includes a rudimentary implementation of a simulator
that allows for some initial experiments.
o Coverage : The code implements [I-D.ietf-rmcat-scream-cc] o Coverage : The code implements [I-D.ietf-rmcat-scream-cc]
o Contact : ingemar.s.johansson@ericsson.com o Contact : ingemar.s.johansson@ericsson.com
7. Acknowledgements 7. Suggested experiments
SCReAM has been evaluated in a number of different ways, most of the
evaluation has been in simulator. The OpenWebRTC implementation work
involved extensive testing with artificial bottlenecks with varying
bandwidths and using two different video coders (OpenH264 and VP9),
the experience of this lead to further improvements of the media rate
control logic.
Further experiments are preferably done by means of implementation in
real clients and web browsers. Recommended experiments are:
o Trials with various access technologies: EDGE/3G/4G, WiFi, DSL.
o Trials with different kinds of media: Audio, Video, slide show
content. Evaluation of multi stream handling in SCReAM.
o Evaluation of functionality of competing flows compensation
mechanism: Evaluate how SCReAM performs with competing TCP like
traffic and to what extent the competing flows compensation causes
self-inflicted congestion.
o Determine proper parameters: A set of default parameters are given
that makes SCReAM work over a reasonably large operation range,
however for instance for very low or very high bitrates it may be
necessary to use different values for instance for RAMP_UP_SPEED.
8. Acknowledgements
We would like to thank the following persons for their comments, We would like to thank the following persons for their comments,
questions and support during the work that led to this memo: Markus questions and support during the work that led to this memo: Markus
Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm, Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm,
Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson, Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson,
Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard
Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Many Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Many
additional thanks to RMCAT chairs Karen and Mirja for patiently additional thanks to RMCAT chairs Karen and Mirja for patiently
reading, suggesting improvements and also for asking all the reading, suggesting improvements and also for asking all the
difficult but necessary questions. Thanks to Stefan Holmer and difficult but necessary questions. Thanks to Stefan Holmer and
Xiaoqing Zhu for the review. Thanks to Ralf Globisch for taking time Xiaoqing Zhu for the review. Thanks to Ralf Globisch for taking time
to try out SCReAM in his challenging low bitrate use cases. to try out SCReAM in his challenging low bitrate use cases.
8. IANA Considerations 9. IANA Considerations
A new RFC4585 transport layer feedback message needs to be A new RFC4585 transport layer feedback message needs to be
standardized. standardized.
9. Security Considerations 10. Security Considerations
The feedback can be vulnerable to attacks similar to those that can The feedback can be vulnerable to attacks similar to those that can
affect TCP. It is therefore recommended that the RTCP feedback is at affect TCP. It is therefore recommended that the RTCP feedback is at
least integrity protected. Furthermore, as SCReAM is self-clocked, a least integrity protected. Furthermore, as SCReAM is self-clocked, a
malicious middlebox can drop RTCP feedback packets and thus cause the malicious middlebox can drop RTCP feedback packets and thus cause the
self-clocking in SCReAM to stall. self-clocking in SCReAM to stall.
10. Change history 11. Change history
A list of changes: A list of changes:
o WG-05 to WG-06: Added list of suggested experiments
o WG-04 to WG-05: Congestion control and rate control simplified o WG-04 to WG-05: Congestion control and rate control simplified
somewhat somewhat
o WG-03 to WG-04: Editorial fixes o WG-03 to WG-04: Editorial fixes
o WG-02 to WG-03: Review comments from Stefan Holmer and Xiaoqing o WG-02 to WG-03: Review comments from Stefan Holmer and Xiaoqing
Zhu addressed, owd changed to qdelay for clarity. Added appendix Zhu addressed, owd changed to qdelay for clarity. Added appendix
section with RTCP feedback requirements, including a suggested section with RTCP feedback requirements, including a suggested
basic feedback format based Loss RLE report block and the Packet basic feedback format based Loss RLE report block and the Packet
Receipt Times blocks in [RFC3611]. Loss detection added as a Receipt Times blocks in [RFC3611]. Loss detection added as a
skipping to change at page 28, line 5 skipping to change at page 28, line 12
o -03 to -04 : Extensive changes due to review comments, code o -03 to -04 : Extensive changes due to review comments, code
somewhat modified, frame skipping made optional somewhat modified, frame skipping made optional
o -02 to -03 : Added algorithm description with equations, removed o -02 to -03 : Added algorithm description with equations, removed
pseudo code and simulation results pseudo code and simulation results
o -01 to -02 : Updated GCC simulation results o -01 to -02 : Updated GCC simulation results
o -00 to -01 : Fixed a few bugs in example code o -00 to -01 : Fixed a few bugs in example code
11. References 12. References
11.1. Normative References 12.1. Normative References
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[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, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://www.rfc-editor.org/info/rfc3550>.
skipping to change at page 28, line 40 skipping to change at page 28, line 47
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011, DOI 10.17487/RFC6298, June 2011,
<http://www.rfc-editor.org/info/rfc6298>. <http://www.rfc-editor.org/info/rfc6298>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012, DOI 10.17487/RFC6817, December 2012,
<http://www.rfc-editor.org/info/rfc6817>. <http://www.rfc-editor.org/info/rfc6817>.
11.2. Informative References 12.2. Informative References
[I-D.ietf-rmcat-app-interaction] [I-D.ietf-rmcat-app-interaction]
Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, "RTP Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, "RTP
Application Interaction with Congestion Control", draft- Application Interaction with Congestion Control", draft-
ietf-rmcat-app-interaction-01 (work in progress), October ietf-rmcat-app-interaction-01 (work in progress), October
2014. 2014.
[I-D.ietf-rmcat-cc-codec-interactions] [I-D.ietf-rmcat-cc-codec-interactions]
Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker,
"Congestion Control and Codec interactions in RTP "Congestion Control and Codec interactions in RTP
Applications", draft-ietf-rmcat-cc-codec-interactions-02 Applications", draft-ietf-rmcat-cc-codec-interactions-02
(work in progress), March 2016. (work in progress), March 2016.
[I-D.ietf-rmcat-coupled-cc] [I-D.ietf-rmcat-coupled-cc]
Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion
control for RTP media", draft-ietf-rmcat-coupled-cc-02 control for RTP media", draft-ietf-rmcat-coupled-cc-03
(work in progress), April 2016. (work in progress), July 2016.
[I-D.ietf-rmcat-scream-cc] [I-D.ietf-rmcat-scream-cc]
Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
for Multimedia", draft-ietf-rmcat-scream-cc-04 (work in for Multimedia", draft-ietf-rmcat-scream-cc-05 (work in
progress), June 2016. progress), June 2016.
[I-D.ietf-rmcat-wireless-tests] [I-D.ietf-rmcat-wireless-tests]
Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and
M. Ramalho, "Evaluation Test Cases for Interactive Real- D. Ramalho, "Evaluation Test Cases for Interactive Real-
Time Media over Wireless Networks", draft-ietf-rmcat- Time Media over Wireless Networks", draft-ietf-rmcat-
wireless-tests-02 (work in progress), May 2016. wireless-tests-02 (work in progress), May 2016.
[Khademi_alternative_backoff_ECN] [Khademi_alternative_backoff_ECN]
"TCP Alternative Backoff with ECN (ABE)", "TCP Alternative Backoff with ECN (ABE)",
<https://tools.ietf.org/html/draft-khademi- <https://tools.ietf.org/html/draft-khademi-
alternativebackoff-ecn-00>. alternativebackoff-ecn-00>.
[OpenWebRTC] [OpenWebRTC]
"Open WebRTC project.", <http://www.openwebrtc.io/>. "Open WebRTC project.", <http://www.openwebrtc.io/>.
skipping to change at page 33, line 27 skipping to change at page 34, line 9
[RFC6679]. The given feedback report format is actually a slight [RFC6679]. The given feedback report format is actually a slight
overkill as SCReAM would do quite well with only a counter that overkill as SCReAM would do quite well with only a counter that
increments by one for each received packet with the ECE-CE code increments by one for each received packet with the ECE-CE code
point set. The more bulky format may be nevertheless be useful point set. The more bulky format may be nevertheless be useful
for e.g ECN black-hole detection. for e.g ECN black-hole detection.
o Source quench bit (Q): Makes it possible to request the sender to o Source quench bit (Q): Makes it possible to request the sender to
reduce its congestion window. This is useful if WebRTC media is reduce its congestion window. This is useful if WebRTC media is
received from many hosts and it becomes necessary to balance the received from many hosts and it becomes necessary to balance the
bitrates between the streams. This can currently not be realized bitrates between the streams. This can currently not be realized
with any standardized feedback format. with any standardized feedback format, however the ECN counter can
be artificially incremented, even though no ECN-CE marked packets
are received to achieve a similar behavior.
A.4.2. Requirements on feedback intensity A.4.2. Requirements on feedback intensity
SCReAM benefits from a relatively frequent feedback. Experiments SCReAM benefits from a relatively frequent feedback. The feedback
have shown that a feedback rate roughly equal to the frame rate gives interval depends on the media bitrate. At low bitrates it is
a stable self-clocking and robustness against loss of feedback. With sufficient with a feedback interval of 100 to 200ms, while at high
a maximum bitrate of 1500kbps the RTCP feedback overhead is in the bitrates a feedback interval of ~20ms is to prefer.
range 10-15kbps with reduced size RTCP [RFC5506], including IP and
UDP framing and a reasonable compact RTCP feedback format. In other
words the RTCP overhead is quite modest and should not pose a problem
in the general case. Worth notice is that SCReAM can work with as
low feedback rates as once every 200ms at low media rates (e.g
50kbps) , a low feedback rate when media rate is high comes at the
cost of a higher sensitivity to loss of feedback and also a potential
reduction in throughput due to degraded ACK-clocking performance.
SCReAM works with AVPF regular mode, immediate or early mode is not
required by SCReAM but may nonetheless be useful for e.g RTCP
messages not directly related to SCReAM, such as those specified in
[RFC4585]. It is recommended to use reduced size RTCP [RFC5506]where
regular full compound RTCP transmission is controlled by trr-int as
described in [RFC4585].
The feedback interval depends on the media bitrate. At low bitrates
it is sufficient with a feedback interval of 100 to 200ms, while at
high bitrates a feedback interval of ~20ms is to prefer.
This leads to a feedback rate according to the following equation: The numbers above can be formulated as feedback interval function
that can be useful for the computation of the desired RTCP bandwidth.
The following equation expresses the feedback rate:
rate_fb = min(50,max(10,rate_media/20000)) rate_fb = min(50,max(5,rate_media/10000))
rate_media is the RTP media bitrate expressed in [bits/s], rate_fb is rate_media is the RTP media bitrate expressed in [bits/s], rate_fb is
the feedback rate expressed in [packets/s]. Converted to feedback the feedback rate expressed in [packets/s]. Converted to feedback
interval we get: interval we get:
fb_int = 1.0/min(50,max(10,rate_media/20000)) fb_int = 1.0/min(50,max(5,rate_media/10000))
The transmission interval is not critical, this means that in the The transmission interval is not critical, this means that in the
case of multi-stream handling between two hosts, the feedback for two case of multi-stream handling between two hosts, the feedback for two
or more SSRCs can be bundled to save UDP/IP overhead, the final or more SSRCs can be bundled to save UDP/IP overhead, the final
realized feedback interval should however not exceed 2*fb_int in such realized feedback interval should however not exceed 2*fb_int in such
cases meaning that a scheduled feedback transmission event should not cases meaning that a scheduled feedback transmission event should not
be delayed more that fb_int. be delayed more that fb_int.
SCReAM works with AVPF regular mode, immediate or early mode is not
required by SCReAM but may nonetheless be useful for e.g RTCP
messages not directly related to SCReAM, such as those specified in
[RFC4585]. It is recommended to use reduced size RTCP [RFC5506]
where regular full compound RTCP transmission is controlled by trr-
int as described in [RFC4585].
A.5. Q-bit semantics (source quench) A.5. Q-bit semantics (source quench)
The Q bit in the feedback is set by a receiver to signal that the The Q bit in the feedback is set by a receiver to signal that the
sender should reduce the bitrate. The sender will in response to sender should reduce the bitrate. The sender will in response to
this reduce the congestion window with the consequence that the video this reduce the congestion window with the consequence that the video
bitrate decreases. A typical use case for source quench is when a bitrate decreases. A typical use case for source quench is when a
receiver receives streams from sources located at different hosts and receiver receives streams from sources located at different hosts and
they all share a common bottleneck, typically it is difficult to they all share a common bottleneck, typically it is difficult to
apply any rate distribution signaling between the sending hosts. The apply any rate distribution signaling between the sending hosts. The
solution is then that the receiver sets the Q bit in the feedback to solution is then that the receiver sets the Q bit in the feedback to
skipping to change at page 35, line 4 skipping to change at page 35, line 23
This is ensured by the opportunistic behavior of SCReAM's congestion This is ensured by the opportunistic behavior of SCReAM's congestion
control. The source quench will have no or little effect if the control. The source quench will have no or little effect if the
flows do not share the same bottleneck. flows do not share the same bottleneck.
The reduction in congestion window is proportional to the amount of The reduction in congestion window is proportional to the amount of
SCReAM RTCP feedback with the Q bit set, the below steps outline how SCReAM RTCP feedback with the Q bit set, the below steps outline how
the sender should react to RTCP feedback with the Q bit set. The the sender should react to RTCP feedback with the Q bit set. The
reduction is done once per RTT. Let : reduction is done once per RTT. Let :
o n = Number of received RTCP feedback messages in one RTT o n = Number of received RTCP feedback messages in one RTT
o n_q = Number of received RTCP feedback messages in one RTT, with Q o n_q = Number of received RTCP feedback messages in one RTT, with Q
bit set. bit set.
The new congestion window is then expressed as: The new congestion window is then expressed as:
cwnd = max(MIN_CWND, cwnd*(1.0-0.5* n_q /n)) cwnd = max(MIN_CWND, cwnd*(1.0-0.5*n_q/n))
Note that CWND is adjusted at most once per RTT. Furthermore The Note that CWND is adjusted at most once per RTT. Furthermore The
CWND increase should be inhibited for one RTT if CWND has been CWND increase should be inhibited for one RTT if CWND has been
decreased as a result of Q bits set in the feedback. decreased as a result of Q bits set in the feedback.
The required intensity of the Q-bit set in the feedback in order to The required intensity of the Q-bit set in the feedback in order to
achieve a given rate distribution depends on many factors such as achieve a given rate distribution depends on many factors such as
RTT, video source material etc. The receiver thus need to monitor RTT, video source material etc. The receiver thus need to monitor
the change in the received video bitrate on the different streams and the change in the received video bitrate on the different streams and
adjust the intensity of the Q-bit accordingly. adjust the intensity of the Q-bit accordingly.
 End of changes. 37 change blocks. 
70 lines changed or deleted 107 lines changed or added

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