draft-ietf-rmcat-scream-cc-09.txt   draft-ietf-rmcat-scream-cc-10.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: November 30, 2017 May 29, 2017 Expires: January 19, 2018 July 18, 2017
Self-Clocked Rate Adaptation for Multimedia Self-Clocked Rate Adaptation for Multimedia
draft-ietf-rmcat-scream-cc-09 draft-ietf-rmcat-scream-cc-10
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 Long Term simulated Internet bottleneck scenarios as well as in a Long Term
Evolution (LTE) system simulator and is shown to achieve both low Evolution (LTE) 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 November 30, 2017. This Internet-Draft will expire on January 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3 1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3
1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 4 1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4 3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4
3.1. Network Congestion Control . . . . . . . . . . . . . . . 7 3.1. Network Congestion Control . . . . . . . . . . . . . . . 7
3.2. Sender Transmission Control . . . . . . . . . . . . . . . 8 3.2. Sender Transmission Control . . . . . . . . . . . . . . . 8
3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 8 3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 3, line 9 skipping to change at page 2, line 45
6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 29 6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 29
6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 29 6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 29
7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 30 7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. Change history . . . . . . . . . . . . . . . . . . . . . . . 31 11. Change history . . . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Additional information . . . . . . . . . . . . . . . 35 Appendix A. Additional information . . . . . . . . . . . . . . . 34
A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 35 A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 34
A.2. Computation of autocorrelation function . . . . . . . . . 35 A.2. Computation of autocorrelation function . . . . . . . . . 35
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 capacity over a given transmission path. higher than the available capacity over a given transmission path.
Applications that are deployed in the Internet MUST employ congestion Applications that are deployed in the Internet MUST employ congestion
control, to achieve robust performance and to avoid congestion control, to achieve robust performance and to avoid congestion
collapse in the Internet. Interactive realtime communication imposes collapse in the Internet. Interactive realtime communication imposes
skipping to change at page 4, line 45 skipping to change at page 4, line 34
certain time lag to avoid over-reaction to spurious congestion events certain time lag to avoid over-reaction to spurious congestion events
such as delay spikes. Despite the fact that there are two or more such as delay spikes. Despite the fact that there are two or more
congestion indications, the outcome is still that there is still only congestion indications, the outcome is still that there is still only
one mechanism to adjust the sending rate. This makes it difficult to one mechanism to adjust the sending rate. This makes it difficult to
reach the goals of high throughput and prompt reaction to congestion. reach the goals of high throughput and prompt reaction to congestion.
2. Terminology 2. Terminology
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 [RFC2119] document are to be interpreted as described in [RFC2119].
3. Overview of SCReAM Algorithm 3. Overview of SCReAM Algorithm
The core SCReAM algorithm has similarities to the concepts of self- The core SCReAM algorithm has similarities to the concepts of self-
clocking used in TFWC [TFWC] and follows the packet conservation clocking used in TFWC [TFWC] and follows the packet conservation
principle. The packet conservation principle is described as an principle. The packet conservation principle is described as an
important key-factor behind the protection of networks from important key-factor behind the protection of networks from
congestion [Packet-conservation]. congestion [Packet-conservation].
In SCReAM, the receiver of the media echoes a list of received RTP In SCReAM, the receiver of the media echoes a list of received RTP
skipping to change at page 10, line 10 skipping to change at page 10, line 10
The RECOMMENDED values, within (), for the constants are deduced from The RECOMMENDED values, within (), for the constants are deduced from
experiments. The units are enclosed in square brackets [ ]. experiments. The units are enclosed in square brackets [ ].
QDELAY_TARGET_LO (0.1s) QDELAY_TARGET_LO (0.1s)
Target value for the minimum qdelay. Target value for the minimum qdelay.
QDELAY_TARGET_HI (0.4s) QDELAY_TARGET_HI (0.4s)
Target value for the maximum qdelay. This parameter provides an Target value for the maximum qdelay. This parameter provides an
upper limit to how much the target qdelay (qdelay_target) can be upper limit to how much the target qdelay (qdelay_target) can be
increased in order to cope with competing loss based flows. The increased in order to cope with competing loss based flows. The
target qdelay MUST not be initialized to this high value however as target qdelay MUST NOT be initialized to this high value however as
it would increase e2e delay and also make the rate control and it would increase e2e delay and also make the rate control and
congestion control loop sluggish. congestion control loop sluggish.
QDELAY_WEIGHT (0.1) QDELAY_WEIGHT (0.1)
Averaging factor for qdelay_fraction_avg. Averaging factor for qdelay_fraction_avg.
QDELAY_TREND_TH (0.2) QDELAY_TREND_TH (0.2)
Averaging factor for qdelay_fraction_avg. Averaging factor for qdelay_fraction_avg.
MAX_BYTES_IN_FLIGHT_HEAD_ROOM (1.1) MAX_BYTES_IN_FLIGHT_HEAD_ROOM (1.1)
skipping to change at page 17, line 34 skipping to change at page 17, line 34
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+bytes_newly_acked <= 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 # an additional slack of bytes_newly_acked is
# added to ensure that CWND growth occurs # added to ensure that CWND growth occurs
# even when feedback is sparse # 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
skipping to change at page 23, line 52 skipping to change at page 23, line 52
end end
target_bitrate += delta_rate_t target_bitrate += delta_rate_t
# force a slight reduction in bitrate if RTP queue # force a slight reduction in bitrate if RTP queue
# builds up # builds up
rtp_queue_delay_t = rtp_queue_size/current_rate_t rtp_queue_delay_t = rtp_queue_size/current_rate_t
if (rtp_queue_delay_t > RTP_QDELAY_TH) if (rtp_queue_delay_t > RTP_QDELAY_TH)
target_bitrate *= TARGET_RATE_SCALE_RTP_QDELAY target_bitrate *= TARGET_RATE_SCALE_RTP_QDELAY
end end
end end
rate_media_limit_t = max(current_rate_t, max(rate_media,rtp_rate_median)) rate_media_limit_t =
max(current_rate_t, max(rate_media,rtp_rate_median))
rate_media_limit_t *= (2.0-qdelay_trend_mem) rate_media_limit_t *= (2.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))
<CODE ENDS> <CODE ENDS>
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
skipping to change at page 28, line 28 skipping to change at page 28, line 28
It is not strictly necessary to make a 100% perfect compensation It is not strictly necessary to make a 100% perfect compensation
for the overhead as the SCReAM algorithm will inherently for the overhead as the SCReAM algorithm will inherently
compensate for moderate errors. Under-compensation of the compensate for moderate errors. Under-compensation of the
overhead has the effect of increasing jitter while overhead has the effect of increasing jitter while
overcompensation will have the effect of causing the bottleneck overcompensation will have the effect of causing the bottleneck
link to become under-utilized. link to become under-utilized.
6. Implementation status 6. Implementation status
[Editor's note: Please remove the whole section before publication, [Editor's note: Please remove the whole section before publication,
as well reference to RFC 6982] as well reference to RFC 7942]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and MUST not supplied by IETF contributors. This is not intended as, and MUST NOT
be construed to be, a catalog of available implementations or their be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations MAY features. Readers are advised to note that other implementations MAY
exist. exist.
According to [RFC6982], "this will allow reviewers and working groups According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see it". they see it".
6.1. OpenWebRTC 6.1. OpenWebRTC
The SCReAM algorithm has been implemented in the OpenWebRTC project The SCReAM algorithm has been implemented in the OpenWebRTC project
[OpenWebRTC], an open source WebRTC implementation from Ericsson [OpenWebRTC], an open source WebRTC implementation from Ericsson
skipping to change at page 32, line 34 skipping to change at page 32, line 34
12. References 12. References
12.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.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>. <http://www.rfc-editor.org/info/rfc4585>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, DOI 10.17487/RFC5506, April and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <http://www.rfc-editor.org/info/rfc5506>. 2009, <http://www.rfc-editor.org/info/rfc5506>.
skipping to change at page 33, line 17 skipping to change at page 33, line 12
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>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-rmcat-app-interaction]
Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, "RTP
Application Interaction with Congestion Control", draft-
ietf-rmcat-app-interaction-01 (work in progress), October
2014.
[I-D.ietf-rmcat-cc-codec-interactions]
Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker,
"Congestion Control and Codec interactions in RTP
Applications", draft-ietf-rmcat-cc-codec-interactions-02
(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-06 control for RTP media", draft-ietf-rmcat-coupled-cc-06
(work in progress), March 2017. (work in progress), March 2017.
[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- M. 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-04 (work in progress), May 2017. wireless-tests-04 (work in progress), May 2017.
skipping to change at page 34, line 33 skipping to change at page 34, line 15
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>. <http://www.rfc-editor.org/info/rfc3611>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <http://www.rfc-editor.org/info/rfc6679>. 2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982,
DOI 10.17487/RFC6982, July 2013,
<http://www.rfc-editor.org/info/rfc6982>.
[RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating [RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
TCP to Support Rate-Limited Traffic", RFC 7661, TCP to Support Rate-Limited Traffic", RFC 7661,
DOI 10.17487/RFC7661, October 2015, DOI 10.17487/RFC7661, October 2015,
<http://www.rfc-editor.org/info/rfc7661>. <http://www.rfc-editor.org/info/rfc7661>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<http://www.rfc-editor.org/info/rfc7942>.
[SCReAM-CPP-implementation] [SCReAM-CPP-implementation]
"C++ Implementation of SCReAM", "C++ Implementation of SCReAM",
<https://github.com/EricssonResearch/scream>. <https://github.com/EricssonResearch/scream>.
[SCReAM-implementation] [SCReAM-implementation]
"SCReAM Implementation", "SCReAM Implementation",
<https://github.com/EricssonResearch/openwebrtc-gst- <https://github.com/EricssonResearch/openwebrtc-gst-
plugins>. plugins>.
[SCReAM-implementation-experience] [SCReAM-implementation-experience]
 End of changes. 17 change blocks. 
47 lines changed or deleted 20 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/