diff options
Diffstat (limited to 'doc/rfc/rfc8698.txt')
| -rw-r--r-- | doc/rfc/rfc8698.txt | 1389 |
1 files changed, 1389 insertions, 0 deletions
diff --git a/doc/rfc/rfc8698.txt b/doc/rfc/rfc8698.txt new file mode 100644 index 0000000..ac330dc --- /dev/null +++ b/doc/rfc/rfc8698.txt @@ -0,0 +1,1389 @@ + + + + +Internet Engineering Task Force (IETF) X. Zhu +Request for Comments: 8698 Cisco Systems +Category: Experimental R. Pan +ISSN: 2070-1721 Intel Corporation + M. Ramalho + AcousticComms + S. Mena + Cisco Systems + February 2020 + + +Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control + Scheme for Real-Time Media + +Abstract + + This document describes Network-Assisted Dynamic Adaptation (NADA), 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 + absence of such markings by reacting to queuing delays and packet + losses instead. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are candidates for any level of + Internet Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8698. + +Copyright Notice + + Copyright (c) 2020 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 + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. System Overview + 4. Core Congestion Control Algorithm + 4.1. Mathematical Notations + 4.2. Receiver-Side Algorithm + 4.3. Sender-Side Algorithm + 5. Practical Implementation of NADA + 5.1. Receiver-Side Operation + 5.1.1. Estimation of One-Way Delay and Queuing Delay + 5.1.2. Estimation of Packet Loss/Marking Ratio + 5.1.3. Estimation of Receiving Rate + 5.2. Sender-Side Operation + 5.2.1. Rate-Shaping Buffer + 5.2.2. Adjusting Video Target Rate and Sending Rate + 5.3. Feedback Message Requirements + 6. Discussions and Further Investigations + 6.1. Choice of Delay Metrics + 6.2. Method for Delay, Loss, and Marking Ratio Estimation + 6.3. Impact of Parameter Values + 6.4. Sender-Based vs. Receiver-Based Calculation + 6.5. Incremental Deployment + 7. Reference Implementations + 8. Suggested Experiments + 9. IANA Considerations + 10. Security Considerations + 11. References + 11.1. Normative References + 11.2. Informative References + Appendix A. Network Node Operations + A.1. Default Behavior of Drop-Tail Queues + A.2. RED-Based ECN Marking + A.3. Random Early Marking with Virtual Queues + Acknowledgments + Contributors + Authors' Addresses + +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 + congestion notification (ECN) [RFC3168] markings. The requirements + for the congestion control algorithm are outlined in [RMCAT-CC]. The + requirements highlight that the desired congestion control scheme + should 1) avoid flow starvation and attain a reasonable fair share of + bandwidth when competing against other flows, 2) adapt quickly, and + 3) operate in a stable manner. + + This document describes an experimental congestion control scheme + called Network-Assisted Dynamic Adaptation (NADA). The design of + NADA 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., 250 ms + with default parameter choices). It further supports weighted + bandwidth sharing among competing video flows with different + priorities. The signaling mechanism consists of standard Real-time + Transport Protocol (RTP) timestamp [RFC3550] and Real-time Transport + Control Protocol (RTCP) feedback reports. The definition of the + desired RTCP feedback message is described in detail in + [RTCP-FEEDBACK] 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 + + 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 the sake of brevity. + + +---------+ r_vin +--------+ +--------+ +----------+ + | Media |<--------| RTP | |Network | | RTP | + | Encoder |========>| Sender |=======>| Node |====>| Receiver | + +---------+ r_vout +--------+ r_send +--------+ +----------+ + /|\ | + | | + +---------------------------------+ + RTCP Feedback Report + + Figure 1: System Overview + + Media encoder with rate control capabilities: Encodes raw media + (audio and video) frames into a compressed bitstream that is later + packetized into RTP packets. As discussed in [RFC8593], the + actual output rate from the encoder r_vout may fluctuate around + the target r_vin. Furthermore, it is possible that the encoder + can only react to bit rate changes at rather coarse time + intervals, e.g., once every 0.5 seconds. + + RTP sender: Responsible for calculating the NADA reference rate + based on network congestion indicators (delay, loss, or ECN + marking reports from the receiver), for updating the video encoder + with a new target rate r_vin and for regulating the actual sending + rate r_send accordingly. The RTP sender also generates a sending + timestamp for each outgoing packet. + + RTP receiver: Responsible for measuring and estimating end-to-end + delay (based on sender timestamp), packet loss (based on RTP + sequence number), ECN marking ratios (based on [RFC6679]), and + receiving rate (r_recv) of the flow. It calculates the aggregated + congestion signal (x_curr) that accounts for queuing delay, ECN + markings, and packet losses. The receiver also determines the + mode for sender rate adaptation (rmode) based on whether the flow + has encountered any standing non-zero congestion. The receiver + sends periodic RTCP reports back to the sender, containing values + of x_curr, rmode, and r_recv. + + Network node with several modes of operation: The system can work + with the default behavior of a simple drop-tail queue. It can + also benefit from advanced Active Queue Management (AQM) features + such as Proportional Integral Controller Enhanced (PIE) [RFC8033], + Flow Queue Controlling Queue Delay (FQ-CoDel) [RFC8290], ECN + marking based on Random Early Detection (RED) [RFC7567], and Pre- + Congestion Notification (PCN) marking using a token bucket + algorithm [RFC6660]. Note that network node operation is out of + scope for the design of NADA. + +4. Core Congestion Control Algorithm + + Like TCP-Friendly Rate Control (TFRC) [FLOYD-CCR00] [RFC5348], NADA + is a rate-based congestion control algorithm. In its simplest form, + the sender reacts to the collection of network congestion indicators + in the form of an aggregated congestion signal and operates in one of + two modes: + + Accelerated ramp up: When the bottleneck is deemed to be + underutilized, the rate increases multiplicatively with respect to + the rate of previously successful transmissions. The rate + increase multiplier (gamma) is calculated based on the observed + round-trip time and target feedback interval, so as to limit self- + inflicted queuing delay. + + Gradual rate update: In the presence of a non-zero aggregate + congestion signal, the sending rate is adjusted in reaction to + 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 Sections 5.1 and 5.2. + +4.1. Mathematical Notations + + This section summarizes the list of variables and parameters used in + the NADA algorithm. Table 2 also includes the default values for + choosing the algorithm parameters to represent either a typical + setting in practical applications or a setting based on theoretical + and simulation studies. See Section 6.3 for some of the discussions + on the impact of parameter values. Additional studies in real-world + settings suggested in Section 8 could gather further insight 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 message | + +------------+------------------------------------------------+ + | 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 | + +------------+------------------------------------------------+ + | r_recv | Receiving rate | + +------------+------------------------------------------------+ + | r_vin | Target rate for video encoder | + +------------+------------------------------------------------+ + | r_vout | Output rate from video encoder | + +------------+------------------------------------------------+ + | d_base | Estimated baseline delay | + +------------+------------------------------------------------+ + | d_fwd | Measured and filtered one-way delay | + +------------+------------------------------------------------+ + | d_queue | Estimated queuing delay | + +------------+------------------------------------------------+ + | d_tilde | Equivalent delay after non-linear warping | + +------------+------------------------------------------------+ + | p_mark | Estimated packet ECN marking ratio | + +------------+------------------------------------------------+ + | p_loss | Estimated packet loss ratio | + +------------+------------------------------------------------+ + | x_curr | Aggregate congestion signal | + +------------+------------------------------------------------+ + | x_prev | Previous value of aggregate congestion signal | + +------------+------------------------------------------------+ + | x_diff | Change in aggregate congestion signal w.r.t. | + | | its previous value: x_diff = x_curr - x_prev | + +------------+------------------------------------------------+ + | rmode | Rate update mode: (0 = accelerated ramp up; 1 | + | | = gradual update) | + +------------+------------------------------------------------+ + | gamma | Rate increase multiplier in accelerated ramp- | + | | up mode | + +------------+------------------------------------------------+ + | loss_int | Measured average loss interval in packet count | + +------------+------------------------------------------------+ + | loss_exp | Threshold value for setting the last observed | + | | packet loss to expiration | + +------------+------------------------------------------------+ + | rtt | Estimated round-trip time at sender | + +------------+------------------------------------------------+ + | buffer_len | Rate-shaping buffer occupancy measured in | + | | bytes | + +------------+------------------------------------------------+ + + Table 1: List of Variables + + +-----------+-------------------------------------------+---------+ + | Notation | Parameter Name | Default | + | | | Value | + +===========+===========================================+=========+ + | PRIO | Weight of priority of the flow | 1.0 | + +-----------+-------------------------------------------+---------+ + | RMIN | Minimum rate of application supported by | 150 | + | | media encoder | Kbps | + +-----------+-------------------------------------------+---------+ + | RMAX | Maximum rate of application supported by | 1.5 | + | | media encoder | Mbps | + +-----------+-------------------------------------------+---------+ + | XREF | Reference congestion level | 10 ms | + +-----------+-------------------------------------------+---------+ + | KAPPA | Scaling parameter for gradual rate update | 0.5 | + | | calculation | | + +-----------+-------------------------------------------+---------+ + | ETA | Scaling parameter for gradual rate update | 2.0 | + | | calculation | | + +-----------+-------------------------------------------+---------+ + | TAU | Upper bound of RTT in gradual rate update | 500 ms | + | | calculation | | + +-----------+-------------------------------------------+---------+ + | DELTA | Target feedback interval | 100 ms | + +-----------+-------------------------------------------+---------+ + | LOGWIN | Observation window in time for | 500 ms | + | | calculating packet summary statistics at | | + | | receiver | | + +-----------+-------------------------------------------+---------+ + | QEPS | Threshold for determining queuing delay | 10 ms | + | | buildup at receiver | | + +-----------+-------------------------------------------+---------+ + | DFILT | Bound on filtering delay | 120 ms | + +-----------+-------------------------------------------+---------+ + | GAMMA_MAX | Upper bound on rate increase ratio for | 0.5 | + | | accelerated ramp up | | + +-----------+-------------------------------------------+---------+ + | QBOUND | Upper bound on self-inflicted queuing | 50 ms | + | | delay during ramp up | | + +-----------+-------------------------------------------+---------+ + | MULTILOSS | Multiplier for self-scaling the | 7.0 | + | | expiration threshold of the last observed | | + | | loss (loss_exp) based on measured average | | + | | loss interval (loss_int) | | + +-----------+-------------------------------------------+---------+ + | QTH | Delay threshold for invoking non-linear | 50 ms | + | | warping | | + +-----------+-------------------------------------------+---------+ + | LAMBDA | Scaling parameter in the exponent of non- | 0.5 | + | | linear warping | | + +-----------+-------------------------------------------+---------+ + | PLRREF | Reference packet loss ratio | 0.01 | + +-----------+-------------------------------------------+---------+ + | PMRREF | Reference packet marking ratio | 0.01 | + +-----------+-------------------------------------------+---------+ + | DLOSS | Reference delay penalty for loss when | 10 ms | + | | packet loss ratio is at PLRREF | | + +-----------+-------------------------------------------+---------+ + | DMARK | Reference delay penalty for ECN marking | 2 ms | + | | when packet marking is at PMRREF | | + +-----------+-------------------------------------------+---------+ + | FPS | Frame rate of incoming video | 30 | + +-----------+-------------------------------------------+---------+ + | BETA_S | Scaling parameter for modulating outgoing | 0.1 | + | | sending rate | | + +-----------+-------------------------------------------+---------+ + | BETA_V | Scaling parameter for modulating video | 0.1 | + | | encoder target rate | | + +-----------+-------------------------------------------+---------+ + | ALPHA | Smoothing factor in exponential smoothing | 0.1 | + | | of packet loss and marking ratios | | + +-----------+-------------------------------------------+---------+ + + Table 2: 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 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 + + 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 on + the order of tens of milliseconds 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 < QTH + | + d_tilde = < (1) + | (d_queue-QTH) + \ QTH exp(-LAMBDA ---------------) , otherwise + QTH + + In Equation (1), the queuing delay value is unchanged when it is + below the first threshold QTH; otherwise, it is scaled down following + a non-linear curve. This non-linear warping is inspired by the + delay-adaptive congestion window backoff policy in [BUDZISZ-AIMD-CC] + so as to "gradually nudge" the controller to operate based on loss- + induced congestion signals when competing against loss-based flows. + The exact form of the non-linear function has been simplified with + respect to [BUDZISZ-AIMD-CC]. The value of the threshold QTH should + be carefully tuned for different operational environments so as to + avoid potential risks of prematurely discounting the congestion + signal level. Typically, a higher value of QTH is required in a + noisier environment (e.g., over wireless connections or where the + video stream encounters many time-varying background competing + traffic) so as to stay robust against occasional non-congestion- + induced delay spikes. Additional insights on how this value can be + tuned or auto-tuned should be gathered from carrying out experimental + studies in different real-world deployment scenarios. + + The value of loss_exp is configured to self-scale with the average + packet loss interval loss_int with a multiplier MULTILOSS: + + loss_exp = MULTILOSS * + loss_int. + + Estimation of the average loss interval loss_int, in turn, follows + Section 5.4 of "TCP Friendly Rate Control (TFRC): Protocol + Specification" [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: + + / p_mark \^2 / p_loss \^2 + x_curr = d_tilde + DMARK*|--------| + DLOSS*|--------| (2) + \ PMRREF / \ PLRREF / + + Here, DMARK is prescribed a reference delay penalty associated with + ECN markings at the reference marking ratio of PMRREF; DLOSS is + prescribed a 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 sharing the same bottleneck link + so that they can compete fairly. + + In the absence of packet marking and losses, the value of x_curr + reduces to the observed queuing delay d_queue. In that case, the + NADA algorithm operates in the regime of delay-based adaptation. + + Given observed per-packet delay and loss information, the receiver is + also in a good position to determine whether or not the network is + underutilized and then recommend the corresponding rate adaptation + mode for the sender. The criteria for operating in accelerated ramp- + up mode are: + + * No recent packet losses within the observation window LOGWIN; and + + * No buildup of queuing delay: d_fwd-d_base < QEPS for all previous + delay samples within the observation window LOGWIN. + + Otherwise, the algorithm operates in graduate update mode. + +4.3. Sender-Side Algorithm + + The sender-side algorithm is outlined as follows: + + On initialization: + + set r_ref = RMIN + + set rtt = 0 + + set x_prev = 0 + + set t_last and t_curr as current system clock time + + 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 minimum rate (RMIN) and + maximum rate (RMAX). + + set x_prev = x_curr + + set 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) + + The rate increase multiplier gamma is calculated as a function of the + upper bound of self-inflicted queuing delay (QBOUND), round-trip time + (rtt), and target feedback interval (DELTA); it is bound on the + filtering delay for calculating d_queue (DFILT). It has a maximum + value of GAMMA_MAX. The rationale behind Equations (3)-(4) is that + the longer it takes for the sender to observe self-inflicted queuing + delay buildup, the more conservative the sender should be in + increasing its rate and, hence, the smaller the rate increase + multiplier. + + In gradual update mode, the rate r_ref is updated as: + + x_offset = x_curr - PRIO*XREF*RMAX/r_ref (5) + + x_diff = x_curr - x_prev (6) + + delta x_offset + r_ref = r_ref - KAPPA*-------*------------*r_ref + TAU TAU + + x_diff + - KAPPA*ETA*---------*r_ref (7) + TAU + + The rate changes in proportion to the previous rate decision. It is + affected by two terms: the offset of the aggregate congestion signal + from its value at equilibrium (x_offset) and its change (x_diff). + The calculation of x_offset depends on the 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 stabilizes 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 the range between minimum and maximum rate. Values + of the minimum rate (RMIN) and maximum rate (RMAX) will be provided + by the media codec, for instance, as outlined by [RMCAT-CC-RTP]. In + the absence of such information, the NADA sender will choose a + default value of 0 for RMIN and 3 Mbps for RMAX. + + As mentioned in the sender-side algorithm, the final rate is always + clipped within the dynamic range specified by the application: + + r_ref = min(r_ref, RMAX) (8) + + r_ref = max(r_ref, RMIN) (9) + + The above operations ignore many practical issues such as clock + synchronization between sender and receiver, the filtering of noise + in delay measurements, and base delay expiration. These will be + addressed in Section 5. + +5. Practical Implementation of NADA + +5.1. Receiver-Side Operation + + The receiver continuously monitors end-to-end per-packet statistics + in terms of delay, loss, and/or ECN marking ratios. It then + aggregates all forms of congestion indicators into the form of an + equivalent delay and periodically reports this back to the sender. + In addition, the receiver tracks the receiving rate of the flow and + includes that in the feedback message. + +5.1.1. Estimation of One-Way Delay and Queuing Delay + + The delay estimation process in NADA follows an approach similar to + that of earlier delay-based congestion control schemes, such as Low + Extra Delay Background Transport (LEDBAT) [RFC6817]. For + experimental implementations, instead of relying on RTP timestamps + and the transmission time offset RTP header extension [RFC5450], the + NADA sender can generate its own timestamp based on the local system + clock and embed that information in the transport packet header. The + NADA receiver estimates the forward delay as having a constant base + delay component plus a time-varying queuing delay component. The + base delay is estimated as the minimum value of one-way delay + observed over a relatively long period (e.g., tens of minutes), + whereas the individual queuing delay value is taken to be the + difference between one-way delay and base delay. By re-estimating + the base delay periodically, one can avoid the potential issue of + base delay expiration, whereby an earlier measured base delay value + is no longer valid due to underlying route changes or a cumulative + timing difference introduced by the clock-rate skew between sender + and receiver. All delay estimations are based on sender timestamps + with a recommended granularity of 100 microseconds or finer. + + The individual sample values of queuing delay should be further + filtered against various non-congestion-induced noise, such as spikes + due to a processing "hiccup" at the network nodes. Therefore, in + addition to calculating the value of queuing delay using d_queue = + d_fwd - d_base, as expressed in Section 5.1, the current + implementation further employs a minimum filter with a window size of + 15 samples over per-packet queuing delay values. + +5.1.2. Estimation of Packet Loss/Marking Ratio + + The receiver detects packet losses via gaps in the RTP sequence + numbers of received packets. For interactive real-time media + applications with stringent latency constraints (e.g., video + conferencing), the receiver avoids the packet reordering delay by + treating out-of-order packets as losses. The instantaneous packet + loss ratio p_inst is estimated as the ratio between the number of + missing packets over the number of total transmitted packets within + the recent observation window LOGWIN. The packet loss ratio p_loss + is obtained after exponential smoothing: + + + p_loss = ALPHA*p_inst + (1-ALPHA)*p_loss (10) + + The filtered result is reported back to the sender as the observed + packet loss ratio p_loss. + + The estimation of the packet marking ratio p_mark follows the same + procedure as above. It is assumed that ECN marking information at + the IP header can be passed to the receiving endpoint, e.g., by + following the mechanism described in [RFC6679]. + +5.1.3. Estimation of Receiving Rate + + It is fairly straightforward to estimate the receiving rate r_recv. + NADA maintains a recent observation window with a time span of LOGWIN + and simply divides the total size of packets arriving during that + window over the time span. The receiving rate (r_recv) can be either + calculated at the sender side based on the per-packet feedback from + the receiver or included as part of the feedback report. + +5.2. Sender-Side Operation + + Figure 2 provides a detailed view of the NADA sender. Upon receipt + of an RTCP feedback report from the receiver, the NADA sender + calculates the reference rate r_ref as specified in Section 4.3. It + further adjusts both the target rate for the live video encoder r_vin + and the sending rate r_send over the network based on the updated + value of r_ref and rate-shaping buffer occupancy buffer_len. + + The NADA sender behavior stays the same in the presence of all types + of congestion indicators: delay, loss, and ECN marking. This unified + approach allows a graceful transition of the scheme as the network + shifts dynamically between light and heavy congestion levels. + + +----------------+ + | Calculate | <---- RTCP report + | Reference Rate | + -----------------+ + | r_ref + +------------+-------------+ + | | + \|/ \|/ + +-----------------+ +---------------+ + | Calculate Video | | Calculate | + | Target Rate | | Sending Rate | + +-----------------+ +---------------+ + | /|\ /|\ | + r_vin | | | | + \|/ +-------------------+ | + +----------+ | buffer_len | r_send + | Video | r_vout -----------+ \|/ + | Encoder |--------> |||||||||=================> + +----------+ -----------+ RTP packets + Rate-Shaping Buffer + + Figure 2: NADA Sender Structure + +5.2.1. Rate-Shaping Buffer + + The operation of the live video encoder is out of the scope of the + design for the congestion control scheme in NADA. Instead, its + behavior is treated as a black box. + + A rate-shaping buffer is employed to absorb any instantaneous + mismatch between the encoder rate output r_vout and the regulated + sending rate r_send. Its current level of occupancy is measured in + bytes and is denoted as buffer_len. + + A large rate-shaping buffer contributes to higher end-to-end delay, + which may harm the performance of real-time media communications. + Therefore, the sender has a strong incentive to prevent the rate- + shaping buffer from building up. The mechanisms adopted are: + + * To deplete the rate-shaping buffer faster by increasing the + sending rate r_send; and + + * To limit incoming packets of the rate-shaping buffer by reducing + the video encoder target rate r_vin. + +5.2.2. Adjusting Video Target Rate and Sending Rate + + If the level of occupancy in the rate-shaping buffer is accessible at + the sender, such information can be leveraged to further adjust the + target rate of the live video encoder r_vin as well as the actual + sending rate r_send. The purpose of such adjustments is to mitigate + the additional latencies introduced by the rate-shaping buffer. The + amount of rate adjustment can be calculated as follows: + + r_diff_v = min(0.05*r_ref, BETA_V*8*buffer_len*FPS) (11) + r_diff_s = min(0.05*r_ref, BETA_S*8*buffer_len*FPS) (12) + r_vin = max(RMIN, r_ref - r_diff_v) (13) + r_send = min(RMAX, r_ref + r_diff_s) (14) + + In Equations (11) and (12), the amount of adjustment is calculated as + proportional to the size of the rate-shaping buffer but is bounded by + 5% of the reference rate r_ref calculated from network congestion + feedback alone. This ensures that the adjustment introduced by the + rate-shaping buffer will not counteract with the core congestion + control process. Equations (13) and (14) indicate the influence of + the rate-shaping buffer. A large rate-shaping buffer nudges the + encoder target rate slightly below (and the sending rate slightly + above) the reference rate r_ref. The final video target rate (r_vin) + and sending rate (r_send) are further bounded within the original + range of [RMIN, RMAX]. + + Intuitively, the amount of extra rate offset needed to completely + drain the rate-shaping buffer within the duration of a single video + frame is given by 8*buffer_len*FPS, where FPS stands for the + reference frame rate of the video. The scaling parameters BETA_V and + BETA_S can be tuned to balance between the competing goals of + maintaining a small rate-shaping buffer and deviating from the + reference rate point. Empirical observations show that the rate- + shaping buffer for a responsive live video encoder typically stays + empty and only occasionally holds a large frame (e.g., when an intra- + frame is produced) in transit. Therefore, the rate adjustment + introduced by this mechanism is expected to be minor. For instance, + a rate-shaping buffer of 2000 bytes will lead to a rate adjustment of + 48 Kbps given the recommended scaling parameters of BETA_V = 0.1 and + BETA_S = 0.1, and the reference frame rate of FPS = 30. + +5.3. Feedback Message Requirements + + The following list of information is required for NADA congestion + control to function properly: + + Recommended rate adaptation mode (rmode): A 1-bit flag indicating + whether the sender should operate in accelerated ramp-up mode + (rmode=0) or gradual update mode (rmode=1). + + Aggregated congestion signal (x_curr): The most recently updated + value, calculated by the receiver according to Section 4.2. This + information can be expressed with a unit of 100 microseconds + (i.e., 1/10 of a millisecond) in 15 bits. This allows a maximum + value of x_curr at approximately 3.27 seconds. + + Receiving rate (r_recv): The most recently measured receiving rate + according to Section 5.1.3. This information is expressed with a + unit of bits per second (bps) in 32 bits (unsigned int). This + allows a maximum rate of approximately 4.3 Gbps, approximately + 1000 times the streaming rate of a typical high-definition (HD) + video conferencing session today. This field can be expanded + further by a few more bytes if an even higher rate needs to be + specified. + + The above list of information can be accommodated by 48 bits, or 6 + bytes, in total. They can be either included in the feedback report + from the receiver or, in the case where all receiver-side + calculations are moved to the sender, derived from per-packet + information from the feedback message as defined in [RTCP-FEEDBACK]. + Choosing the feedback message interval DELTA is discussed in + Section 6.3. A target feedback interval of DELTA = 100 ms is + recommended. + +6. Discussions and Further Investigations + + This section discusses the various design choices made by NADA, + potential alternative variants of its implementation, and guidelines + on how the key algorithm parameters can be chosen. Section 8 + recommends additional experimental setups to further explore these + topics. + +6.1. Choice of Delay Metrics + + The current design works with relative one-way delay (OWD) as the + main indication of congestion. The value of the relative OWD is + obtained by maintaining the minimum value of observed OWD over a + relatively long time horizon and subtracting that out from the + observed absolute OWD value. Such an approach cancels out the fixed + difference between the sender and receiver clocks. It has been + widely adopted by other delay-based congestion control approaches + such as [RFC6817]. As discussed in [RFC6817], the time horizon for + tracking the minimum OWD needs to be chosen with care; it must be + long enough for an opportunity to observe the minimum OWD with zero + standing queue along the path, and it must be sufficiently short + enough to timely reflect "true" changes in minimum OWD introduced by + route changes and other rare events and to mitigate the cumulative + impact of clock rate skew over time. + + The potential drawback in relying on relative OWD as the congestion + signal is that when multiple flows share the same bottleneck, the + flow arriving late at the network experiencing a non-empty queue may + mistakenly consider the standing queuing delay as part of the fixed + path propagation delay. This will lead to slightly unfair bandwidth + sharing among the flows. + + Alternatively, one could move the per-packet statistical handling to + the sender instead and use relative round-trip time (RTT) in lieu of + relative OWD, assuming that per-packet acknowledgments are available. + The main drawback of an RTT-based approach is the noise in the + measured delay in the reverse direction. + + Note that the choice of either delay metric (relative OWD vs. RTT) + involves no change in the proposed rate adaptation algorithm. + Therefore, comparing the pros and cons regarding which delay metric + to adopt can be kept as an orthogonal direction of investigation. + +6.2. Method for Delay, Loss, and Marking Ratio Estimation + + Like other delay-based congestion control schemes, performance of + NADA depends on the accuracy of its delay measurement and estimation + module. Appendix A of [RFC6817] provides an extensive discussion on + this aspect. + + The current recommended practice of applying minimum filter with a + window size of 15 samples suffices in guarding against processing + delay outliers observed in wired connections. For wireless + connections with a higher packet delay variation (PDV), more + sophisticated techniques on denoising, outlier rejection, and trend + analysis may be needed. + + More sophisticated methods in packet loss ratio calculation, such as + that adopted by [FLOYD-CCR00], will likely be beneficial. These + alternatives are part of the experiments this document proposes. + +6.3. Impact of Parameter Values + + In the gradual rate update mode, the parameter TAU indicates the + upper bound of round-trip time (RTT) in the feedback control loop. + Typically, the observed feedback interval delta is close to the + target feedback interval DELTA, and the relative ratio of delta/TAU + versus ETA dictates the relative strength of influence from the + aggregate congestion signal offset term (x_offset) versus its recent + change (x_diff), respectively. These two terms are analogous to the + integral and proportional terms in a proportional-integral (PI) + controller. The recommended choice of TAU = 500 ms, DELTA = 100 ms, + and ETA = 2.0 corresponds to a relative ratio of 1:10 between the + gains of the integral and proportional terms. Consequently, the rate + adaptation is mostly driven by the change in the congestion signal + with a long-term shift towards its equilibrium value driven by the + offset term. Finally, the scaling parameter KAPPA determines the + overall speed of the adaptation and needs to strike a balance between + responsiveness and stability. + + The choice of the target feedback interval DELTA needs to strike the + right balance between timely feedback and low RTCP feedback message + counts. A target feedback interval of DELTA = 100 ms is recommended, + corresponding to a feedback bandwidth of 16 Kbps with 200 bytes per + feedback message -- approximately 1.6% overhead for a 1 Mbps flow. + Furthermore, both simulation studies and frequency-domain analysis in + [IETF-95] have established that a feedback interval below 250 ms + (i.e., more frequently than 4 feedback messages per second) will not + break up the feedback control loop of NADA congestion control. + + In calculating the non-linear warping of delay in Equation (1), the + current design uses fixed values of QTH for determining whether to + perform the non-linear warping. Its value should be carefully tuned + for different operational environments (e.g., over wired vs. wireless + connections) so as to avoid the potential risk of prematurely + discounting the congestion signal level. It is possible to adapt its + value based on past observed patterns of queuing delay in the + presence of packet losses. It needs to be noted that the non-linear + warping mechanism may lead to multiple NADA streams stuck in loss- + based mode when competing against each other. + + In calculating the aggregate congestion signal x_curr, the choice of + DMARK and DLOSS influence the steady-state packet loss/marking ratio + experienced by the flow at a given available bandwidth. Higher + values of DMARK and DLOSS result in lower steady-state loss/marking + ratios but are more susceptible to the impact of individual packet + loss/marking events. While the value of DMARK and DLOSS are fixed + and predetermined in the current design, this document also + encourages further explorations of a scheme for automatically tuning + these values based on desired bandwidth sharing behavior in the + presence of other competing loss-based flows (e.g., loss-based TCP). + +6.4. Sender-Based vs. Receiver-Based Calculation + + In the current design, the aggregated congestion signal x_curr is + calculated at the receiver, keeping the sender operation completely + independent of the form of actual network congestion indications + (delay, loss, or marking) in use. + + Alternatively, one can shift receiver-side calculations to the + sender, whereby the receiver simply reports on per-packet information + via periodic feedback messages as defined in [RTCP-FEEDBACK]. Such + an approach enables interoperability amongst senders operating on + different congestion control schemes but requires slightly higher + overhead in the feedback messages. See additional discussions in + [RTCP-FEEDBACK] regarding the desired format of the feedback messages + and the recommended feedback intervals. + +6.5. Incremental Deployment + + One nice property of NADA is the consistent video endpoint behavior + irrespective of network node variations. This facilitates gradual, + incremental adoption of the scheme. + + Initially, the proposed congestion control mechanism can be + implemented without any explicit support from the network and relies + solely on observed relative one-way delay measurements and packet + loss ratios as implicit congestion signals. + + When ECN is enabled at the network nodes with RED-based marking, the + receiver can fold its observations of ECN markings into the + calculation of the equivalent delay. The sender can react to these + explicit congestion signals without any modification. + + Ultimately, networks equipped with proactive marking based on the + level of token bucket metering can reap the additional benefits of + zero standing queues and lower end-to-end delay and work seamlessly + with existing senders and receivers. + +7. Reference Implementations + + The NADA scheme has been implemented in both ns-2 [NS-2] and ns-3 + [NS-3] simulation platforms. The implementation in ns-2 hosts the + calculations as described in Section 4.2 at the receiver side, + whereas the implementation in ns-3 hosts these receiver-side + calculations at the sender for the sake of interoperability. + Extensive ns-2 simulation evaluations of an earlier draft version of + this document are recorded in [ZHU-PV13]. An open-source + implementation of NADA as part of an ns-3 module is available at + [NS3-RMCAT]. Evaluation results of this document based on ns-3 are + presented in [IETF-90] and [IETF-91] for wired test cases as + documented in [RMCAT-EVAL-TEST]. Evaluation results of NADA over Wi- + Fi-based test cases as defined in [WIRELESS-TESTS] are presented in + [IETF-93]. These simulation-based evaluations have shown that NADA + flows can obtain their fair share of bandwidth when competing against + each other. They typically adapt fast in reaction to the arrival and + departure of other flows and can sustain a reasonable throughput when + competing against loss-based TCP flows. + + [IETF-90] describes the implementation and evaluation of NADA in a + lab setting. Preliminary evaluation results of NADA in single-flow + and multi-flow test scenarios are presented in [IETF-91]. + + A reference implementation of NADA has been carried out by modifying + the WebRTC module embedded in the Mozilla open-source browser. + Presentations from [IETF-103] and [IETF-105] document real-world + evaluations of the modified browser driven by NADA. The experimental + setting involves remote connections with endpoints over either home + or enterprise wireless networks. These evaluations validate the + effectiveness of NADA flows in recovering quickly from throughput + drops caused by intermittent delay spikes over the last-hop wireless + connections. + +8. Suggested Experiments + + NADA has been extensively evaluated under various test scenarios, + including the collection of test cases specified by [RMCAT-EVAL-TEST] + and the subset of Wi-Fi-based test cases in [WIRELESS-TESTS]. + Additional evaluations have been carried out to characterize how NADA + interacts with various AQM schemes such as RED, Controlling Queue + Delay (CoDel), and Proportional Integral Controller Enhanced (PIE). + Most of these evaluations have been carried out in simulators. A few + key test cases have been evaluated in lab environments with + implementations embedded in video conferencing clients. It is + strongly recommended to carry out implementation and experimentation + of NADA in real-world settings. Such exercises will provide insights + on how to choose or automatically adapt the values of the key + algorithm parameters (see list in Table 2) as discussed in Section 6. + + Additional experiments are suggested for the following scenarios, + preferably over real-world networks: + + * Experiments reflecting the setup of a typical WAN connection. + + * Experiments with ECN marking capability turned on at the network + for existing test cases. + + * Experiments with multiple NADA streams bearing different user- + specified priorities. + + * Experiments with additional access technologies, especially over + cellular networks such as 3G/LTE. + + * Experiments with various media source contents, including audio + only, audio and video, and application content sharing (e.g., + slideshows). + +9. IANA Considerations + + This document has no IANA actions. + +10. Security Considerations + + The rate adaptation mechanism in NADA relies on feedback from the + receiver. As such, it is vulnerable to attacks where feedback + messages are hijacked, replaced, or intentionally injected with + misleading information resulting in denial of service, similar to + those that can affect TCP. Therefore, it is RECOMMENDED that the + RTCP feedback message is at least integrity checked. In addition, + [RTCP-FEEDBACK] discusses the potential risk of a receiver providing + misleading congestion feedback information and the mechanisms for + mitigating such risks. + + The modification of the sending rate based on the sender-side rate- + shaping buffer may lead to temporary excessive congestion over the + network in the presence of an unresponsive video encoder. However, + this effect can be mitigated by limiting the amount of rate + modification introduced by the rate-shaping buffer, bounding the size + of the rate-shaping buffer at the sender, and maintaining a maximum + allowed sending rate by NADA. + +11. References + +11.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, + <https://www.rfc-editor.org/info/rfc2119>. + + [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, + <https://www.rfc-editor.org/info/rfc3168>. + + [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, <https://www.rfc-editor.org/info/rfc3550>. + + [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, + <https://www.rfc-editor.org/info/rfc5348>. + + [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, <https://www.rfc-editor.org/info/rfc6679>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +11.2. Informative References + + [BUDZISZ-AIMD-CC] + 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, DOI 10.1109/TNET.2011.2159736, + December 2011, + <https://doi.org/10.1109/TNET.2011.2159736>. + + [FLOYD-CCR00] + Floyd, S., Handley, M., Padhye, J., and J. Widmer, + "Equation-based congestion control for unicast + applications", ACM SIGCOMM Computer Communications Review, + vol. 30, no. 4, pp. 43-56, DOI 10.1145/347057.347397, + October 2000, <https://doi.org/10.1145/347057.347397>. + + [IETF-103] Zhu, X., Pan, R., Ramalho, M., Mena, S., Jones, P., Fu, + J., and S. D'Aronco, "NADA Implementation in Mozilla + Browser", IETF 103, November 2018, + <https://datatracker.ietf.org/meeting/103/materials/ + slides-103-rmcat-nada-implementation-in-mozilla-browser- + 00>. + + [IETF-105] Zhu, X., Pan, R., Ramalho, M., Mena, S., Jones, P., Fu, + J., and S. D'Aronco, "NADA Implementation in Mozilla + Browser and Draft Update", IETF 105, July 2019, + <https://datatracker.ietf.org/meeting/105/materials/ + slides-105-rmcat-nada-update-02.pdf>. + + [IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan, + "NADA Update: Algorithm, Implementation, and Test Case + Evaluation Results", IETF 90, July 2014, + <https://tools.ietf.org/agenda/90/slides/slides-90-rmcat- + 6.pdf>. + + [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", IETF 91, November 2014, + <https://www.ietf.org/proceedings/interim/2014/11/09/ + rmcat/slides/slides-interim-2014-rmcat-1-2.pdf>. + + [IETF-93] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C., + Jones, P., D'Aronco, S., and J. Fu, "Updates on NADA", + IETF 93, July 2015, + <https://www.ietf.org/proceedings/93/slides/slides-93- + rmcat-0.pdf>. + + [IETF-95] Zhu, X., Pan, R., Ramalho, M., Mena, S., Jones, P., Fu, + J., D'Aronco, S., and C. Ganzhorn, "Updates on NADA: + Stability Analysis and Impact of Feedback Intervals", IETF + 95, April 2016, + <https://www.ietf.org/proceedings/95/slides/slides-95- + rmcat-5.pdf>. + + [NS-2] "ns-2", December 2014, + <http://nsnam.sourceforge.net/wiki/index.php/Main_Page>. + + [NS-3] "ns-3 Network Simulator", <https://www.nsnam.org/>. + + [NS3-RMCAT] + Fu, J., Mena, S., and X. Zhu, "Simulator of IETF RMCAT + congestion control protocols", November 2017, + <https://github.com/cisco/ns3-rmcat>. + + [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in + RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009, + <https://www.rfc-editor.org/info/rfc5450>. + + [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, + <https://www.rfc-editor.org/info/rfc6660>. + + [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, + "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, + DOI 10.17487/RFC6817, December 2012, + <https://www.rfc-editor.org/info/rfc6817>. + + [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF + Recommendations Regarding Active Queue Management", + BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, + <https://www.rfc-editor.org/info/rfc7567>. + + [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, + "Proportional Integral Controller Enhanced (PIE): A + Lightweight Control Scheme to Address the Bufferbloat + Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, + <https://www.rfc-editor.org/info/rfc8033>. + + [RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, + J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler + and Active Queue Management Algorithm", RFC 8290, + DOI 10.17487/RFC8290, January 2018, + <https://www.rfc-editor.org/info/rfc8290>. + + [RFC8593] Zhu, X., Mena, S., and Z. Sarker, "Video Traffic Models + for RTP Congestion Control Evaluations", RFC 8593, + DOI 10.17487/RFC8593, May 2019, + <https://www.rfc-editor.org/info/rfc8593>. + + [RMCAT-CC] Jesup, R. and Z. Sarker, "Congestion Control Requirements + for Interactive Real-Time Media", Work in Progress, + Internet-Draft, draft-ietf-rmcat-cc-requirements-09, 12 + December 2014, <https://tools.ietf.org/html/draft-ietf- + rmcat-cc-requirements-09>. + + [RMCAT-CC-RTP] + Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, + "Congestion Control and Codec interactions in RTP + Applications", Work in Progress, Internet-Draft, draft- + ietf-rmcat-cc-codec-interactions-02, 18 March 2016, + <https://tools.ietf.org/html/draft-ietf-rmcat-cc-codec- + interactions-02>. + + [RMCAT-EVAL-TEST] + Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test + Cases for Evaluating RMCAT Proposals", Work in Progress, + Internet-Draft, draft-ietf-rmcat-eval-test-10, 23 May + 2019, <https://tools.ietf.org/html/draft-ietf-rmcat-eval- + test-10>. + + [RTCP-FEEDBACK] + Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP + Control Protocol (RTCP) Feedback for Congestion Control", + Work in Progress, Internet-Draft, draft-ietf-avtcore-cc- + feedback-message-05, 4 November 2019, + <https://tools.ietf.org/html/draft-ietf-avtcore-cc- + feedback-message-05>. + + [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", Work in Progress, + Internet-Draft, draft-ietf-rmcat-wireless-tests-08, 5 July + 2019, <https://tools.ietf.org/html/draft-ietf-rmcat- + wireless-tests-08>. + + [ZHU-PV13] Zhu, X. and R. Pan, "NADA: A Unified Congestion Control + Scheme for Low-Latency Interactive Video", Proc. IEEE + International Packet Video Workshop, San Jose, CA, USA, + DOI 10.1109/PV.2013.6691448, December 2013, + <https://doi.org/10.1109/PV.2013.6691448>. + +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, + this appendix describes three variants of queue management behavior + at the network node, leading to either implicit or explicit + congestion signals. It needs to be acknowledged that NADA has not + yet been tested with non-probabilistic ECN marking behaviors. + + In all three flavors described below, the network queue operates with + the simple First In, First Out (FIFO) principle. There is no need to + maintain per-flow state. The system can scale easily with a large + number of video flows and at high link capacity. + +A.1. Default Behavior of Drop-Tail Queues + + 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 contribute + to the calculation of the aggregated congestion signal x_curr. No + special action is required at the 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 + [RFC7567]. Calculation of the marking probability involves the + following steps on packet arrival: + + 1. update smoothed queue size q_avg as: + + q_avg = w*q + (1-w)*q_avg + + 2. calculate marking probability p as: + + / 0, if q < q_lo + | + | q_avg - q_lo + p= < p_max*--------------, if q_lo <= q < q_hi + | q_hi - q_lo + | + \ p = 1, if q >= q_hi + + Here, q_lo and q_hi correspond to the low and high thresholds of + queue occupancy. The maximum marking probability is p_max. + + The ECN marking events will contribute to the calculation of an + equivalent delay x_curr at the receiver. No changes are required at + the sender. + +A.3. Random Early Marking with Virtual Queues + + Advanced network nodes may support random early marking based on a + token bucket algorithm originally designed for Pre-Congestion + Notification (PCN) [RFC6660]. The early congestion notification + (ECN) bit in the IP header of packets is marked randomly. The + marking probability is calculated based on a token bucket algorithm + originally designed for PCN [RFC6660]. The target link utilization + is set as 90%; the marking probability is designed to grow linearly + with the token bucket size when it varies between 1/3 and 2/3 of the + full token bucket limit. + + Calculation of the marking probability involves the following steps + upon packet arrival: + + 1. meter packet against token bucket (r,b) + + 2. update token level b_tk + + 3. calculate the marking probability as: + + / 0, if b-b_tk < b_lo + | + | b-b_tk-b_lo + p = < p_max* --------------, if b_lo <= b-b_tk < b_hi + | b_hi-b_lo + | + \ 1, if b-b_tk >= b_hi + + Here, the token bucket lower and upper limits are denoted by b_lo and + b_hi, respectively. The parameter b indicates the size of the token + bucket. The parameter r is chosen to be below capacity, resulting in + slight underutilization of the link. The maximum marking probability + is p_max. + + The ECN marking events will contribute to the calculation of an + equivalent delay x_curr at the receiver. No changes are required at + the sender. The virtual queuing mechanism from the PCN-based marking + algorithm will lead to additional benefits such as zero standing + queues. + +Acknowledgments + + 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 Kühlewind, Karen Elisabeth Egede + Nielsen, Julius Flohr, Roland Bless, Andreas Smas, and Martin + Stiemerling for their valuable review comments and helpful input to + this specification. + +Contributors + + The following individuals contributed to the implementation and + evaluation of the proposed scheme and, therefore, helped to validate + and substantially improve this specification. + + Paul E. Jones <paulej@packetizer.com> of Cisco Systems implemented an + early version of the NADA congestion control scheme and helped with + its lab-based testbed evaluations. + + Jiantao Fu <jianfu@cisco.com> of Cisco Systems helped with the + implementation and extensive evaluation of NADA both in Mozilla web + browsers and in earlier simulation-based evaluation efforts. + + Stefano D'Aronco <stefano.daronco@geod.baug.ethz.ch> of ETH Zurich + (previously at Ecole Polytechnique Federale de Lausanne when + contributing to this work) helped with the implementation and + evaluation of an early version of NADA in [NS-3]. + + Charles Ganzhorn <charles.ganzhorn@gmail.com> contributed to the + testbed-based evaluation of NADA during an early stage of its + development. + +Authors' Addresses + + Xiaoqing Zhu + Cisco Systems + 12515 Research Blvd., Building 4 + Austin, TX 78759 + United States of America + + Email: xiaoqzhu@cisco.com + + + Rong Pan + Intel Corporation + 2200 Mission College Blvd + Santa Clara, CA 95054 + United States of America + + Email: rong.pan@intel.com + + + Michael A. Ramalho + AcousticComms Consulting + 6310 Watercrest Way Unit 203 + Lakewood Ranch, FL 34202-5211 + United States of America + + Phone: +1 732 832 9723 + Email: mar42@cornell.edu + URI: http://ramalho.webhop.info/ + + + Sergio Mena + Cisco Systems + EPFL, Quartier de l'Innovation, Batiment E + CH-1015 Ecublens + Switzerland + + Email: semena@cisco.com |