--- 1/draft-ietf-rmcat-nada-08.txt 2018-08-03 09:13:18.458294673 -0700 +++ 2/draft-ietf-rmcat-nada-09.txt 2018-08-03 09:13:18.514296018 -0700 @@ -1,24 +1,24 @@ Network Working Group X. Zhu Internet-Draft R. Pan Intended status: Experimental M. Ramalho -Expires: January 3, 2019 S. Mena +Expires: February 4, 2019 S. Mena P. Jones J. Fu Cisco Systems S. D'Aronco EPFL - July 2, 2018 + August 3, 2018 NADA: A Unified Congestion Control Scheme for Real-Time Media - draft-ietf-rmcat-nada-08 + draft-ietf-rmcat-nada-09 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 @@ -33,21 +33,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 January 3, 2019. + This Internet-Draft will expire on February 4, 2019. Copyright Notice 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 @@ -59,48 +59,48 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 3 4. Core Congestion Control Algorithm . . . . . . . . . . . . . . 5 4.1. Mathematical Notations . . . . . . . . . . . . . . . . . 5 4.2. Receiver-Side Algorithm . . . . . . . . . . . . . . . . . 8 4.3. Sender-Side Algorithm . . . . . . . . . . . . . . . . . . 10 - 5. Practical Implementation of NADA . . . . . . . . . . . . . . 12 - 5.1. Receiver-Side Operation . . . . . . . . . . . . . . . . . 12 - 5.1.1. Estimation of one-way delay and queuing delay . . . . 12 + 5. Practical Implementation of NADA . . . . . . . . . . . . . . 13 + 5.1. Receiver-Side Operation . . . . . . . . . . . . . . . . . 13 + 5.1.1. Estimation of one-way delay and queuing delay . . . . 13 5.1.2. Estimation of packet loss/marking ratio . . . . . . . 13 - 5.1.3. Estimation of receiving rate . . . . . . . . . . . . 13 - 5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 13 - 5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 14 - 5.2.2. Adjusting video target rate and sending rate . . . . 15 - 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. 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 + 5.1.3. Estimation of receiving rate . . . . . . . . . . . . 14 + 5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 14 + 5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 15 + 5.2.2. Adjusting video target rate and sending rate . . . . 16 + 5.3. Feedback Message Requirements . . . . . . . . . . . . . . 16 + 6. Discussions and Further Investigations . . . . . . . . . . . 17 + 6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 17 + 6.2. Method for delay, loss, and marking ratio estimation . . 18 + 6.3. Impact of parameter values . . . . . . . . . . . . . . . 18 + 6.4. Sender-based vs. receiver-based calculation . . . . . . . 19 + 6.5. Incremental deployment . . . . . . . . . . . . . . . . . 19 + 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 + 8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 20 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 12.2. Informative References . . . . . . . . . . . . . . . . . 22 + Appendix A. Network Node Operations . . . . . . . . . . . . . . 24 + A.1. Default behavior of drop tail queues . . . . . . . . . . 24 + A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 24 + A.3. Random Early Marking with Virtual Queues . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction Interactive real-time media applications introduce a unique set of challenges for congestion control. Unlike TCP, the mechanism used for real-time media needs to adapt quickly to instantaneous bandwidth changes, accommodate fluctuations in the output of video encoder rate control, and cause low queuing delay over the network. An ideal scheme should also make effective use of all types of congestion signals, including packet loss, queuing delay, and explicit @@ -113,22 +113,24 @@ benefits from explicit congestion control signals (e.g., ECN markings) from the network, yet also operates when only implicit congestion indicators (delay and/or loss) are available. Such a unified sender behavior distinguishes NADA from other congestion control schemes for real-time media. In addition, its core congestion control algorithm is designed to guarantee stability for 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. + timestamp [RFC3550] and RTCP feedback reports. The definition of + standardized RTCP feedback message requires future work so as to + support the successful operation of several congestion control + schemes for real-time interactive media. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "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 @@ -204,21 +206,28 @@ both its value (x_curr) and its change in value (x_diff). This section introduces the list of mathematical notations and describes the core congestion control algorithm at the sender and receiver, respectively. Additional details on recommended practical implementations are described in Section 5.1 and Section 5.2. 4.1. Mathematical Notations This section summarizes the list of variables and parameters used in - the NADA algorithm. + the NADA algorithm. Figure 3 also includes the default values for + choosing the algorithm parameters either to represent a typical + setting in practical applications or based on theoretical and + simulation studies. See Section 6.3 for some of the discussions on + the impact of parameter values. In the experimental phase of this + draft, additional studies in real-world settings will gather further + learnings on how to choose and adapt these parameter values in + practical deployment. +--------------+-------------------------------------------------+ | Notation | Variable Name | +--------------+-------------------------------------------------+ | t_curr | Current timestamp | | t_last | Last time sending/receiving a feedback | | delta | Observed interval between current and previous | | | feedback reports: delta = t_curr-t_last | | r_ref | Reference rate based on network congestion | | r_send | Sending rate | @@ -298,32 +307,32 @@ | FPS | Frame rate of incoming video | 30 | | BETA_S | Scaling parameter for modulating | 0.1 | | | outgoing sending rate | | | BETA_V | Scaling parameter for modulating | 0.1 | | | video encoder target rate | | | ALPHA | Smoothing factor in exponential | 0.1 | | | smoothing of packet loss and | | | | marking ratios | +--------------+----------------------------------+----------------+ - Figure 3: List of algorithm parameters. + Figure 3: List of algorithm parameters and their default values. 4.2. Receiver-Side Algorithm The receiver-side algorithm can be outlined as below: On initialization: set d_base = +INFINITY set p_loss = 0 set p_mark = 0 set r_recv = 0 - set both t_last and t_curr as current time + set both t_last and t_curr as current time in milliseconds On receiving a media packet: obtain current timestamp t_curr from system clock obtain from packet header sending time stamp t_sent obtain one-way delay measurement: d_fwd = t_curr - t_sent 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 @@ -331,46 +340,53 @@ 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 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. + instance, over wired connections, a moderate queuing delay value on + the order of tens of milliseonds 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. If the last observed packet loss is within the expiration window of loss_exp (measured in terms of packet counts), the estimated queuing delay follows a non-linear warping: / d_queue, if d_queue. [IETF-91] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C., Jones, P., and S. D'Aronco, "NADA Algorithm Update and Test Case Evaluations", November 2014,