--- 1/draft-ietf-rmcat-scream-cc-09.txt 2017-07-18 08:13:20.949497313 -0700 +++ 2/draft-ietf-rmcat-scream-cc-10.txt 2017-07-18 08:13:21.025499109 -0700 @@ -1,18 +1,18 @@ RMCAT WG I. Johansson Internet-Draft Z. Sarker 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 - draft-ietf-rmcat-scream-cc-09 + draft-ietf-rmcat-scream-cc-10 Abstract This memo describes a rate adaptation algorithm for conversational media services such as video. The solution conforms to the packet conservation principle and uses a hybrid loss and delay based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a Long Term Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios. @@ -25,49 +25,37 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as 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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3 1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4 3.1. Network Congestion Control . . . . . . . . . . . . . . . 7 3.2. Sender Transmission Control . . . . . . . . . . . . . . . 8 3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 8 @@ -92,22 +80,22 @@ 6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 29 6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 29 7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 11. Change history . . . . . . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . 32 12.2. Informative References . . . . . . . . . . . . . . . . . 33 - Appendix A. Additional information . . . . . . . . . . . . . . . 35 - A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 35 + Appendix A. Additional information . . . . . . . . . . . . . . . 34 + A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 34 A.2. Computation of autocorrelation function . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction Congestion in the Internet occurs when the transmitted bitrate is higher than the available capacity over a given transmission path. Applications that are deployed in the Internet MUST employ congestion control, to achieve robust performance and to avoid congestion collapse in the Internet. Interactive realtime communication imposes @@ -175,21 +163,21 @@ certain time lag to avoid over-reaction to spurious congestion events such as delay spikes. Despite the fact that there are two or more congestion indications, the outcome is still that there is still only one mechanism to adjust the sending rate. This makes it difficult to reach the goals of high throughput and prompt reaction to congestion. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "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 The core SCReAM algorithm has similarities to the concepts of self- clocking used in TFWC [TFWC] and follows the packet conservation principle. The packet conservation principle is described as an important key-factor behind the protection of networks from congestion [Packet-conservation]. In SCReAM, the receiver of the media echoes a list of received RTP @@ -419,21 +407,21 @@ The RECOMMENDED values, within (), for the constants are deduced from experiments. The units are enclosed in square brackets [ ]. QDELAY_TARGET_LO (0.1s) Target value for the minimum qdelay. QDELAY_TARGET_HI (0.4s) Target value for the maximum qdelay. This parameter provides an upper limit to how much the target qdelay (qdelay_target) can be 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 congestion control loop sluggish. QDELAY_WEIGHT (0.1) Averaging factor for qdelay_fraction_avg. QDELAY_TREND_TH (0.2) Averaging factor for qdelay_fraction_avg. MAX_BYTES_IN_FLIGHT_HEAD_ROOM (1.1) @@ -756,21 +744,22 @@ end # not in fast increase phase # off_target calculated as with LEDBAT off_target_t = (qdelay_target - qdelay) / qdelay_target gain_t = GAIN # adjust congestion window cwnd_delta_t = 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 # an additional slack of bytes_newly_acked is # added to ensure that CWND growth occurs # even when feedback is sparse cwnd_delta_t = 0; end # apply delta cwnd += cwnd_delta_t # limit cwnd to the maximum number of bytes in flight @@ -1050,21 +1038,22 @@ end target_bitrate += delta_rate_t # force a slight reduction in bitrate if RTP queue # builds up rtp_queue_delay_t = rtp_queue_size/current_rate_t if (rtp_queue_delay_t > RTP_QDELAY_TH) target_bitrate *= TARGET_RATE_SCALE_RTP_QDELAY 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) target_bitrate = min(target_bitrate, rate_media_limit_t) target_bitrate = min(TARGET_BITRATE_MAX, max(TARGET_BITRATE_MIN,target_bitrate)) In case of a loss event the target_bitrate is updated and the rate change procedure is exited. Otherwise the rate change procedure continues. The rationale behind the rate reduction due to loss is that a congestion window reduction will take effect, a rate reduction @@ -1258,36 +1247,36 @@ It is not strictly necessary to make a 100% perfect compensation for the overhead as the SCReAM algorithm will inherently compensate for moderate errors. Under-compensation of the overhead has the effect of increasing jitter while overcompensation will have the effect of causing the bottleneck link to become under-utilized. 6. Implementation status [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 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 assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort 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 features. Readers are advised to note that other implementations MAY 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 running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see it". 6.1. OpenWebRTC The SCReAM algorithm has been implemented in the OpenWebRTC project [OpenWebRTC], an open source WebRTC implementation from Ericsson @@ -1454,25 +1443,20 @@ 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . - [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, . - [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . @@ -1482,32 +1466,20 @@ DOI 10.17487/RFC6298, June 2011, . [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, . 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] Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion control for RTP media", draft-ietf-rmcat-coupled-cc-06 (work in progress), March 2017. [I-D.ietf-rmcat-wireless-tests] Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and M. Ramalho, "Evaluation Test Cases for Interactive Real- Time Media over Wireless Networks", draft-ietf-rmcat- wireless-tests-04 (work in progress), May 2017. @@ -1543,30 +1515,30 @@ [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, . [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, . - [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running - Code: The Implementation Status Section", RFC 6982, - DOI 10.17487/RFC6982, July 2013, - . - [RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating TCP to Support Rate-Limited Traffic", RFC 7661, DOI 10.17487/RFC7661, October 2015, . + [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, + . + [SCReAM-CPP-implementation] "C++ Implementation of SCReAM", . [SCReAM-implementation] "SCReAM Implementation", . [SCReAM-implementation-experience]