[要約] 要約：RFC 8698は、リアルタイムメディアのための統一された輻輳制御スキームであるNADAについて説明しています。 目的：NADAは、リアルタイムメディアの品質を向上させるために、ネットワークの輻輳制御を効果的に行うことを目指しています。
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
Network-Assisted Dynamic Adaptation（NADA）：リアルタイムメディアの統合型輻輳制御方式
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.
このドキュメントでは、ビデオ会議などのインタラクティブなリアルタイムメディアアプリケーション向けの新しい輻輳制御方式であるネットワーク支援動的適応（NADA）について説明します。提案された方式では、送信者は、統合されたアプローチで、暗黙的または明示的な輻輳シグナリングに基づいて送信レートを調整します。このスキームは、ネットワークノードからの明示的輻輳通知（ECN）マーキングの恩恵を受けることができます。また、そのようなマーキングがない場合でも、代わりにキューイング遅延とパケット損失に反応することにより、一貫した送信者の動作を維持します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。これは公開レビューを受けており、Internet Engineering Steering Group（IESG）による公開が承認されています。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
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.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、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.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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
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.
インタラクティブなリアルタイムメディアアプリケーションは、輻輳制御に固有の一連の課題をもたらします。 TCPとは異なり、リアルタイムメディアに使用されるメカニズムは、帯域幅の瞬間的な変化にすばやく適応し、ビデオエンコーダレート制御の出力の変動に対応し、ネットワーク上でのキューイング遅延を低くする必要があります。理想的な方式では、パケット損失、キューイング遅延、明示的輻輳通知（ECN）[RFC3168]マーキングなど、あらゆる種類の輻輳信号を効果的に使用する必要があります。輻輳制御アルゴリズムの要件は、[RMCAT-CC]で概説されています。要件は、望ましい輻輳制御方式が1）フローの枯渇を回避し、他のフローと競合する場合に帯域幅の合理的な公平な共有を達成すること、2）迅速に適応すること、および3）安定した方法で動作することを強調しています。
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.
このドキュメントでは、Network-Assisted Dynamic Adaptation（NADA）と呼ばれる実験的な輻輳制御方式について説明します。 NADAの設計は、ネットワークからの明示的な輻輳制御信号（ECNマーキングなど）の恩恵を受けるだけでなく、暗黙的な輻輳インジケータ（遅延や損失）しか利用できない場合にも機能します。このような統合された送信側の動作は、NADAを他のリアルタイムメディアの輻輳制御方式と区別します。さらに、そのコア輻輳制御アルゴリズムは、規定の範囲（デフォルトのパラメーター選択で250ミリ秒など）未満のパスラウンドトリップ時間（RTT）の安定性を保証するように設計されています。さらに、優先順位の異なる競合するビデオフロー間での重み付き帯域幅共有をサポートします。シグナリングメカニズムは、標準のリアルタイムトランスポートプロトコル（RTP）タイムスタンプ[RFC3550]とリアルタイムトランスポートコントロールプロトコル（RTCP）フィードバックレポートで構成されます。リアルタイムインタラクティブメディアのいくつかの輻輳制御方式の正常な動作をサポートするために、目的のRTCPフィードバックメッセージの定義は[RTCP-FEEDBACK]で詳細に説明されています。
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
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.
図1は、NADAが動作するリアルタイムメディアトランスポートのエンドツーエンドシステムを示しています。RTCPフィードバックレポートが通過する逆の（輻輳していない可能性がある）パスに沿ってネットワークノードも存在することに注意してください。これらのネットワークノードは、簡潔にするために図には示されていません。
+---------+ r_vin +--------+ +--------+ +----------+
| Media |<--------| RTP | |Network | | RTP |
| Encoder |========>| Sender |=======>| Node |====>| Receiver |
+---------+ r_vout +--------+ r_send +--------+ +----------+
/|\ |
| |
+---------------------------------+
RTCP Feedback Report
Figure 1: System Overview
図1：システムの概要
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パケットにパケット化される圧縮ビットストリームにエンコードします。 [RFC8593]で説明されているように、エンコーダーr_voutからの実際の出力レートは、ターゲットr_vinの前後で変動する可能性があります。さらに、エンコーダーがかなり粗い時間間隔で、たとえば0.5秒ごとに1回だけビットレートの変更に反応できる可能性があります。
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送信者：ネットワークの輻輳インジケーター（受信者からの遅延、損失、またはECNマーキングレポート）に基づいてNADA参照レートを計算し、ビデオエンコーダーを新しいターゲットレートr_vinで更新し、それに応じて実際の送信レートr_sendを調整します。 RTP送信側は、各送信パケットの送信タイムスタンプも生成します。
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.
RTPレシーバー：エンドツーエンドの遅延（送信者のタイムスタンプに基づく）、パケット損失（RTPシーケンス番号に基づく）、ECNマーキング率（[RFC6679]に基づく）、および受信レート（r_recv）の測定と推定を担当フロー。キューイング遅延、ECNマーキング、およびパケット損失を考慮した集約された輻輳信号（x_curr）を計算します。受信者は、フローがゼロ以外の永続的な輻輳に遭遇したかどうかに基づいて、送信者レート適応のモード（rmode）も決定します。受信者は、x_curr、rmode、およびr_recvの値を含む定期的なRTCPレポートを送信者に送り返します。
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.
いくつかの動作モードを持つネットワークノード：システムは、単純なドロップテールキューのデフォルトの動作で動作します。また、Proportional Integral Controller Enhanced（PIE）[RFC8033]、フローキュー制御キュー遅延（FQ-CoDel）[RFC8290]、ランダム早期検出（RED）に基づくECNマーキングなどの高度なアクティブキュー管理（AQM）機能も利用できます。 [RFC7567]、およびトークンバケットアルゴリズムを使用した事前輻輳通知（PCN）マーキング[RFC6660]。ネットワークノード操作はNADAの設計の範囲外であることに注意してください。
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:
TCPフレンドリーレートコントロール（TFRC）[FLOYD-CCR00] [RFC5348]と同様に、NADAはレートベースの輻輳制御アルゴリズムです。最も単純な形式では、送信者はネットワークの輻輳インジケーターの集合に集約された輻輳信号の形で反応し、次の2つのモードのいずれかで動作します。
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).
段階的なレートの更新：ゼロ以外の集約輻輳信号が存在する場合、送信レートはその値（x_curr）と値の変化（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.
このセクションでは、数学的表記のリストを紹介し、送信側と受信側のそれぞれのコア輻輳制御アルゴリズムについて説明します。推奨される実際の実装の詳細については、セクション5.1および5.2で説明します。
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.
このセクションでは、NADAアルゴリズムで使用される変数とパラメーターのリストを要約します。表2には、実用的なアプリケーションの一般的な設定、または理論的研究とシミュレーション研究に基づく設定のいずれかを表すアルゴリズムパラメーターを選択するためのデフォルト値も含まれています。パラメータ値の影響に関するいくつかの説明については、セクション6.3を参照してください。セクション8で提案された実際の設定での追加の調査により、これらのパラメーター値を実際に展開して選択および適応する方法についてさらに洞察を得ることができます。
+------------+------------------------------------------------+
| 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
表1：変数のリスト
+-----------+-------------------------------------------+---------+
| 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
表2：アルゴリズムパラメーターとそのデフォルト値のリスト
The receiver-side algorithm can be outlined as below:
受信側のアルゴリズムの概要は次のとおりです。
On initialization:
初期化時：
set d_base = +INFINITY
d_base = + INFINITYを設定します。
set p_loss = 0
p_loss = 0に設定します
set p_mark = 0
p_mark = 0に設定
set r_recv = 0
r_recv = 0を設定します。
set both t_last and t_curr as current time in milliseconds
t_lastとt_currの両方をミリ秒単位の現在の時刻として設定します
On receiving a media packet:
メディアパケットの受信時：
obtain current timestamp t_curr from system clock
システムクロックから現在のタイムスタンプt_currを取得する
obtain from packet header sending time stamp t_sent
パケットヘッダー送信タイムスタンプ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
パケット損失率の見積もりを更新しますp_loss
update packet marking ratio estimate p_mark
パケットマーキング率の推定値を更新するp_mark
update measurement of receiving rate r_recv
受信レートr_recvの測定値を更新
On time to send a new feedback report (t_curr - t_last > DELTA):
新しいフィードバックレポートを送信する予定の時間（t_curr-t_last> DELTA）：
calculate non-linear warping of delay d_tilde if packet loss exists
パケット損失が存在する場合、遅延d_tildeの非線形ワーピングを計算します
calculate current aggregate congestion signal x_curr
現在の集約輻輳信号x_currを計算します
determine mode of rate adaptation for sender: rmode
送信者のレート適応モードを決定する：rmode
send feedback containing values of: rmode, x_curr, and r_recv
rmode、x_curr、およびr_recvの値を含むフィードバックを送信します
update t_last = t_curr
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.
遅延ベースのフローが損失ベースのフロー（たとえば、損失ベースのTCP）と競合するときにその地盤を保つためには、観察されたキューイング遅延の異なるレベルを区別することが重要です。たとえば、有線接続では、数十ミリ秒のオーダーの中程度のキューイング遅延値が他の遅延ベースのフローによって自己に与えられるか誘導される可能性がありますが、数百ミリ秒の高いキューイング遅延値は、遅延の増加を抑制しない損失ベースのフロー。
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:
最後に観察されたパケット損失がloss_expの有効期限内（パケット数で測定）の場合、推定キューイング遅延は非線形ワーピングに従います。
/ 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.
式（1）では、キューイング遅延値は、最初のしきい値QTHを下回っていても変化しません。それ以外の場合は、非線形曲線に従って縮小されます。この非線形ワーピングは、[BUDZISZ-AIMD-CC]の遅延適応型輻輳ウィンドウバックオフポリシーに触発されており、損失ベースのフローと競合する場合に、損失によって引き起こされる輻輳信号に基づいて動作するようにコントローラーを「徐々に動かします」。非線形関数の正確な形式は、[BUDZISZ-AIMD-CC]に関して簡略化されています。しきい値QTHの値は、輻輳信号レベルを早期に割り引く潜在的なリスクを回避するために、さまざまな運用環境に合わせて慎重に調整する必要があります。通常、より高い値のQTHは、ノイズの多い環境（たとえば、ワイヤレス接続またはビデオストリームが時間的に変化する多くのバックグラウンドで競合するトラフィックに遭遇する場合）で、時折発生する非輻輳に起因する遅延スパイクに対して堅牢に保つために必要です。この値を調整または自動調整する方法に関する追加の洞察は、さまざまな実際の展開シナリオで実験的研究を実行することから収集する必要があります。
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で自己スケーリングするように構成されています。
loss_exp = MULTILOSS * loss_int.
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].
平均損失間隔loss_intの推定は、「TCPフレンドリーレートコントロール（TFRC）：プロトコル仕様」[RFC5348]のセクション5.4に従います。
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.
実際には、loss_intの期間中続く遷移期間中のキューイング遅延のワープ（d_tilde）値と非ワープ（d_queue）値の間を線形補間することをお勧めします。
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.
ここで、DMARKには、PMRREFの参照マーキング比率でのECNマーキングに関連する参照遅延ペナルティが規定されています。 DLOSSには、PLRREFの参照パケット損失率でのパケット損失に関連する参照遅延ペナルティが規定されています。 DLOSSとDMARKの値は、ネットワークノードの構成に依存しません。 ECN対応のアクティブキュー管理スキームは、通常、パケットをドロップする前にマークを付けるため、DLOSSの値はDMARKの値よりも高い必要があります（SHOULD）。さらに、DLOSSとDMARKの値は、公平に競争できるように、同じボトルネックリンクを共有するすべてのNADAフロー全体で一貫して設定する必要があります。
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.
パケットのマーキングと損失がない場合、x_currの値は、観測されたキューイング遅延d_queueに減少します。その場合、NADAアルゴリズムは遅延ベースの適応の体制で動作します。
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
* 観測ウィンドウLOGWIN内での最近のパケット損失はありません。そして
* No buildup of queuing delay: d_fwd-d_base < QEPS for all previous delay samples within the observation window LOGWIN.
* キューイング遅延の蓄積なし：観測ウィンドウLOGWIN内の以前のすべての遅延サンプルのd_fwd-d_base <QEPS。
Otherwise, the algorithm operates in graduate update mode.
それ以外の場合、アルゴリズムは段階的な更新モードで動作します。
The sender-side algorithm is outlined as follows:
送信側のアルゴリズムの概要は次のとおりです。
On initialization:
初期化時：
set r_ref = RMIN
r_ref = RMINを設定
set rtt = 0
rtt = 0に設定
set x_prev = 0
x_prev = 0を設定
set t_last and t_curr as current system clock time
t_lastとt_currを現在のシステムクロック時間として設定する
On receiving feedback report:
フィードバックレポートの受信時：
obtain current timestamp from system clock: t_curr
システムクロックから現在のタイムスタンプを取得：t_curr
obtain values of rmode, x_curr, and r_recv from feedback report
フィードバックレポートからrmode、x_curr、およびr_recvの値を取得する
update estimation of rtt
rttの推定値を更新
measure feedback interval: delta = t_curr - t_last
if rmode == 0:
rmode == 0の場合：
update r_ref following accelerated ramp-up rules
加速ランプアップルールに従ってr_refを更新する
else:
そうしないと：
update r_ref following gradual update rules
段階的な更新ルールに従ってr_refを更新する
clip rate r_ref within the range of minimum rate (RMIN) and maximum rate (RMAX).
最小レート（RMIN）と最大レート（RMAX）の範囲内のクリップレートr_ref。
set x_prev = x_curr
セットx_prev = x_curr
set t_last = t_curr
セットt_last = t_curr
In accelerated ramp-up mode, the rate r_ref is updated as follows:
加速ランプアップモードでは、レートr_refは次のように更新されます。
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.
レート増加乗数ガンマは、自己起因のキューイング遅延（QBOUND）、往復時間（rtt）、およびターゲットフィードバック間隔（DELTA）の上限の関数として計算されます。これは、d_queue（DFILT）を計算するためのフィルタリング遅延に拘束されます。最大値はGAMMA_MAXです。方程式（3）から（4）の背後にある理論的根拠は、送信者が自己に起因するキューイング遅延の増加を観察するのにかかる時間が長いほど、送信者はそのレートを増加させる際により慎重になるはずであり、したがって、レート増加乗数は小さくなる。
In gradual update mode, the rate r_ref is updated as:
段階的更新モードでは、レートr_refは次のように更新されます。
x_offset = x_curr - PRIO*XREF*RMAX/r_ref (5)
x_diff = x_curr - x_prev (6)
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.
レートは、前回のレート決定に比例して変化します。これは、2つの項の影響を受けます。平衡状態での値からの混雑信号のオフセット（x_offset）とその変化（x_diff）です。 x_offsetの計算は、フローの最大レート（RMAX）、優先度の重み（PRIO）、および参照輻輳信号（XREF）に依存します。 XREFの値は、観測された輻輳信号レベルがPRIO * XREFを下回ったときにRMAXの最大レートを達成できるように選択されています。
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.
平衡状態では、集約された輻輳信号はx_curr = PRIO * XREF * RMAX / r_refで安定します。これにより、複数のフローが同じボトルネックを共有し、x_currの共通の値を観察する場合、平衡状態でのそれらのレートは、それぞれの優先度レベル（PRIO）および最小レートと最大レートの間の範囲に比例します。最小レート（RMIN）と最大レート（RMAX）の値は、たとえば[RMCAT-CC-RTP]で概説されているように、メディアコーデックによって提供されます。そのような情報がない場合、NADA送信側は、RMINに0、RMAXに3 Mbpsのデフォルト値を選択します。
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 = min（r_ref、RMAX）（8）
r_ref = max(r_ref, RMIN) (9)
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で説明します。
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.
受信機は、遅延、損失、ECNマーキング比率の観点から、エンドツーエンドのパケットごとの統計を継続的に監視します。次に、すべての形式の輻輳インジケーターを同等の遅延の形式に集約し、これを送信者に定期的に報告します。さらに、受信者はフローの受信速度を追跡し、それをフィードバックメッセージに含めます。
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.
NADAの遅延推定プロセスは、低追加遅延バックグラウンドトランスポート（LEDBAT）[RFC6817]など、以前の遅延ベースの輻輳制御方式と同様のアプローチに従います。実験的な実装では、RTPタイムスタンプと送信時間オフセットRTPヘッダー拡張[RFC5450]に依存する代わりに、NADA送信者はローカルシステムクロックに基づいて独自のタイムスタンプを生成し、その情報をトランスポートパケットヘッダーに埋め込むことができます。 NADAレシーバーは、一定の基本遅延コンポーネントと時変キューイング遅延コンポーネントを持つものとして転送遅延を推定します。基本遅延は、比較的長い期間（たとえば、数十分）にわたって観測された一方向遅延の最小値として推定されますが、個々のキューイング遅延値は、一方向遅延と基本遅延の差と見なされます。基本遅延を定期的に再推定することにより、基本遅延の期限切れの潜在的な問題を回避できます。これにより、基礎となるルート変更または送信者間のクロックレートスキューによって導入される累積タイミング差により、以前に測定された基本遅延値が無効になります。そしてレシーバー。すべての遅延推定は、100マイクロ秒またはそれより細かい推奨粒度で送信者のタイムスタンプに基づいています。
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で表されているように、d_queue = d_fwd-d_baseを使用してキューイング遅延の値を計算することに加えて、現在の実装では、パケットごとのキューイング遅延値に対して15サンプルのウィンドウサイズの最小フィルターをさらに採用しています。
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:
レシーバーは、受信したパケットのRTPシーケンス番号のギャップを介してパケット損失を検出します。レイテンシの制約が厳しいインタラクティブなリアルタイムメディアアプリケーション（ビデオ会議など）の場合、レシーバは、順序が正しくないパケットを損失として扱うことで、パケットの並べ替え遅延を回避します。瞬時パケット損失率p_instは、最新の監視ウィンドウLOGWIN内の送信パケット総数に対する欠落パケット数の比率として推定されます。パケット損失率p_lossは、指数平滑化の後に取得されます。
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.
フィルタリングされた結果は、観測されたパケット損失率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].
パケットマーキング率p_markの推定は、上記と同じ手順に従います。 [RFC6679]で説明されているメカニズムに従って、IPヘッダーのECNマーキング情報を受信エンドポイントに渡すことができると想定されています。
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.
受信率r_recvを見積もるのはかなり簡単です。 NADAは、LOGWINのタイムスパンで最近の観測ウィンドウを維持し、そのウィンドウの間に到着するパケットの合計サイズをそのタイムスパンで単純に分割します。受信レート（r_recv）は、受信側からのパケットごとのフィードバックに基づいて送信側で計算するか、フィードバックレポートの一部として含めることができます。
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.
図2は、NADA送信者の詳細を示しています。 NADA送信側は、受信側からRTCPフィードバックレポートを受信すると、セクション4.3で指定されているように参照レートr_refを計算します。さらに、更新されたr_refの値とレートシェーピングバッファー占有率buffer_lenに基づいて、ライブビデオエンコーダーのターゲットレートr_vinと送信レートr_sendの両方をネットワーク上で調整します。
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.
NADA送信側の動作は、すべてのタイプの輻輳インジケーター（遅延、損失、ECNマーキング）がある場合でも同じです。この統一されたアプローチにより、ネットワークは軽い輻輳レベルと重い輻輳レベルの間で動的に移行するため、スキームをスムーズに移行できます。
+----------------+
| 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
図2：NADAトランスミッターの構造
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.
ライブビデオエンコーダーの操作は、NADAの輻輳制御方式の設計の範囲外です。代わりに、その動作はブラックボックスとして扱われます。
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.
レートシェーピングバッファは、エンコーダレート出力r_voutと調整された送信レートr_sendの間の瞬間的な不一致を吸収するために使用されます。現在の占有レベルはバイト単位で測定され、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
* 送信レートr_sendを増やすことにより、レートシェーピングバッファをより早く使い果たすため。そして
* To limit incoming packets of the rate-shaping buffer by reducing the video encoder target rate r_vin.
* ビデオエンコーダのターゲットレートr_vinを下げることにより、レートシェーピングバッファの着信パケットを制限します。
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_vinと実際の送信レートr_sendをさらに調整できます。このような調整の目的は、レートシェーピングバッファによって導入される追加のレイテンシを軽減することです。レート調整の量は、次のように計算できます。
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].
式（11）および（12）では、調整量はレートシェーピングバッファーのサイズに比例するように計算されますが、ネットワークの輻輳フィードバックのみから計算される参照レートr_refの5％によって制限されます。これにより、レートシェーピングバッファによって導入される調整が、コアの輻輳制御プロセスを妨げないことが保証されます。式（13）および（14）は、レートシェーピングバッファの影響を示します。大きなレートシェーピングバッファは、エンコーダのターゲットレートを、リファレンスレートr_refの少し下（および送信レートの少し上）に微調整します。最終的なビデオターゲットレート（r_vin）と送信レート（r_send）は、[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.
直感的には、単一のビデオフレームの継続時間内にレートシェーピングバッファを完全に排出するために必要な追加のレートオフセットの量は、8 * buffer_len * FPSで与えられます。FPSはビデオの参照フレームレートを表します。スケーリングパラメーターBETA_VとBETA_Sを調整して、小さなレートシェーピングバッファーを維持するという目標と、基準レートポイントから逸脱するという目標のバランスを取ることができます。経験的観察は、レスポンシブライブビデオエンコーダーのレートシェーピングバッファーは通常空のままであり、転送中に大きなフレーム（たとえば、イントラフレームが生成されるとき）しか保持しないことを示しています。したがって、このメカニズムによって導入されるレート調整はわずかであると予想されます。たとえば、2000バイトのレートシェーピングバッファーは、推奨されるスケーリングパラメーターがBETA_V = 0.1およびBETA_S = 0.1であり、参照フレームレートがFPS = 30の場合、48 Kbpsのレート調整になります。
The following list of information is required for NADA congestion control to function properly:
NADAの輻輳制御が適切に機能するには、次の情報のリストが必要です。
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).
推奨レートアダプテーションモード（rmode）：送信側が加速ランプアップモード（rmode = 0）で動作するか、段階的更新モード（rmode = 1）で動作するかを示す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.
集約された輻輳信号（x_curr）：セクション4.2に従って受信者によって計算された最新の更新値。この情報は、15ビットで100マイクロ秒（つまり、ミリ秒の1/10）の単位で表すことができます。これにより、約3.27秒でx_currの最大値が許可されます。
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.
受信率（r_recv）：セクション5.1.3に従って最後に測定された受信率。この情報は、32ビットのビット/秒（bps）の単位（unsigned int）で表されます。これにより、約4.3 Gbpsの最大レートが可能になり、今日の標準的な高解像度（HD）ビデオ会議セッションのストリーミングレートの約1000倍になります。さらに高いレートを指定する必要がある場合は、このフィールドをさらに数バイト拡張できます。
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.
上記の情報のリストは、合計で48ビット、つまり6バイトで対応できます。これらは、レシーバーからのフィードバックレポートに含めるか、[RTCP-FEEDBACK]で定義されているフィードバックメッセージのパケットごとの情報から、レシーバー側のすべての計算をセンダーに移動する場合に含めることができます。フィードバックメッセージ間隔DELTAの選択については、セクション6.3で説明します。 DELTA = 100 msのターゲットフィードバック間隔をお勧めします。
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.
このセクションでは、NADAによって行われたさまざまな設計の選択、その実装の潜在的な代替バリアント、および主要なアルゴリズムパラメーターの選択方法に関するガイドラインについて説明します。セクション8では、これらのトピックをさらに調査するために、追加の実験設定を推奨しています。
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.
現在の設計では、輻輳の主な指標として相対一方向遅延（OWD）を使用しています。相対OWDの値は、比較的長い期間にわたって観測されたOWDの最小値を維持し、それを観測された絶対OWD値から差し引くことによって取得されます。このようなアプローチは、送信側と受信側のクロック間の固定された違いをキャンセルします。これは、[RFC6817]などの他の遅延ベースの輻輳制御アプローチで広く採用されています。 [RFC6817]で説明されているように、最小OWDを追跡する期間は慎重に選択する必要があります。パスに沿ってゼロのスタンディングキューで最小OWDを観察する機会に十分な長さである必要があり、ルート変更やその他のまれなイベントによって導入された最小OWDの「真の」変更をタイムリーに反映し、クロックレートスキューの累積的な影響。
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.
輻輳信号として相対OWDに依存することの潜在的な欠点は、複数のフローが同じボトルネックを共有する場合、空でないキューが発生しているネットワークに遅れて到着するフローが、スタンディングキューイング遅延を固定パス伝搬遅延の一部として誤って考慮する可能性があることです。 。これにより、フロー間でわずかに不公平な帯域幅が共有されます。
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.
あるいは、代わりにパケットごとの統計処理を送信者に移動し、パケットごとの確認応答が利用可能であると仮定して、相対OWDの代わりに相対ラウンドトリップ時間（RTT）を使用できます。 RTTベースのアプローチの主な欠点は、逆方向に測定された遅延のノイズです。
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.
どちらの遅延メトリック（相対OWD対RTT）を選択しても、提案されたレート適応アルゴリズムに変更はありません。したがって、採用する遅延メトリックに関する長所と短所の比較は、調査の直交方向として維持できます。
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.
他の遅延ベースの輻輳制御方式と同様に、NADAのパフォーマンスは、その遅延測定および推定モジュールの精度に依存します。 [RFC6817]の付録Aは、この側面に関する広範な議論を提供します。
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.
15サンプルのウィンドウサイズで最小フィルターを適用する現在推奨されている方法は、有線接続で観察される処理遅延の外れ値から保護するのに十分です。パケット遅延変動（PDV）が高いワイヤレス接続の場合、ノイズ除去、外れ値の拒否、および傾向分析に関するより高度な手法が必要になる場合があります。
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.
[FLOYD-CCR00]で採用されているような、パケット損失率の計算におけるより高度な方法は、おそらく有益でしょう。これらの代替案は、このドキュメントが提案する実験の一部です。
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.
段階的レート更新モードでは、パラメーターTAUはフィードバック制御ループでの往復時間（RTT）の上限を示します。通常、観測されたフィードバック間隔デルタはターゲットフィードバック間隔DELTAに近く、デルタ/ TAUとETAの相対的な比率は、最近の変化（x_diff）と比べて、集約輻輳信号オフセット項（x_offset）からの影響の相対的な強さを示します。それぞれ。これらの2つの項は、比例-積分（PI）コントローラーの積分および比例項に類似しています。 TAU = 500 ms、DELTA = 100 ms、およびETA = 2.0の推奨される選択は、積分項と比例項のゲイン間の相対比1:10に対応します。その結果、レート適応は、主に、オフセット項によって駆動されるその平衡値への長期シフトを伴う輻輳信号の変化によって駆動されます。最後に、スケーリングパラメータKAPPAは、適応の全体的な速度を決定し、応答性と安定性のバランスをとる必要があります。
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.
ターゲットフィードバック間隔DELTAの選択は、タイムリーなフィードバックと少ないRTCPフィードバックメッセージ数の間の適切なバランスを取る必要があります。 DELTA = 100 msのターゲットフィードバック間隔が推奨されます。これは、フィードバックメッセージごとに200バイトの16 Kbpsのフィードバック帯域幅に対応します。1Mbpsフローの場合、オーバーヘッドは約1.6％です。さらに、[IETF-95]のシミュレーション研究と周波数領域分析の両方で、250 ms未満のフィードバック間隔（つまり、1秒あたり4フィードバックメッセージより頻繁）は、NADA輻輳制御のフィードバック制御ループを壊さないことが確立されています。
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.
式（１）で遅延の非線形ワーピングを計算する際、現在の設計では、ＱＴＨの固定値を使用して、非線形ワーピングを実行するかどうかを決定します。その値は、輻輳信号レベルを早期に割り引く潜在的なリスクを回避するために、さまざまな運用環境（たとえば、有線接続と無線接続）に合わせて慎重に調整する必要があります。パケット損失がある場合にキューイング遅延の過去の観測パターンに基づいてその値を適応させることが可能です。非線形ワーピングメカニズムにより、複数のNADAストリームが損失ベースモードでスタックし、互いに競合する可能性があることに注意する必要があります。
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).
集約輻輳信号x_currの計算では、DMARKとDLOSSの選択が、所定の利用可能な帯域幅でフローが経験する定常状態のパケット損失/マーキング比率に影響を与えます。 DMARKおよびDLOSSの値が高いほど、定常状態の損失/マーキング率は低くなりますが、個々のパケット損失/マーキングイベントの影響を受けやすくなります。 DMARKとDLOSSの値は現在の設計で固定されており、事前に決定されていますが、このドキュメントでは、他の競合する損失ベースのフロー（損失など）が存在する場合に、望ましい帯域幅共有動作に基づいてこれらの値を自動的に調整するスキームのさらなる調査を奨励していますベースのTCP）。
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.
現在の設計では、集約された輻輳信号x_currが受信側で計算され、使用中の実際のネットワーク輻輳表示（遅延、損失、またはマーキング）の形式とは完全に独立した送信側の動作が維持されます。
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.
あるいは、受信者側の計算を送信者にシフトすることもできます。これにより、[RTCP-FEEDBACK]で定義されているように、受信者は定期的なフィードバックメッセージを介してパケットごとの情報を報告します。このようなアプローチにより、さまざまな輻輳制御方式で動作する送信者間の相互運用性が可能になりますが、フィードバックメッセージで若干高いオーバーヘッドが必要になります。フィードバックメッセージの望ましい形式と推奨されるフィードバック間隔については、[RTCP-FEEDBACK]の追加の説明を参照してください。
One nice property of NADA is the consistent video endpoint behavior irrespective of network node variations. This facilitates gradual, incremental adoption of the scheme.
NADAの優れた特性の1つは、ネットワークノードの変動に関係なく、一貫したビデオエンドポイントの動作です。これにより、段階的で段階的なスキームの採用が容易になります。
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.
REDベースのマーキングがあるネットワークノードでECNが有効になっている場合、受信者はECNマーキングの観測を等価遅延の計算に組み込むことができます。送信者は、これらの明示的な輻輳信号に変更を加えることなく対応できます。
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.
最終的に、トークンバケットメータリングのレベルに基づくプロアクティブマーキングを備えたネットワークは、ゼロスタンディングキューとエンドツーエンドの遅延の低減という追加のメリットを享受し、既存の送信者および受信者とシームレスに連携できます。
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].
[IETF-90]は、ラボ環境でのNADAの実装と評価について説明しています。シングルフローおよびマルチフローテストシナリオでのNADAの予備評価結果は、[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.
NADAのリファレンス実装は、Mozillaオープンソースブラウザーに埋め込まれたWebRTCモジュールを変更することによって行われました。 [IETF-103]および[IETF-105]からのプレゼンテーションは、NADAによって駆動される変更されたブラウザの実際の評価を文書化しています。実験的な設定には、ホームまたはエンタープライズワイヤレスネットワークを介したエンドポイントとのリモート接続が含まれます。これらの評価は、ラストホップワイヤレス接続上の断続的な遅延スパイクによって引き起こされるスループットドロップから迅速に回復する際のNADAフローの有効性を検証します。
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.
NADAは、[RMCAT-EVAL-TEST]で指定されたテストケースのコレクションや[WIRELESS-TESTS]のWi-Fiベースのテストケースのサブセットを含む、さまざまなテストシナリオの下で広範囲に評価されています。 NADAがRED、Controlling Queue Delay（CoDel）、Proportional Integral Controller Enhanced（PIE）などのさまざまなAQMスキームとどのように相互作用するかを特徴付けるために、追加の評価が行われました。これらの評価のほとんどは、シミュレーターで実行されています。ビデオ会議クライアントに実装が組み込まれたラボ環境で、いくつかの主要なテストケースが評価されています。 NADAの実装と実験を実際の環境で実行することを強くお勧めします。このような演習では、セクション6で説明するように、主要なアルゴリズムパラメーター（表2のリストを参照）の値を選択または自動的に調整する方法についての洞察が得られます。
Additional experiments are suggested for the following scenarios, preferably over real-world networks:
次のシナリオでは、できれば実際のネットワークを介して追加の実験を行うことをお勧めします。
* Experiments reflecting the setup of a typical WAN connection.
* 一般的なWAN接続の設定を反映した実験。
* Experiments with ECN marking capability turned on at the network for existing test cases.
* 既存のテストケースのネットワークでECNマーキング機能を有効にした実験。
* Experiments with multiple NADA streams bearing different user-specified priorities.
* ユーザーが指定した優先順位が異なる複数のNADAストリームを使用した実験。
* Experiments with additional access technologies, especially over cellular networks such as 3G/LTE.
* 特に3G / LTEなどのセルラーネットワークを介した、追加のアクセステクノロジーの実験。
* Experiments with various media source contents, including audio only, audio and video, and application content sharing (e.g., slideshows).
* オーディオのみ、オーディオとビデオ、アプリケーションコンテンツの共有（スライドショーなど）を含む、さまざまなメディアソースコンテンツの実験。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
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.
NADAのレート適応メカニズムは、受信機からのフィードバックに依存しています。そのため、フィードバックメッセージが乗っ取られたり、置き換えられたり、意図的に誤解を招く情報が注入されたりする攻撃に対して脆弱であり、TCPに影響を与える可能性のあるものと同様にサービス拒否を引き起こします。したがって、RTCPフィードバックメッセージは少なくとも整合性チェックされることが推奨されます。さらに、[RTCP-FEEDBACK]は、誤解を招く輻輳フィードバック情報を提供する受信機の潜在的なリスクと、そのようなリスクを軽減するメカニズムについて説明します。
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.
送信側のレートシェーピングバッファーに基づいて送信レートを変更すると、応答しないビデオエンコーダーが存在する場合、ネットワーク上で一時的に過度の輻輳が発生する可能性があります。ただし、この影響は、レートシェーピングバッファによって導入されるレート変更の量を制限し、送信側のレートシェーピングバッファのサイズを制限し、NADAによる最大許容送信レートを維持することで軽減できます。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<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>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <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>.
[RFC5348] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：Protocol Specification」、RFC 5348、DOI 10.17487 / RFC5348、2008年9月、<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>.
[RFC6679] Westerlund、M.、Johansson、I.、Perkins、C.、O'Hanlon、P。、およびK. Carlberg、「RTP over UDPの明示的輻輳通知（ECN）」、RFC 6679、DOI 10.17487 / RFC6679 、2012年8月、<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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[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>.
[BUDZISZ-AIMD-CC] Budzisz、L.、Stanojevic、R.、Schlote、A.、Baker、F。、およびR. Shorten、「損失と遅延ベースのTCPの公平な共存について」、IEEE / ACMネットワーキングのトランザクション、vol。 19、いいえ。 6、pp。1811-1824、DOI 10.1109 / TNET.2011.2159736、2011年12月、<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>.
[FLOYD-CCR00] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「ユニキャストアプリケーションのための方程式ベースの輻輳制御」、ACM SIGCOMM Computer Communications Review、vol。 30、いいえ。 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-103]朱、X。、パン、R。、ラマーリョ、M。、メナ、S。、ジョーンズ、P。、フー、J。、およびS.ダロンコ、「MozillaブラウザでのNADA実装」、 IETF 103、2018年11月、<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-105] Zhu、X.、Pan、R.、Ramalho、M.、Mena、S.、Jones、P.、Fu、J。、およびS. D'Aronco、「MozillaブラウザおよびドラフトでのNADA実装Update」、IETF 105、2019年7月、<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-90] Zhu、X.、Ramalho、M.、Ganzhorn、C.、Jones、P。、およびR. Pan、「NADA Update：Algorithm、Implementation、and Test Case Evaluation Results」、IETF 90、2014年7月、<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-91] Zhu、X.、Pan、R.、Ramalho、M.、Mena、S.、Ganzhorn、C.、Jones、P。、およびS. D'Aronco、「NADAアルゴリズムの更新とテストケースの評価"、IETF 91、2014年11月、<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-93]朱、X。、パン、R。、ラマーリョ、M。、メナ、S。、ガンツホーン、C。、ジョーンズ、P。、ダロンコ、S.、J。フー、「最新情報NADA」、IETF 93、2015年7月、<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>.
[IETF-95]朱、X。、パン、R。、ラマーリョ、M。、メナ、S。、ジョーンズ、P。、フー、J。、ダロンコ、S.、C。ガンツホーン、「最新情報NADA：安定性分析とフィードバック間隔の影響」、IETF 95、2016年4月、<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-2]「ns-2」、2014年12月、<http://nsnam.sourceforge.net/wiki/index.php/Main_Page>。
[NS-3] "ns-3 Network Simulator", <https://www.nsnam.org/>.
[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>.
[NS3-RMCAT] Fu、J.、Mena、S。、およびX. Zhu、「IETF RMCAT輻輳制御プロトコルのシミュレーター」、2017年11月、<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>.
[RFC5450] Singer、D。およびH. Desineni、「RTPストリームの伝送時間オフセット」、RFC 5450、DOI 10.17487 / RFC5450、2009年3月、<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>.
[RFC6660] Briscoe、B.、Moncaster、T。、およびM. Menth、「単一のDiffservコードポイント（DSCP）を使用したIPヘッダー内の3つの事前輻輳通知（PCN）状態のエンコード」、RFC 6660、DOI 10.17487 / RFC6660 、2012年7月、<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>.
[RFC6817] Shalunov、S.、Hazel、G.、Iyengar、J。、およびM. Kuehlewind、「Low Extra Delay Background Transport（LEDBAT）」、RFC 6817、DOI 10.17487 / RFC6817、2012年12月、<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>.
[RFC7567]ベイカー、F。、エド。およびG.フェアハースト編、「アクティブキュー管理に関するIETFの推奨事項」、BCP 197、RFC 7567、DOI 10.17487 / RFC7567、2015年7月、<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>.
[RFC8033]パン、R、ナタラジャン、P、ベイカー、F、Gホワイト、2017年2月、<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>.
[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、2018年1月、<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>.
[RFC8593] Zhu、X.、Mena、S。、およびZ. Sarker、「RTP輻輳制御評価のビデオトラフィックモデル」、RFC 8593、DOI 10.17487 / RFC8593、2019年5月、<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] Jesup、R。およびZ. Sarker、「インタラクティブリアルタイムメディアの輻輳制御要件」、作業中、インターネットドラフト、draft-ietf-rmcat-cc-requirements-09、2014年12月12日、 <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-CC-RTP] Zanaty、M.、Singh、V.、Nandakumar、S。、およびZ. Sarker、「RTPアプリケーションでの輻輳制御とコーデックの相互作用」、進行中の作業、インターネットドラフト、ドラフト-ietf- rmcat-cc-codec-interactions-02、2016年3月18日、<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>.
[RMCAT-EVAL-TEST] Sarker、Z.、Singh、V.、Zhu、X。、およびM. Ramalho、「RMCATプロポーザルを評価するためのテストケース」、作業中、インターネットドラフト、draft-ietf-rmcat- eval-test-10、2019年5月23日、<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>.
[RTCP-FEEDBACK] Sarker、Z.、Perkins、C.、Singh、V。、およびM. Ramalho、「輻輳制御のためのRTP制御プロトコル（RTCP）フィードバック」、進行中の作業、インターネットドラフト、ドラフト-ietf- avtcore-cc-feedback-message-05、2019年11月4日、<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>.
[ワイヤレステスト] Sarker、Z.、Johansson、I.、Zhu、X.、Fu、J.、Tan、W。、およびM. Ramalho、「ワイヤレスネットワーク上のインタラクティブなリアルタイムメディアの評価テストケース」、 Work in Progress、Internet-Draft、draft-ietf-rmcat-wireless-tests-08、2019年7月5日、<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>.
[ZHU-PV13] Zhu、X.、R。Pan、「NADA：A Unified Cgestion Control Scheme for Low-Latency Interactive Video」、Proc。 IEEE International Packet Video Workshop、カリフォルニア州サンノゼ、DOI 10.1109 / PV.2013.6691448、2013年12月、<https://doi.org/10.1109/PV.2013.6691448>。
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.
NADAは、さまざまなネットワークキュー管理方式で機能し、特定のネットワークノード操作を想定していません。例として、この付録では、ネットワークノードでのキュー管理動作の3つのバリアントについて説明します。これにより、暗黙的または明示的な輻輳信号が発生します。 NADAが非確率的ECNマーキング動作でまだテストされていないことを認める必要があります。
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.
以下に説明する3つのフレーバーすべてにおいて、ネットワークキューは単純な先入れ先出し（FIFO）の原則で動作します。フローごとの状態を維持する必要はありません。システムは、多数のビデオフローと高いリンク容量で簡単に拡張できます。
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.
ドロップテールキューまたはREDキューを備えた従来のネットワークでは、エンドツーエンドの遅延やパケット損失、あるいはその両方の推定から輻輳が推測されます。キューでのパケットドロップはレシーバーで検出され、集約された輻輳信号x_currの計算に寄与します。ネットワークノードで特別なアクションは必要ありません。
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:
このモードでは、ネットワークノードは、ランダム早期検出（RED）アルゴリズム[RFC7567]に従って、IPパケットヘッダーのECNフィールドをランダムにマークします。マーキング確率の計算には、パケット到着時の次の手順が含まれます。
1. update smoothed queue size q_avg as:
1. 平滑化キューサイズq_avgを次のように更新します。
q_avg = w*q + (1-w)*q_avg
2. calculate marking probability p as:
2. マーキング確率pを次のように計算します。
/ 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.
ここで、q_loとq_hiは、キュー占有率の低しきい値と高しきい値に対応しています。最大マーキング確率は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.
ECNマーキングイベントは、レシーバーでの同等の遅延x_currの計算に貢献します。送信側での変更は必要ありません。
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.
高度なネットワークノードは、元々輻輳前通知（PCN）[RFC6660]向けに設計されたトークンバケットアルゴリズムに基づくランダムな早期マーキングをサポートする場合があります。パケットのIPヘッダーの早期輻輳通知（ECN）ビットはランダムにマークされます。マーキング確率は、元々PCN [RFC6660]用に設計されたトークンバケットアルゴリズムに基づいて計算されます。目標リンク使用率は90％に設定されています。マーキング確率は、完全なトークンバケット制限の1/3から2/3の間で変動する場合、トークンバケットサイズとともに直線的に増加するように設計されています。
Calculation of the marking probability involves the following steps upon packet arrival:
マーキング確率の計算には、パケット到着時の次の手順が含まれます。
1. meter packet against token bucket (r,b)
1. トークンバケットに対するパケットのメーター（r、b）
2. update token level b_tk
2. トークンレベルb_tkを更新する
3. calculate the marking probability as:
3. 次のようにマーキング確率を計算します。
/ 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.
ここで、トークンバケットの下限と上限は、それぞれb_loとb_hiで表されます。パラメータbは、トークンバケットのサイズを示します。パラメータrは容量を下回るように選択されているため、リンクの使用率がわずかに低下します。最大マーキング確率は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.
ECNマーキングイベントは、レシーバーでの同等の遅延x_currの計算に貢献します。送信側での変更は必要ありません。 PCNベースのマーキングアルゴリズムからの仮想キューイングメカニズムは、ゼロスタンディングキューなどの追加の利点につながります。
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.
著者は、Randell Jesup、Luca De Cicco、Piers O'Hanlon、Ingemar Johansson、Stefan Holmer、Cesar Ilharco Magalhaes、Safiqul Islam、Michael Welzl、MirjaKühlewind、Karen Elisabeth Egede Nielsen、Julius Flohr、Roland 、およびこの仕様への貴重なレビューコメントと有用な情報を提供してくれたMartin Stiemerling。
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.
シスコシステムズのPaul E. Jones <paulej@packetizer.com>は、NADA輻輳制御スキームの初期バージョンを実装し、ラボベースのテストベッド評価を支援しました。
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.
シスコシステムズのJiantao Fu <jianfu@cisco.com>は、Mozilla Webブラウザと以前のシミュレーションベースの評価作業の両方で、NADAの実装と広範な評価を支援しました。
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].
ETHチューリッヒのStefano D'Aronco <stefano.daronco@geod.baug.ethz.ch>（以前はこの作業に貢献したときは、Ecole Polytechnique Federale de Lausanneにいた）が、[NS-]でのNADAの初期バージョンの実装と評価を支援しました。 3]。
Charles Ganzhorn <charles.ganzhorn@gmail.com> contributed to the testbed-based evaluation of NADA during an early stage of its development.
Charles Ganzhorn <charles.ganzhorn@gmail.com>は、NADAの開発の初期段階におけるNADAのテストベッドベースの評価に貢献しました。
Authors' Addresses
著者のアドレス
Xiaoqing Zhu Cisco Systems 12515 Research Blvd., Building 4 Austin, TX 78759 United States of America
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
Rong Pan Intel Corporation 2200 Mission College Blvd Santa Clara、CA 95054アメリカ合衆国
Email: rong.pan@intel.com
Michael A. Ramalho AcousticComms Consulting 6310 Watercrest Way Unit 203 Lakewood Ranch, FL 34202-5211 United States of America
Michael A. Ramalho AcousticComms Consulting 6310 Watercrest Way Unit 203 Lakewood Ranch、FL 34202-5211アメリカ合衆国
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
Sergio Mena Cisco Systems EPFL、Quartier de l'Innovation、Batiment E CH-1015 Ecublens Switzerland
Email: semena@cisco.com