--- 1/draft-ietf-rmcat-coupled-cc-08.txt 2019-08-22 07:13:08.060442907 -0700 +++ 2/draft-ietf-rmcat-coupled-cc-09.txt 2019-08-22 07:13:08.128444638 -0700 @@ -1,19 +1,19 @@ RTP Media Congestion Avoidance Techniques (rmcat) S. Islam Internet-Draft M. Welzl Intended status: Experimental S. Gjessing -Expires: July 14, 2019 University of Oslo - January 10, 2019 +Expires: February 23, 2020 University of Oslo + August 22, 2019 Coupled congestion control for RTP media - draft-ietf-rmcat-coupled-cc-08 + draft-ietf-rmcat-coupled-cc-09 Abstract When multiple congestion controlled Real-time Transport Protocol (RTP) sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the amount of changes needed to existing RTP applications. It specifies how to apply the method for @@ -29,21 +29,21 @@ 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 https://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 July 14, 2019. + This Internet-Draft will expire on February 23, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -57,52 +57,53 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Architectural overview . . . . . . . . . . . . . . . . . . . 5 5. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. FSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3.1. Example algorithm 1 - Active FSE . . . . . . . . . . 9 - 5.3.2. Example algorithm 2 - Conservative Active FSE . . . . 11 + 5.3.2. Example algorithm 2 - Conservative Active FSE . . . . 10 6. Application . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. NADA . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 6.2. General recommendations . . . . . . . . . . . . . . . . . 12 + 6.2. General recommendations . . . . . . . . . . . . . . . . . 11 7. Expected feedback from experiments . . . . . . . . . . . . . 12 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Application to GCC . . . . . . . . . . . . . . . . . 16 Appendix B. Scheduling . . . . . . . . . . . . . . . . . . . . . 16 Appendix C. Example algorithm - Passive FSE . . . . . . . . . . 16 C.1. Example operation (passive) . . . . . . . . . . . . . . . 19 Appendix D. Change log . . . . . . . . . . . . . . . . . . . . . 23 D.1. draft-welzl-rmcat-coupled-cc . . . . . . . . . . . . . . 23 D.1.1. Changes from -00 to -01 . . . . . . . . . . . . . . . 23 D.1.2. Changes from -01 to -02 . . . . . . . . . . . . . . . 23 D.1.3. Changes from -02 to -03 . . . . . . . . . . . . . . . 23 D.1.4. Changes from -03 to -04 . . . . . . . . . . . . . . . 24 D.1.5. Changes from -04 to -05 . . . . . . . . . . . . . . . 24 D.2. draft-ietf-rmcat-coupled-cc . . . . . . . . . . . . . . . 24 D.2.1. Changes from draft-welzl-rmcat-coupled-cc-05 . . . . 24 D.2.2. Changes from -00 to -01 . . . . . . . . . . . . . . . 24 D.2.3. Changes from -01 to -02 . . . . . . . . . . . . . . . 24 D.2.4. Changes from -02 to -03 . . . . . . . . . . . . . . . 24 - D.2.5. Changes from -03 to -04 . . . . . . . . . . . . . . . 25 + D.2.5. Changes from -03 to -04 . . . . . . . . . . . . . . . 24 D.2.6. Changes from -04 to -05 . . . . . . . . . . . . . . . 25 D.2.7. Changes from -05 to -06 . . . . . . . . . . . . . . . 25 D.2.8. Changes from -06 to -07 . . . . . . . . . . . . . . . 25 D.2.9. Changes from -07 to -08 . . . . . . . . . . . . . . . 25 + D.2.10. Changes from -08 to -09 . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction When there is enough data to send, a congestion controller attempts to increase its sending rate until the path's capacity has been reached. Some controllers detect path capacity by increasing the sending rate further, until packets are ECN-marked [RFC8087] or dropped, and then decreasing the sending rate until that stops happening. This process inevitably creates undesirable queuing delay @@ -380,93 +381,80 @@ o P(f) - The priority of flow f which is received from the flow's congestion controller; the FSE uses this variable for calculating FSE_R(f). o S_P - The sum of all the priorities. o TLO - The total leftover rate: the sum of rates that could not be assigned to flows that were limited by their desired rate. - o S_P2 - The sum of all the priorities of flows to which a share of - the TLO can be assigned. + o AR - The aggregate rate that is assigned to flows that are not + limited by their desired rate. 5.3.1. Example algorithm 1 - Active FSE This algorithm was designed to be the simplest possible method to assign rates according to the priorities of flows. Simulations results in [fse] indicate that it does however not significantly reduce queuing delay and packet loss. (1) When a flow f starts, it registers itself with SBD and the FSE. FSE_R(f) is initialized with the congestion controller's initial rate. SBD will assign the correct FGI. When a flow is assigned an FGI, it adds its FSE_R(f) to S_CR. (2) When a flow f stops or pauses, its entry is removed from the list. (3) Every time the congestion controller of the flow f determines a new sending rate CC_R(f), the flow calls UPDATE, which carries out the tasks listed below to derive the new sending rates for all the flows in the FG. A flow's UPDATE function uses three - local (i.e. per-flow) temporary variables: S_P, TLO and S_P2. + local (i.e. per-flow) temporary variables: S_P, TLO and AR. (a) It updates S_CR. S_CR = S_CR + CC_R(f) - FSE_R(f) - (b) It calculates the sum of all the priorities, S_P. + (b) It calculates the sum of all the priorities, S_P, and + initializes FSE_R. S_P = 0 for all flows i in FG do S_P = S_P + P(i) + FSE_R(i) = 0 end for - (c) It calculates the sending rates for all the flows in an FG, - the total leftover rate (TLO) from flows that are limited - by their desired rate, and the sum of the priorities of all - other flows, S_P2. + (c) It distributes S_CR among all flows, ensuring that each + flow's desired rate is not exceeded. - TLO = 0 - S_P2 = 0 + TLO = S_CR + while(TLO-AR>0 and S_P>0) + AR = 0 for all flows i in FG do - FSE_R(i) = P(i) * S_CR /S_P - if FSE_R(i) >= DR(i) then - TLO = TLO + FSE_R(i) - DR(i) - FSE_R(i) = DR(i) + if FSE_R[i] < DR[i] then + if TLO * P[i] / S_P >= DR[i] then + TLO = TLO - DR[i] + FSE_R[i] = DR[i] + S_P = S_P - P[i] else - S_P2 = S_P2 + P(i) - end if - end for - - (d) It checks if there are flows that are limited by their DR - and cannot accept their share of the TLO, and updates TLO - and S_P2 accordingly. - - for all flows i in FG do - if FSE_R(i) < DR(i) then - if FSE_R(i) + TLO * P(i) / S_P2 > DR(i) then - TLO = TLO - ( DR(i) - FSE_R(i) ) - FSE_R(i) = DR(i) - S_P2 = S_P2 - P(i) + FSE_R[i] = TLO * P[i] / S_P + AR = AR + TLO * P[i] / S_P end if end if end for + end while - (e) It assigns the non-limited flow their share of the total - leftover rate and sends all the rates to all the flows. + (d) It distributes FSE_R to all the flows. for all flows i in FG do - if FSE_R(i) < DR(i) then - FSE_R(i) = FSE_R(i) + P(i) * TLO / S_P2 - end if send FSE_R(i) to the flow i end for 5.3.2. Example algorithm 2 - Conservative Active FSE This algorithm changes algorithm 1 to conservatively emulate the behavior of a single flow by proportionally reducing the aggregate rate on congestion. Simulations results in [fse] indicate that it can significantly reduce queuing delay and packet loss. @@ -560,23 +547,23 @@ testers are invited to document their findings in an Internet draft. 8. Acknowledgements This document has benefitted from discussions with and feedback from Andreas Petlund, Anna Brunstrom, Colin Perkins, David Hayes, David Ros (who also gave the FSE its name), Ingemar Johansson, Karen Nielsen, Kristian Hiorth, Mirja Kuehlewind, Martin Stiemerling, Spencer Dawkins, Varun Singh, Xiaoqing Zhu, and Zaheduzzaman Sarker. The authors would like to especially thank Xiaoqing Zhu and Stefan - Holmer for helping with NADA and GCC, and Julius Flohr for helping us - correct the active algorithm for the case of application-limited - flows. + Holmer for helping with NADA and GCC, and Anna Brunstrom as well as + Julius Flohr for helping us correct the active algorithm for the case + of application-limited flows. This work was partially funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700). 9. IANA Considerations This memo includes no request to IANA. 10. Security Considerations @@ -605,22 +592,22 @@ Implementers should also be aware of the Security Considerations sections of [RFC3124], [RFC5348], and [RFC7478]. 11. References 11.1. Normative References [I-D.ietf-rmcat-nada] Zhu, X., *, R., Ramalho, M., Cruz, S., Jones, P., Fu, J., and S. D'Aronco, "NADA: A Unified Congestion Control - Scheme for Real-Time Media", draft-ietf-rmcat-nada-09 - (work in progress), August 2018. + Scheme for Real-Time Media", draft-ietf-rmcat-nada-11 + (work in progress), July 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, DOI 10.17487/RFC3124, June 2001, . @@ -646,21 +633,21 @@ 2014. [fse-noms] Islam, S., Welzl, M., Hayes, D., and S. Gjessing, "Managing Real-Time Media Flows through a Flow State Exchange", IEEE NOMS 2016, Istanbul, Turkey , 2016. [I-D.ietf-rmcat-eval-test] Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- - eval-test-08 (work in progress), November 2018. + eval-test-10 (work in progress), May 2019. [I-D.ietf-rmcat-gcc] Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. Mascolo, "A Google Congestion Control Algorithm for Real- Time Communication", draft-ietf-rmcat-gcc-02 (work in progress), July 2016. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-19 @@ -1110,20 +1097,24 @@ D.2.8. Changes from -06 to -07 o Addressed OPSDIR, SECDIR, GENART, AD and IESG comments. D.2.9. Changes from -07 to -08 o Updated the algorithms in section 5 to support application-limited flows. Moved definition of Desired Rate from appendix to section 5. Updated references. +D.2.10. Changes from -08 to -09 + + o Minor improvement of the algorithms in section 5. + Authors' Addresses Safiqul Islam University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Phone: +47 22 84 08 37 Email: safiquli@ifi.uio.no