--- 1/draft-ietf-rmcat-nada-06.txt 2018-06-05 21:13:11.128628111 -0700 +++ 2/draft-ietf-rmcat-nada-07.txt 2018-06-05 21:13:11.188629555 -0700 @@ -1,26 +1,26 @@ Network Working Group X. Zhu Internet-Draft Cisco Systems Intended status: Experimental R. Pan -Expires: June 6, 2018 Pensando Systems +Expires: December 7, 2018 Pensando Systems M. Ramalho S. Mena P. Jones J. Fu Cisco Systems S. D'Aronco EPFL - December 3, 2017 + June 5, 2018 NADA: A Unified Congestion Control Scheme for Real-Time Media - draft-ietf-rmcat-nada-06 + draft-ietf-rmcat-nada-07 Abstract This document describes NADA (network-assisted dynamic adaptation), a novel congestion control scheme for interactive real-time media applications, such as video conferencing. In the proposed scheme, the sender regulates its sending rate based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from explicit congestion notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the @@ -35,25 +35,25 @@ 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 June 6, 2018. + This Internet-Draft will expire on December 7, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + Copyright (c) 2018 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 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 @@ -79,24 +79,25 @@ 5.3. Feedback Message Requirements . . . . . . . . . . . . . . 15 6. Discussions and Further Investigations . . . . . . . . . . . 16 6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 16 6.2. Method for delay, loss, and marking ratio estimation . . 16 6.3. Impact of parameter values . . . . . . . . . . . . . . . 17 6.4. Sender-based vs. receiver-based calculation . . . . . . . 18 6.5. Incremental deployment . . . . . . . . . . . . . . . . . 18 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 - 11.2. Informative References . . . . . . . . . . . . . . . . . 20 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 + 12.2. Informative References . . . . . . . . . . . . . . . . . 21 Appendix A. Network Node Operations . . . . . . . . . . . . . . 23 A.1. Default behavior of drop tail queues . . . . . . . . . . 23 A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 23 A.3. Random Early Marking with Virtual Queues . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction Interactive real-time media applications introduce a unique set of challenges for congestion control. Unlike TCP, the mechanism used @@ -120,22 +121,24 @@ path round-trip-times (RTTs) below a prescribed bound (e.g., 250ms with default parameter choices). It further supports weighted bandwidth sharing among competing video flows with different priorities. The signaling mechanism consists of standard RTP timestamp [RFC3550] and RTCP feedback reports with non-standard messages. 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 [RFC2119]. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. 3. System Overview Figure 1 shows the end-to-end system for real-time media transport that NADA operates in. Note that there also exist network nodes along the reverse (potentially uncongested) path that the RTCP feedback reports traverse. Those network nodes are not shown in the figure for sake of abrevity. +---------+ r_vin +--------+ +--------+ +----------+ @@ -324,21 +327,21 @@ update baseline delay: d_base = min(d_base, d_fwd) update queuing delay: d_queue = d_fwd - d_base update packet loss ratio estimate p_loss update packet marking ratio estimate p_mark update measurement of receiving rate r_recv On time to send a new feedback report (t_curr - t_last > DELTA): calculate non-linear warping of delay d_tilde if packet loss exists calculate current aggregate congestion signal x_curr determine mode of rate adaptation for sender: rmode - send RTCP feedback report containing values of: rmode, x_curr, and r_recv + send feedback containing values of: rmode, x_curr, and r_recv update t_last = t_curr In order for a delay-based flow to hold its ground when competing against loss-based flows (e.g., loss-based TCP), it is important to distinguish between different levels of observed queuing delay. For instance, over wired connections, a moderate queuing delay value below 100ms is likely self-inflicted or induced by other delay-based flows, whereas a high queuing delay value of several hundreds of milliseconds may indicate the presence of a loss-based flow that does not refrain from increased delay. @@ -372,21 +375,23 @@ Estimation of the average loss interval loss_int, in turn, follows Section 5.4 of the TCP Friendly Rate Control (TFRC) protocol [RFC5348]. In practice, it is recommended to linearly interpolate between the warped (d_tilde) and non-warped (d_queue) values of the queuing delay during the transitional period lasting for the duration of loss_int. The aggregate congestion signal is: - x_curr = d_tilde + DMARK*(p_mark/PMRREF)^2 + DLOSS*(p_loss/PLRREF)^2. (2) + / p_mark \^2 / p_loss \^2 + x_curr = d_tilde + DMARK*|--------| + DLOSS*|--------|. (2) + \ PMRREF / \ PLRREF / Here, DMARK is prescribed reference delay penalty associated with ECN markings at the reference marking ratio of PMRREF; DLOSS is prescribed reference delay penalty associated with packet losses at the reference packet loss ratio of PLRREF. The value of DLOSS and DMARK does not depend on configurations at the network node. Since ECN-enabled active queue management schemes typically mark a packet before dropping it, the value of DLOSS SHOULD be higher than that of DMARK. Furthermore, the values of DLOSS and DMARK need to be set consistently across all NADA flows for them to compete fairly. @@ -420,21 +425,22 @@ on receiving feedback report: obtain current timestamp from system clock: t_curr obtain values of rmode, x_curr, and r_recv from feedback report update estimation of rtt measure feedback interval: delta = t_curr - t_last if rmode == 0: update r_ref following accelerated ramp-up rules else: update r_ref following gradual update rules - clip rate r_ref within the range of [RMIN, RMAX] + clip rate r_ref within the range of minimum rate (RMIN) + and maximum rate (RMAX). x_prev = x_curr t_last = t_curr In accelerated ramp-up mode, the rate r_ref is updated as follows: QBOUND gamma = min(GAMMA_MAX, ------------------) (3) rtt+DELTA+DFILT r_ref = max(r_ref, (1+gamma) r_recv) (4) @@ -468,22 +474,23 @@ Calculation of x_offset depends on maximum rate of the flow (RMAX), its weight of priority (PRIO), as well as a reference congestion signal (XREF). The value of XREF is chosen so that the maximum rate of RMAX can be achieved when the observed congestion signal level is below PRIO*XREF. At equilibrium, the aggregated congestion signal stablizes at x_curr = PRIO*XREF*RMAX/r_ref. This ensures that when multiple flows share the same bottleneck and observe a common value of x_curr, their rates at equilibrium will be proportional to their respective priority - levels (PRIO) and maximum rate (RMAX). Values of RMIN and RMAX will - be provided by the media codec, as specified in + levels (PRIO) and the range between minimum and maximum rate. Values + of the minimum rate (RMIN) and maximum rate (RMAX) will be provided + by the media codec, as specified in [I-D.ietf-rmcat-cc-codec-interactions]. In the absense of such information, NADA sender will choose a default value of 0 for RMIN, and 2Mbps for RMAX. As mentioned in the sender-side algorithm, the final rate is clipped within the dynamic range specified by the application: r_ref = min(r_ref, RMAX) (8) r_ref = max(r_ref, RMIN) (9) @@ -848,33 +855,37 @@ cellular networks such as 3G/LTE. o Experiments with various media source contents, including audio only, audio and video, and application content sharing (e.g., slide shows). 9. IANA Considerations This document makes no request of IANA. -10. Acknowledgements +10. Security Considerations + + TBD + +11. Acknowledgements The authors would like to thank Randell Jesup, Luca De Cicco, Piers O'Hanlon, Ingemar Johansson, Stefan Holmer, Cesar Ilharco Magalhaes, Safiqul Islam, Michael Welzl, Mirja Kuhlewind, Karen Elisabeth Egede Nielsen, Julius Flohr, Roland Bless, and Andreas Smas for their various valuable review comments and feedback. Thanks to Charles Ganzhorn for contributing to the testbed-based evaluation of NADA during an early stage of its development. -11. References +12. References -11.1. Normative 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, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . @@ -887,21 +898,25 @@ [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, . [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, . -11.2. Informative References + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + +12.2. Informative References [Budzisz-TON11] Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and R. Shorten, "On the Fair Coexistence of Loss- and Delay- Based TCP", IEEE/ACM Transactions on Networking vol. 19, no. 6, pp. 1811-1824, December 2011. [Floyd-CCR00] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "Equation-based Congestion Control for Unicast @@ -920,21 +935,21 @@ requirements-09 (work in progress), December 2014. [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-05 (work in progress), April 2017. [I-D.ietf-rmcat-video-traffic-model] Zhu, X., Cruz, S., and Z. Sarker, "Modeling Video Traffic Sources for RMCAT Evaluations", draft-ietf-rmcat-video- - traffic-model-03 (work in progress), July 2017. + traffic-model-04 (work in progress), January 2018. [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. [IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan, "NADA Update: Algorithm, Implementation, and Test Case Evalua6on Results", July 2014, @@ -955,39 +970,36 @@ [ns-2] "The Network Simulator - ns-2", . [ns-3] "The Network Simulator - ns-3", . [ns3-rmcat] Fu, J., Mena, S., and X. Zhu, "NS3 open source module of IETF RMCAT congestion control protocols", November 2017, . - [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, - S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., - Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, - S., Wroclawski, J., and L. Zhang, "Recommendations on - Queue Management and Congestion Avoidance in the - Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, - . - [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI 10.17487/RFC6660, July 2012, . [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, . + [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF + Recommendations Regarding Active Queue Management", + BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, + . + [Zhu-PV13] Zhu, X. and R. Pan, "NADA: A Unified Congestion Control Scheme for Low-Latency Interactive Video", in Proc. IEEE International Packet Video Workshop (PV'13) San Jose, CA, USA, December 2013. Appendix A. Network Node Operations NADA can work with different network queue management schemes and does not assume any specific network node operation. As an example, @@ -1006,21 +1018,21 @@ In a conventional network with drop tail or RED queues, congestion is inferred from the estimation of end-to-end delay and/or packet loss. Packet drops at the queue are detected at the receiver, and contributes to the calculation of the aggregated congestion signal x_curr. No special action is required at network node. A.2. RED-based ECN marking In this mode, the network node randomly marks the ECN field in the IP packet header following the Random Early Detection (RED) algorithm - [RFC2309]. Calculation of the marking probability involves the + [RFC7567]. Calculation of the marking probability involves the following steps: on packet arrival: update smoothed queue size q_avg as: q_avg = w*q + (1-w)*q_avg. calculate marking probability p as: / 0, if q < q_lo; |